0

I using x86dbg and am working on unpacking a target. The unpacking stub appears to be using some anti-debugging techniques - most of which I can detour with a plugin.

However, there are a lot of occurrences of rdtsc in the code. The code is being generated / unpacked throughout execution so I cannot simply search for all instances of the instruction.

I have tried running a trace with a condition to break when rdtsc is found but it is simply way to slow and tedious; especially since rdtsc is sometimes used in loops and it isn't as simple as just noping them out since a comparison takes place much later in the stub (it is also hard to identify where due to the excessive junk code.)

Any help would be greatly appreciated,

Thanks.

Improve this question

1 Answer 1

Reset to default
2

there are a few fake rdtsc drivers floating around

or if you have windbg attached in kernel mode you can toggle cr4.TSD bit and catch the exception iirc there is a script floating for that too but a fleeting google didn't land me that now ill link it later

edit anti rdtsc windbg script by vallejocc

here is a small demo 

kd> r cr4
cr4=00000699

kd> r cr4 = 69d
kd> r cr4    
cr4=0000069d
kd> g    

 *** Unhandled exception **0xc0000096**, hit in C:\Windows\system32\svchost.exe -k netsvcs:

 *** enter .exr 03C0F78C for the exception record
 ***  enter .cxr 03C0F7A0 for the context
 *** then kb to get the faulting stack

Break instruction exception - code 80000003 (first chance)
ntdll!RtlUnhandledExceptionFilter2+0x2ab:
001b:7743d10d cc              int     3

kd> .exr 03C0F78C
ExceptionAddress: 6dbb1358
   ExceptionCode: c0000096
  ExceptionFlags: 00000000
NumberParameters: 0

kd> .cxr 03C0F7A0
eax=1d218944 ebx=00000000 ecx=1ee17334 edx=0000021a esi=042708e0 edi=00000000
eip=6dbb1358 esp=03c0fa84 ebp=03c0fb08 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010246
001b:6dbb1358 0f31            rdtsc  <<<<<<
kd> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 03c0fb08 6dbb150f 04270808 002767b0 03c0fb3c 0x6dbb1358
Improve this answer
2
  • Thanks for this response. I think I am going to go the driver route at this point and if it causes some head-aches I may escalate to a kernel mode debugger. Thanks. I am looking at using this driver here deroko.phearless.org/ring0.html
    – Jeremy
    Commented Mar 3, 2018 at 20:44
  • i edited the post to include the antirdtsc winsbg script's link derokos fakerdtsc is fine
    – blabb
    Commented Mar 4, 2018 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.