View Full Version : A cute anti-tracing trick

November 5th, 2007, 13:44
I have been tracing this app, which had the irritating tendency to escape the debugger and run to execution.

This is the way it does it: peppered throughout the code you find something like this:

11001857 55 PUSH EBP
11001858 8BEC MOV EBP,ESP
1100185A 51 PUSH ECX
1100185B 53 PUSH EBX
1100185C 56 PUSH ESI
1100185D 57 PUSH EDI
1100185E E8 72F9FFFF CALL XXXXXXX.110011D5 ; If I trace over this call with F8 the program takes off

11001863 -E9 6A006A00 JMP 116A18D2
11001868 FF15 C0180011 CALL DWORD PTR DS:[<&KERNEL32.GetModuleH>; kernel32.GetModuleHandleA
1100186E 50 PUSH EAX
1100186F E8 06FDFFFF CALL mc2_eval.1100157A
11001874 59 POP ECX
11001875 59 POP ECX

But if I trace into the call f7(Which the normal flow of program execution will do ) we arrive a this little snippet

110011D4 C3 RETN
110011D5 FE0424 INC BYTE PTR SS:[ESP] ; Quick and elegant
110011D8 C3 RETN

means that when we return the actual code that is executed is:

11001864 6A 00 PUSH 0 ; This instruction used to be 11001863 -E9 6A006A00 JMP 116A18D2, but now the EIP has updated to 11001864
Tricking Olly, who had placed the trace-over breakpoint at 11001863 -E9

11001866 6A 00 PUSH 0
11001868 FF15 C0180011 CALL DWORD PTR DS:[<&KERNEL32.GetModuleH>; kernel32.GetModuleHandleA
1100186E 50 PUSH EAX

A few hundred of these trace traps over the code makes tracing this baby a pain in the ass!

November 5th, 2007, 13:49
Nice find naides.


November 5th, 2007, 15:16
It is used in Thinstall Virtual OS loader.

November 5th, 2007, 17:54
Is there something more? Or, is it always the same trick (inc,ret combination)? In this case you should be able to solve the problem writing a simple script. Don't know, removing the call with a "jmp $+6" instruction...

November 5th, 2007, 18:53
Stone-age tricks are still effective, just like a stone-age club can still bash your head in.

November 5th, 2007, 19:38
Just write something to check if the call leads to inc dword ptr[esp], ret, and if so, nop it. There, 2 min. of annoyance.

November 5th, 2007, 23:06
Funny, I just happened to be browsing the ImmDbg site (not that I use it but I've been playing with Python lately) and found a discussion on this exact obfuscation trick and scripting to get around it.


November 10th, 2007, 03:13
@Extremist: Indeed, this sort of code has been around since the very first processors to have a stack/call/return instructions, it's nothing new. It's known as an "NRC" or Non-Returning-Call (in the sense that EF does not return to the instruction after the call) and can be useful for situations other than anti-tracing (jump table lookups come to mind).

Many variations of this are possible, like
; some code that sets eax to the requested destination goes here
call .do_nrc
jmps .dest_1
jmps .dest_2
jmps .dest_3

.dest_1 ; some code goes here
.dest_2 ; some code goes here
.dest_3 ; ...etc
lea eax [2*eax+eax]
add [esp] eax ; compute destination
I'm assuming the debugger isn't breaking because it's setting explicit breakpoints on where it "thinks" the next instruction would be, rather than using the single-step flag and continuing until it finds a return instruction, at which point it traces one more time to the instruction "after" the call (wherever that may be). This doesn't solve NRCs which truly never return (in which case "step over" _should_ run until a return), but better than the behavior here. In the example, tracing F8 over should result in the next instruction being at 11001864.

(Add this to OllyDbg 2.0?)