develop a 'customized ld'

develop a 'customized ld'

[sean yang]

Hi folks,
I am looking at the source codes in ld directory(source code related to the 
linker) as I want to develop a slightly different linker. Basically, what I 
want to do is to find the address of some instructions in a program at link 
time.

For example, I want to find the program counter(i.e., the address of the 
instruction) of "call '@foo'" instruction at link time.
#demo.c
extern int foo(int);
int main(){
  int i, j;
  i=foo(1); //which will be compiled to something like "push 1; call 
@foo;..."
  j=foo(i);
}//the assebly code is not syntatically correct--only try to show my goal.

Conceptually, this doesn't seem to need much code modification---keep most 
pass intact and add a customized pass to achieve what i want. ld is a quite 
big project to me, honestly. And this is my first time to touch it. Could 
someone give me some hint where should I start? Can any expert assess the 
difficulty of achieving such functionality?

Thanks,
Sean

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

Re: develop a 'customized ld'

[Simon Richter]

[-- Attachment #1: Type: text/plain, Size: 418 bytes --]

Hi,

sean yang wrote:

> For example, I want to find the program counter(i.e., the address of the 
> instruction) of "call '@foo'" instruction at link time.

This can be done for assembler code, but obvoisly not for C code as
there is no way to make sure the C compiler will always use the same
instructions. Just declare an assembler label in front of the
instruction of which you want to take the address.

   Simon

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 307 bytes --]

Re: develop a 'customized ld'

[Ian Lance Taylor]

Simon Richter <Simon.Richter@hogyros.de> writes:

> sean yang wrote:
> 
> > For example, I want to find the program counter(i.e., the address of the 
> > instruction) of "call '@foo'" instruction at link time.
> 
> This can be done for assembler code, but obvoisly not for C code as
> there is no way to make sure the C compiler will always use the same
> instructions. Just declare an assembler label in front of the
> instruction of which you want to take the address.

You can use a gcc extension creatively to approximate this:

void foo ()
{
 lab:
  printf ("%p\n", &&lab);
}

Ian

Re: develop a 'customized ld'

[Daniel Jacobowitz]

On Sat, Sep 10, 2005 at 10:19:47AM -0700, Ian Lance Taylor wrote:
> Simon Richter <Simon.Richter@hogyros.de> writes:
> 
> > sean yang wrote:
> > 
> > > For example, I want to find the program counter(i.e., the address of the 
> > > instruction) of "call '@foo'" instruction at link time.
> > 
> > This can be done for assembler code, but obvoisly not for C code as
> > there is no way to make sure the C compiler will always use the same
> > instructions. Just declare an assembler label in front of the
> > instruction of which you want to take the address.
> 
> You can use a gcc extension creatively to approximate this:
> 
> void foo ()
> {
>  lab:
>   printf ("%p\n", &&lab);
> }

But be careful with it - recent versions of GCC are pretty bad about
preserving the addresses of labels not used for control flow.  I assume
Ian's example will be OK, but if you don't have a computed goto which
might target the label, GCC may just put it somewhere else...

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: develop a 'customized ld'

[sean yang]

>From: Daniel Jacobowitz <drow@false.org>
>To: seanatpurdue@hotmail.com, 
>binutils@sourceware.org,Simon.Richter@hogyros.de
>Subject: Re: develop a 'customized ld'
>Date: Sat, 10 Sep 2005 13:43:02 -0400
>
>On Sat, Sep 10, 2005 at 10:19:47AM -0700, Ian Lance Taylor wrote:
> > Simon Richter <Simon.Richter@hogyros.de> writes:
> >
> > > sean yang wrote:
> > >
> > > > For example, I want to find the program counter(i.e., the address of 
>the
> > > > instruction) of "call '@foo'" instruction at link time.
> > >
> > > This can be done for assembler code, but obvoisly not for C code as
> > > there is no way to make sure the C compiler will always use the same
> > > instructions. Just declare an assembler label in front of the
> > > instruction of which you want to take the address.
> >
> > You can use a gcc extension creatively to approximate this:
> >
> > void foo ()
> > {
> >  lab:
> >   printf ("%p\n", &&lab);
> > }
>
>But be careful with it - recent versions of GCC are pretty bad about
>preserving the addresses of labels not used for control flow.  I assume
>Ian's example will be OK, but if you don't have a computed goto which
>might target the label, GCC may just put it somewhere else...
Thanks to both of you. This is one conern, the other is I really don't want 
to have extra intruction--if the programming load for modification the 
binutils is not too heavy. Perticularly, I don't want to have printf() in 
the final code. Could u give some more suggestion on this?

Thanks again,
Sean

>
>--
>Daniel Jacobowitz
>CodeSourcery, LLC

_________________________________________________________________
DonÂ’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: develop a 'customized ld'

[Ian Lance Taylor]

"sean yang" <seanatpurdue@hotmail.com> writes:

> > > You can use a gcc extension creatively to approximate this:
> > >
> > > void foo ()
> > > {
> > >  lab:
> > >   printf ("%p\n", &&lab);
> > > }
> >
> >But be careful with it - recent versions of GCC are pretty bad about
> >preserving the addresses of labels not used for control flow.  I assume
> >Ian's example will be OK, but if you don't have a computed goto which
> >might target the label, GCC may just put it somewhere else...
> Thanks to both of you. This is one conern, the other is I really don't
> want to have extra intruction--if the programming load for
> modification the binutils is not too heavy. Perticularly, I don't want
> to have printf() in the final code. Could u give some more suggestion
> on this?

The printf was just an example of using the label.  The gcc extension
is '&&' applied to a label.  See the gcc docs.

You haven't really said what you want to do with the address.  If you
don't want to use it in the program itself, then this approach is
useless.

Ian

Re: develop a 'customized ld'

[sean yang]

>From: Ian Lance Taylor <ian@airs.com>
>To: "sean yang" <seanatpurdue@hotmail.com>
>CC: binutils@sourceware.org
>Subject: Re: develop a 'customized ld'
>Date: 10 Sep 2005 22:31:38 -0700
>
>"sean yang" <seanatpurdue@hotmail.com> writes:
>
> > > > You can use a gcc extension creatively to approximate this:
> > > >
> > > > void foo ()
> > > > {
> > > >  lab:
> > > >   printf ("%p\n", &&lab);
> > > > }
> > >
> > >But be careful with it - recent versions of GCC are pretty bad about
> > >preserving the addresses of labels not used for control flow.  I assume
> > >Ian's example will be OK, but if you don't have a computed goto which
> > >might target the label, GCC may just put it somewhere else...
> > Thanks to both of you. This is one conern, the other is I really don't
> > want to have extra intruction--if the programming load for
> > modification the binutils is not too heavy. Perticularly, I don't want
> > to have printf() in the final code. Could u give some more suggestion
> > on this?
>
>The printf was just an example of using the label.  The gcc extension
>is '&&' applied to a label.  See the gcc docs.
>
>You haven't really said what you want to do with the address.  If you
>don't want to use it in the program itself, then this approach is
>useless.
I would like to collect the information of call to some libc functions. I am 
not going to use it in the program itself but I am going to use it in a 
system  tool to watch the program's special calls.
Thanks,
Sean

>
>Ian

_________________________________________________________________
Is your PC infected? Get a FREE online computer virus scan from McAfee® 
Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

Re: develop a 'customized ld'

[Ravi Ramaseshan]

Hi,

On 9/11/05, sean yang <seanatpurdue@hotmail.com> wrote:
> I would like to collect the information of call to some libc functions. I am
> not going to use it in the program itself but I am going to use it in a
> system  tool to watch the program's special calls.

So why do you want to do it in the linker ? Why not work on the
disassembly instead ?

-- 
Ravi Ramaseshan

" Reality is only something we believe in strongly. "

Re: develop a 'customized ld'

[sean yang]

>From: Ravi Ramaseshan <ramaseshan.ravi@gmail.com>
>Reply-To: ramaseshan.ravi@gmail.com
>To: sean yang <seanatpurdue@hotmail.com>
>CC: binutils@sourceware.org
>Subject: Re: develop a 'customized ld'
>Date: Sun, 11 Sep 2005 01:53:25 -0400
>
>Hi,
>
>On 9/11/05, sean yang <seanatpurdue@hotmail.com> wrote:
> > I would like to collect the information of call to some libc functions. 
>I am
> > not going to use it in the program itself but I am going to use it in a
> > system  tool to watch the program's special calls.
>
>So why do you want to do it in the linker ? Why not work on the
>disassembly instead ?
I want to have the code obfuscated at link time also, say, insert some 
junk(nop) to prevent others understanding it easily.
In that case, objdump etc. wouldn't work because of the obfuscation.


>
>--
>Ravi Ramaseshan
>
>" Reality is only something we believe in strongly. "

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

Re: develop a 'customized ld'

[Nick Clifton]

Hi Sean,

>>> I would like to collect the information of call to some libc 
>>> functions. 

Why not use the "--wrap <func-name>" linker command line switch ?  That 
way you can intercept calls to specific libc functions, add your own 
wrapper code to collect the information you require and then call the 
normal libc version.

> I want to have the code obfuscated at link time also, say, insert some 
> junk(nop) to prevent others understanding it easily.

This is a separate issue.  As a general principle I would argue against 
obfuscation, it should never really be needed.  If you must do it, then 
just inserting junk instructions is not really going to help.  They can 
easily be detected and ignored by a determined examiner.  Your best bet 
would be to encrypt the binary and hope that you can keep your keys safe 
so that an unauthorized viewer cannot decode the executable.

Getting back to your original question:

> Could someone give me some hint where should I start? Can any expert 
 > assess the difficulty of achieving such functionality?

Conceptually intercepting certain instructions and modifying them is 
very similar to relaxation, so I would suggest that you look at the 
linker's support for this feature.  Have a look at the various 
*_relax_section() functions in the bfd/ directory for examples of this.

As for difficulty - well this is not really something I would ask a 
binutils newbie to do.  You have the potential to corrupt the binaries 
you are producing in quite nasty and/or subtle ways.  Good luck though!

Cheers
   Nick

Re: develop a 'customized ld'

[sean yang]

>From: Nick Clifton <nickc@redhat.com>
>To: sean yang <seanatpurdue@hotmail.com>
>CC: ramaseshan.ravi@gmail.com, binutils@sourceware.org
>Subject: Re: develop a 'customized ld'
>Date: Fri, 30 Sep 2005 12:02:45 +0100
>
>Hi Sean,
>
>>>>I would like to collect the information of call to some libc functions.
>
>Why not use the "--wrap <func-name>" linker command line switch ?  That way 
>you can intercept calls to specific libc functions, add your own wrapper 
>code to collect the information you require and then call the normal libc 
>version.
>
>>I want to have the code obfuscated at link time also, say, insert some 
>>junk(nop) to prevent others understanding it easily.
>
>This is a separate issue.  As a general principle I would argue against 
>obfuscation, it should never really be needed.  If you must do it, then 
>just inserting junk instructions is not really going to help.  They can 
>easily be detected and ignored by a determined examiner.  Your best bet 
>would be to encrypt the binary and hope that you can keep your keys safe so 
>that an unauthorized viewer cannot decode the executable.
~~~~~~~~~~~~~~~~~~~~~
I totally agree with you that obfuscation can never prevent a determinated 
reverse engineer. But
my goal was to deter an automatic binary analyzer(please see my previous 
post for the example how objdump fails in some cases).


>
>Getting back to your original question:
>
>>Could someone give me some hint where should I start? Can any expert
> > assess the difficulty of achieving such functionality?
>
>Conceptually intercepting certain instructions and modifying them is very 
>similar to relaxation, so I would suggest that you look at the linker's 
>support for this feature.  Have a look at the various *_relax_section() 
>functions in the bfd/ directory for examples of this.
>
>As for difficulty - well this is not really something I would ask a 
>binutils newbie to do.  You have the potential to corrupt the binaries you 
>are producing in quite nasty and/or subtle ways.  Good luck though!
>
>Cheers
>   Nick
>

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

about libc function interfaces and ld --wrap

[sean yang]

Several question to ask about libc and linker:

(1) I would ask general glibc design question: whether an exported function 
in glibc can be called by another function internally?
For example (--which is a faked example),
malloc is an exported function;
foo(this is a faked name example)  is another exported function;
** is it possible that foo( ) calls malloc( )  internally?

(2) If the answer to above question is yes, then the following that question 
is: if I have printf wrapped by my own layer (by "ld --wrap printf"), will 
_wrap_malloc() change the internal call's behavior?

void *
__wrap_ malloc(int c)
{
  printf ("Coming here\n", c);
  return __real_malloc (c);
}

(3) If there a convenient way to wrap multi function, e.g., malloc, printf, 
getc...., with same "added functionality" (say just print "coming here"). I 
mean an better way than create each wrapper seperately?

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

Re: about libc function interfaces and ld --wrap

[Daniel Jacobowitz]

On Fri, Mar 03, 2006 at 10:24:48PM +0000, sean yang wrote:
> Several question to ask about libc and linker:
> 
> (1) I would ask general glibc design question: whether an exported function 
> in glibc can be called by another function internally?
> For example (--which is a faked example),
> malloc is an exported function;
> foo(this is a faked name example)  is another exported function;
> ** is it possible that foo( ) calls malloc( )  internally?

Yes.

> (2) If the answer to above question is yes, then the following that 
> question is: if I have printf wrapped by my own layer (by "ld --wrap 
> printf"), will _wrap_malloc() change the internal call's behavior?
> 
> void *
> __wrap_ malloc(int c)
> {
>  printf ("Coming here\n", c);
>  return __real_malloc (c);
> }

Not necessarily.

> (3) If there a convenient way to wrap multi function, e.g., malloc, printf, 
> getc...., with same "added functionality" (say just print "coming here"). I 
> mean an better way than create each wrapper seperately?

Nope.

-- 
Daniel Jacobowitz
CodeSourcery

Re: develop a 'customized ld'

[sean yang]

>From: Simon Richter <Simon.Richter@hogyros.de>
>To: sean yang <seanatpurdue@hotmail.com>
>CC: binutils@sourceware.org
>Subject: Re: develop a 'customized ld'
>Date: Sat, 10 Sep 2005 19:15:40 +0200
>
>Hi,
>
>sean yang wrote:
>
> > For example, I want to find the program counter(i.e., the address of the
> > instruction) of "call '@foo'" instruction at link time.
>
>This can be done for assembler code, but obvoisly not for C code as
>there is no way to make sure the C compiler will always use the same
>instructions. Just declare an assembler label in front of the
>instruction of which you want to take the address.
~~~~~~~~~~~~~~~~~at assemble time, the address are still not resolved as the 
virtual address which is the address that instruction to be loaded to at 
runtime. i.e., all addresses produced by assembler are still relative 
address. How can I get what I need by modifying assembler? Maybe I missed 
some of your points. Could you give more details?

Thanks,
Sean


>
>    Simon


><< signature.asc >>

_________________________________________________________________
DonÂ’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

Re: develop a 'customized ld'

[sean yang]

>From: Ravi Ramaseshan <ramaseshan.ravi@gmail.com>
>Reply-To: ramaseshan.ravi@gmail.com
>To: sean yang <seanatpurdue@hotmail.com>
>Subject: Re: develop a 'customized ld'
>Date: Sun, 11 Sep 2005 01:52:23 -0400
>
>Hi,
>
>On 9/11/05, sean yang <seanatpurdue@hotmail.com> wrote:
> > I would like to collect the information of call to some libc functions. 
>I am
> > not going to use it in the program itself but I am going to use it in a
> > system  tool to watch the program's special calls.
>
>So why do you want to do it in the linker ? Why not work on the
>disassembly instead ?
~~~~~~~~~~~~~~~Thanks for this comment. Yes, a "perfect" disassembler will 
give me what I want. But I think disassemblers such as objdump are not 100% 
reliable.
For example, objdump gives wrong interpretation of a piece of code in libc 
under redhat.
Location:     Mem Contents             Disassembly Results

0x809ef45: eb 3c                          jmp 0x809ef83
0x809ef47: 00 00                         add %al, (%eax)
0x809ef49: 00                              add %al,
0x809ef4a: 83 ee 04 83 ee            0xee8304ee(%ebx)
0x809ef4f: 04 83                          add $0x83, %al
...
0x809efaa: 73 9e                          jae 0x809ef4a

starting at 0x809ef47, three NUL bytes of data (0x00) were inserted to push 
the loop header at address forward, presumably for alignment purposes. The 
NUL bytes and subsequent instructions are misinterpreted by the utility 
objdump. The error is observable: the add at address 0x809ef49 references an 
absolute memory location that does not even appear in the scope of 
executable! The instruction sequence is clearly invalid.

My goal is to fully automatically identify these call sites (as opposed to 
reverse-engineering other's code, in which case human intelligence will help 
to resolve the imprecise results of disassembler).
I understand the analogy of using assembler/linker and using disassembler is 
like observing a tree with our eyes and observing a picture of a tree: we 
have exact and enough information when using assembler/linker --a 3-D tree 
in the analogy case; we have an image which loses a lot useful information 
when using disassembler.


>--
>Ravi Ramaseshan
>
>" Reality is only something we believe in strongly. "

_________________________________________________________________
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement