Results 1 to 8 of 8

Thread: A cute anti-tracing trick

  1. #1
    Naides is Nobody
    Join Date
    Jan 2002
    Location
    Planet Earth
    Posts
    1,647

    A cute anti-tracing trick

    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:

    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!

  2. #2
    Nice find naides.

    Regards,
    JMI

  3. #3
    Registered User
    Join Date
    Aug 2005
    Location
    Greece
    Posts
    157
    It is used in Thinstall Virtual OS loader.
    A picture worth 1K words (or .5K DWORDS).

  4. #4
    Red wine, not vodka! ZaiRoN's Avatar
    Join Date
    Oct 2001
    Location
    Italy
    Posts
    922
    Blog Entries
    17
    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...

  5. #5
    Stone-age tricks are still effective, just like a stone-age club can still bash your head in.

  6. #6
    Registered User
    Join Date
    Dec 2005
    Posts
    216
    Blog Entries
    5
    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.

  7. #7
    Teach, Not Flame Kayaker's Avatar
    Join Date
    Oct 2000
    Posts
    4,143
    Blog Entries
    5
    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.

    http://forum.immunityinc.com/index.php?topic=34.0

  8. #8
    @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
    Code:
     ; 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
    ...
    .do_nrc
     lea eax [2*eax+eax]
     add [esp] eax ; compute destination
     ret
    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?)

Similar Threads

  1. An anti-attach trick.
    By walied in forum Malware Analysis and Unpacking Forum
    Replies: 7
    Last Post: December 20th, 2011, 14:37
  2. some anti-disassembler trick ?
    By NoLOcKs in forum OllyDbg Support Forums
    Replies: 2
    Last Post: May 13th, 2009, 17:00
  3. # JL/JGE Intel CPU bug as anti-reversing trick
    By nezumi-lab in forum Blogs Forum
    Replies: 2
    Last Post: March 1st, 2009, 20:20
  4. Does asprotect have anti-tracing code???
    By padawan in forum The Newbie Forum
    Replies: 2
    Last Post: February 23rd, 2004, 16:50
  5. In Win2K how to defeat the anti-debug trick of ASProtect?
    By Solomon in forum Malware Analysis and Unpacking Forum
    Replies: 13
    Last Post: December 20th, 2002, 09:50

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •