naides
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:
But if I trace into the call f7(Which the normal flow of program execution will do ) we arrive a this little snippet
means that when we return the actual code that is executed is:
A few hundred of these trace traps over the code makes tracing this baby a pain in the ass!
This is the way it does it: peppered throughout the code you find something like this:
Code:
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
Code:
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:
Code:
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!