📚 OpenRCE is preserved as a read-only archive. Launched at RECon Montreal in 2005. Registration and posting are disabled.








Flag: Tornado! Hurricane!

 Forums >>  Debuggers  >>  Detours

Topic created on: November 8, 2006 11:52 CST by morphique .

I have just used detours instead of breakpoint handler in order to intercept functions in binary. It's pretty fast.
These days brekpoint handler technique is quite common in order trace execution path. Setting breakpoint on functions and then intercept them thorugh EXCEPTION_HANDLER_BREAKPOINT routine for eg. what pedram has done in pydbg.

Does anyone know of any disadvantage of using trampoline function or detour function over breakpoint handler technique?

Cheers
M

  pedram     November 9, 2006 16:04.32 CST
No disadvantage as far as I know. In fact it's probably a better technique as there is no possibility for debugger detection. The hook-via-breakpoint technique was just easier to do in PyDbg given the available functionality.

Perhaps someone should write and submit a detours style hooking library for PaiMei ;-)

  halvar     November 12, 2006 12:37.39 CST
> pedram: No disadvantage as far as I know. In fact it\'s probably a better technique as there is no possibility for debugger detection. The hook-via-breakpoint technique was just easier to do in PyDbg given the available functionality.
>
> Perhaps someone should write and submit a detours style hooking library for PaiMei ;-)

If someone wanted to screw with this, simple code-integrity-
checking would do, no ? ;)

On a related note: Detours-style might perform better
as no exception is thrown when a function is hit.

  gera     November 13, 2006 06:17.34 CST
> Perhaps someone should write and submit a detours style hooking library for PaiMei ;-)

It may be possible to integrate UHooker (http://oss.corest.com/projects/uhooker.htm, "Detours hooking in .py") into PaiMei. I haven't checked the code for UHooker though, so I don't know.

  morphique     November 13, 2006 10:07.40 CST
> It may be possible to integrate UHooker (http://oss.corest.com/projects/uhooker.htm, "Detours hooking in .py") into PaiMei. I haven't checked the code for UHooker though, so I don't know.

If I am not wrong, unhooker uses soft breakpoint technique.

  pedram     November 13, 2006 14:03.14 CST
> halvar: > If someone wanted to screw with this, simple code-integrity-checking would do, no ? ;)

Most definitely. But at least the whole anti-debugger detection surface is removed. I also originally wanted to mention that speed wise its faster, forgot to include that in my original response.

  LordTerror     November 29, 2006 13:21.04 CST
The problem with jmp/call hooks is that the next 4-5 bytes are filled with data that could crash a process if executed.  Because of this, jmp/call hooks are unsuited for general purpose breakpoints.  They woud be a useful addition to a debugger, though.

  Sirmabus     January 20, 2007 20:02.31 CST
As a general hook method, JMP hooks are have next to no overhead (not considering the hook contents) if your detour/stubs are code aligned 32bytes (maybe 16 would work as well).

I did some RDTSC cycle timings on an AMD64 some time ago and found (over an avg of 1000 tests each):
1) JMP5 (0xE9 32bit relative offset opcode jump) � Lost the exact count, but unly a few cycles total (when aligned, around +~100 cycles when not).
2) int 3 w/single step restore - ~10800 cycles.
3) int 3 using stub to return - ~4600 cycles.

I assume a lot of the �int 3�/breakpoint overhead is from the standard (WinXP SP2 in this case) SEH, and not so much the processor/hardware steps involved.  Would be interesting to see how much of an improvement there would be to use a custom kernel driver to bypass the standard Windows SEH (and skip a few layers) for a targeted process.

And obviously the more hooks you have, and where they are located effect the overall speed factor.  I did this in a code profiling application.  Tens of thousands of JMP5�s caused next to no noticeable degradation, but �int 3� method even using dynamic stubs to return/continue (to skip the replace, single step part) made the target slow to a crawl making it nearly impossible for real time use.

Note: Registration is required to post to the forums.

There are 31,328 total registered users.


Recently Created Topics
[help] Unpacking VMP...
Mar/12
Reverse Engineering ...
Jul/06
let 'IDAPython' impo...
Sep/24
set 'IDAPython' as t...
Sep/24
GuessType return une...
Sep/20
About retrieving the...
Sep/07
How to find specific...
Aug/15
How to get data depe...
Jul/07
Identify RVA data in...
May/06
Question about memor...
Dec/12


Recent Forum Posts
Finding the procedur...
rolEYder
Question about debbu...
rolEYder
Identify RVA data in...
sohlow
let 'IDAPython' impo...
sohlow
How to find specific...
hackgreti
Problem with ollydbg
sh3dow
How can I write olly...
sh3dow
New LoadMAP plugin v...
mefisto...
Intel pin in loaded ...
djnemo
OOP_RE tool available?
Bl4ckm4n


Recent Blog Entries
halsten
Mar/14
Breaking IonCUBE VM

oleavr
Oct/24
Anatomy of a code tracer

hasherezade
Sep/24
IAT Patcher - new tool for ...

oleavr
Aug/27
CryptoShark: code tracer ba...

oleavr
Jun/25
Build a debugger in 5 minutes

More ...


Recent Blog Comments
nieo on:
Mar/22
IAT Patcher - new tool for ...

djnemo on:
Nov/17
Kernel debugger vs user mod...

acel on:
Nov/14
Kernel debugger vs user mod...

pedram on:
Dec/21
frida.github.io: scriptable...

capadleman on:
Jun/19
Using NtCreateThreadEx for ...

More ...


Imagery
SoySauce Blueprint
Jun 6, 2008

[+] expand

View Gallery (11) / Submit