OllyDbg trace gets "lost" in OS code

[romkyns]

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:

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?

[blabberer]

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

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

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

[romkyns]

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?

[blabberer]

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

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

[romkyns]

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.

[blabberer]

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

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