Want an example on how to trampoline a system call?

[arking1981]

Dear experts:

I am reading interesting articles about something called trampoline, which can let you run your own code first when invoking a system call. For example, check the parameters passed to memcpy().

From what I read, I guess we should do it as:

1) locate memcpy() instruction in my binary

2) jmp to my memcpy_x() at the entry of memcpy() in my original binary; should keep the first 5 bytes for the context?

3) return to memcpy() after checking parameters

It looks straightforward, but I have not found an example or a guide with a little more details. 

The first problem is I don't know how to edit my binary in asm and locate memcpy() in the text segment(I think it should be in text seg or code segment). Then the memcpy should be dynamicly linked into my binary at run-time, how could I edit it? I am very fresh to this area, please tolerate my stupid questions. 

Please suggest.

Regards

Kang

[Dennis Handly]

What are you really trying to do?  gdb already provides heap leak and corruption checking by monitoring libc functions.

>which can let you run your own code first when invoking a system call. check the parameters passed to memcpy.

(memcpy(3) isn't a system call, it is a libc function call.)

>2) jump to my memcpy_x() at the entry of memcpy in my original binary; should keep the first 5 bytes for the context?

You are not allowed to rewrite instructions.  Instead you use shlib binding rules and interposition.  Then use dlopen and dlsym to find the real memcpy.

>The first problem is I don't know how to edit my binary in asm

You don't do that.

[arking1981]

Thanks Dennis.

@Dennis Handly wrote:

What are you really trying to do?  gdb already provides heap leak and corruption checking by monitoring libc functions.

>which can let you run your own code first when invoking a system call. check the parameters passed to memcpy.

(memcpy(3) isn't a system call, it is a libc function call.)

 [K] I am not going to hack something. Just want to understand how this works, maybe in future this can help me with my program to detect tough issues. yes memcpy is a libc call :). I just used it as an example, and I also may concern memset(), strcpy() and etc.

>2) jump to my memcpy_x() at the entry of memcpy in my original binary; should keep the first 5 bytes for the context?

You are not allowed to rewrite instructions.  Instead you use shlib binding rules and interposition.  Then use dlopen and dlsym to find the real memcpy.

[K] Understand there is shlib binding in the run-time, another interposition technique. But there should still be a possibility to modify opcode directly, isnt it? 

>The first problem is I don't know how to edit my binary in asm

You don't do that.

[K] ok, so how did other guys achieve this trick? I am so curious.

Thanks again, Dennis

---

[Dennis Handly · Accepted solution]

>[K] I am not going to hack something. Just want to understand how this works, and I also may concern memset(), strcpy() and etc.

Note: Some of these functions may be inlined by the optimizer.

>[K] But there should still be a possibility to modify opcode directly, isn't it?

This is architecture specific.  You also have to play games like java where you have to flush the caches to make sure the hardware knows you changed things.

>[K] so how did other guys achieve this trick? I am so curious.

You find the address.  Save off several bundles of instructions.  Add a branch to the new location.  You'll have problems if this is another load module.

Then after your function is done, put the parms back and execute the saved instructions and branch to the remaining code in the original function.  This is very difficult in practice.