Results 1 to 6 of 6

Thread: OllyDbg trace gets "lost" in OS code

  1. #1

    OllyDbg trace gets "lost" in OS code

    I'm trying to trace through a piece of code in two different situations and see the point at which the execution traces diverge.

    For some reason, however, my traces seem to get lost while executing OS code: Olly traces on and on through a system DLL and then all of a sudden it finds itself on a breakpoint back in user code, having skipped a large number of instructions. For example:

    Code:
    004036A3 Main     push    0
    004036A5 Main     call    <jmp.&user32.GetKeyboardType>
    00403698 Main     jmp     [dword <&user32.GetKeyboardType>]
    GetKeyboardType   mov     edi, edi
    75A29AC6 Main     push    ebp
    75A29AC7 Main     mov     ebp, esp
    ...
    ... snip 20 thousand instructions
    ...
    77801003 Main     call    [dword fs:C0]
    73A92320 Main     jmp     far 0033:73A9271E
    759E60E2 Main     add     esp, 4
        Breakpoint at mycode.00575E5E
    00575E5E Main     mov     ebp, esp
    See what happens there at the end: the trace stops at the "add" for some reason, after successfully tracing quite a bunch of OS code, and never really resumes until it hits a breakpoint.

    Why is this happening and how can I fix this?
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  2. #2
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,456
    Blog Entries
    15

    77801003 Main call [dword fs:C0]
    thats weird you probably have some hooks somewhere (keylogger ??? )

    GetkeyBoardType is a Fairly simple Function it doesnt call any far pointers in fs segment

    Code:
    lkd> uf /c USER32!GetKeyboardType
    USER32!GetKeyboardType (7e4311db)
      USER32!GetKeyboardType+0x5e (7e431203):
        call to USER32!NtUserCallOneParam (7e4184ae)
      USER32!GetKeyboardType+0x23 (7e44a124):
        call to USER32!GetClientKeyboardType (7e45602f)
    lkd> uf /c USER32!NtUserCallOneParam
    USER32!NtUserCallOneParam (7e4184ae)
      USER32!NtUserCallOneParam+0xa (7e4184b8):
        unresolvable call: call    dword ptr [edx]
    lkd> uf /c USER32!GetClientKeyboardType
    USER32!GetClientKeyboardType (7e45602f)
      USER32!GetClientKeyboardType+0x50 (7e45607f):
        call to USER32!WinStationQueryInformationW (7e46e2f5)
      USER32!GetClientKeyboardType+0x8f (7e4560be):
        call to USER32!__security_check_cookie (7e418674)
    lkd> uf /c USER32!WinStationQueryInformationW
    Flow analysis was incomplete, some code may be missing
    USER32!WinStationQueryInformationW (7e46e2f5)
      USER32!_tailMerge_WINSTA+0x8 (7e46e2e7):
        call to USER32!__delayLoadHelper2 (7e43d0b0)
    fs:[c0] in xpsp3 is Wow32 Reserved ptr what os are you using

    Code:
    lkd> dt nt!_Teb /n /v Wo*
    struct _TEB, 66 elements, 0xfb8 bytes
       +0x0c0 WOW32Reserved : Ptr32 to Void

  3. #3
    Quote Originally Posted by blabberer View Post
    thats weird you probably have some hooks somewhere (keylogger ??? )
    I do actually have a low-level hook set by a program I wrote for myself, but this happens with lots and lots of other APIs; this one is just a random example. I suppose my antivirus might also have some hooks set.

    Do you think this is because of hooks then? Are there reasons why Olly would be thrown off by a hook, and/or unable to trace through the hook's code?
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  4. #4
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,456
    Blog Entries
    15
    ollydbg is capable of tracing through os code with a few exceptions

    if trace goes into SysCall viz sysenter, int2e , int2b etc it cant get back to the immediate next instruction

    since you havent replied i will edit this post scroll down to end

    as it is not knowable in advance (system returns back by ZwContinue in most cases and a context structure that holds the continue EIP is used in the cases)

    in your case you may need to set a few breaks viz at that add esp,4 etc break physically and single step manually to understand what is happening

    also from your trace it seemshe code is spanning over a few modules

    where does the far pointer point to
    is ollydbg set to pass exceptions automatically ?
    can you follow though without tracing this far pointer
    i cant give a definitive opinion whether what you see is a problem or not with the info i have in hand



    end edit

    the fs:[co] call seems to be a syscall in x64

    Code:
    However, an examination of the Wow64 ntdll shows something different; a call is made through a field at offset +C0 in the 32-bit TEB:
    
    0:000> u ntdll!NtClose
    ntdll!ZwClose:
    mov     eax,0Ch
    xor     ecx,ecx
    lea     edx,[esp+4]
    call    dword ptr fs:[0C0h]
    ret     4
    
    http://www.nynaeve.net/?p=131
    
    
    Not sure if anyone is still interested, XP x64 SP2 and Vista x64 SP1 may use something like:
    
    7D61CFAC ZwCreateFile
    MOV EAX,52
    XOR ECX,ECX
    LEA EDX,DWORD PTR SS:[ESP+4]
    CALL NEAR DWORD PTR FS:[C0]
    RET 2C
    
    at FS:[C0] lies a far jmp, eg:
    JMP FAR 0033:78B83C2C
    
    Itís quite convenient that all functions seem to call a common point to dispatch syscalls.
    
    http://opcode0x90.wordpress.com/2007/05/18/kifastsystemcall-hook/
    so yes since ollydbg is passing through a syscall hoop once it reaches back to from syscall it will run and will stop only a breakpoint is hit

    you can check this thread for some ideas ( i dont have an x64 so cant vouch if the tricks works still)

    http://www.woodmann.com/forum/showthread.php?11550-Tracing-Over-System-Calls-In-OllyDbg
    Last edited by blabberer; January 29th, 2012 at 09:53.

  5. #5
    Quote Originally Posted by blabberer View Post
    ollydbg is capable of tracing through os code with a few exceptions
    if trace goes into SysCall viz sysenter, int2e , int2b etc it cant get back to the immediate next instruction
    ...
    so yes since ollydbg is passing through a syscall hoop once it reaches back to from syscall it will run and will stop only a breakpoint is hit
    That sounds spot-on. This is indeed an x64 system (though the debuggee and the debugger are running in 32-bit mode). Good to know about olly tracing capabilities; I've had this a few times before and I didn't know if it was a bug, a genuine limitation, or me doing something wrong.

    Also, excellent link, thank you! It reminded me of "trace over system calls", which I initially discarded for "not working", then discovered the thing about system modules (olly on x64 doesn't recognize all system modules correctly as such, apparently), and then promptly forgot about all of that.
    Last edited by romkyns; January 29th, 2012 at 11:55.
    I promise that I have read the FAQ and tried to use the Search to answer my question.

  6. #6
    Super Moderator
    Join Date
    Dec 2004
    Posts
    1,456
    Blog Entries
    15
    check the plugin in this thread and see if there are any improvements

    http://www.woodmann.com/forum/showthread.php?11550-Tracing-Over-System-Calls-In-OllyDbg&p=91811#post91811

    may be yoou can try typing something like below in the sequence dialog box
    and then use runtrace


    Code:
    mov EAX,CONST
    xor ECX,ECX
    lea     edx,[esp+4]
    call    dword ptr fs:[0C0h]

Similar Threads

  1. Replies: 0
    Last Post: February 22nd, 2008, 19:30
  2. Terminal Dogma: "the whole crackme is ANTI trace!"
    By ZaiRoN in forum Mini Project Area
    Replies: 11
    Last Post: December 1st, 2006, 19:23
  3. Replies: 2
    Last Post: May 22nd, 2005, 05:25
  4. Question to: "trace over system dll"
    By Anonymous in forum OllyDbg Support Forums
    Replies: 3
    Last Post: February 13th, 2005, 04:17
  5. tsehp : small "anti-trace" in asprotect..?
    By nikolatesla20 in forum Advanced Reversing and Programming
    Replies: 7
    Last Post: April 12th, 2002, 18:42

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
  •