Defeat QueryPerformanceCounter as Anti-Debugging trick

Question

The sample I try to analyze starts with PUSHAD. It begins with:

   PUSHAD
   MOV ESI, unbr002.0109D000
   LEA EDI, DWORD PTR DS:[ESI+FFEA4000]
   MOV DWORD PTR DS: [EDI+208C04], 8C1FE
   PUSH EDI
   OR EBP, FFFFFFFF
   JMP SHORT unbr002.0117C2EA
   NOP
   NOP
   ....

What I did: First, I try the ESP trick (step over PUSHAD, double-click on ESP -> Follow in Dump etc. ) which does not work. Then, I search the counterpart of PUSHAD, the POPAD instruction and put a breakpoint on it. After that, I click on F9 to run the program until the BP is hit. Then I saw this:

  POPAD
  LEA EAX, DWORD PTR DS:[ESP-80]
  PUSH 0
  CMP ESP, EAX
  JNZ SHORT unbr002.0117C4BC        a)
  SUB ESP, -80
  JMP unbr002.01048A05              b) 
  JMP SHORT unbr002.0117C4CC
  PUSH ESI
  MOV ESI, unbr002.010961A4
  CLD
  LODS DWORD PTR DS:[ESI]
  TEST EAX, EAX
  JE SHORT unbr002.0117C4E5
  PUSH 3
  POP ECX
  PUSH DWORD PTR SS:[ESP+10]
  LOOPD SHORT unbr002.0117C4D3
  POP ESI
  RETN 0C
  DB 00
  DB 00
  .....
  .....

So, I know that after POPAD, a so called tail jump will come to bring me to the OEP. When I go to a) nothing happens, I mean the jump is not taken.

When I go to b), (I did not step over/into, only click on ENTER) then it jumps to the following place:

 CALL unbr002.01055C47

Here, I also look into the function at 01055C47 which looks like this(I will only type the relevant part of this because the function is too big):

 .....
 CALL DWORD PTR DS:[109407C]       kernel32.GetSystemTimeAsFileTime
 MOV ESI, DWORD PTR SS:[EBP-4]
 XOR ESI, DWORD PTR SS:[EBP-8]
 CALL DWORD PTR DS:[10940F4]       kernel32.GetCurrentProcessId
 XOR ESI, EAX
 CALL DWORD PTR DS:[10940E0]       kernel32.GetCurrentThreadId
 XOR ESI, EAX 
 CALL DWORD PTR DS:[10942BC]       kernel32.GetTickCount
 XOR ESI, EAX
 LEA EAX, DWORD PTR SS:[EBP-10]
 PUSH EAX
 CALL DWORD PTR DS:[109442C0]      kernel32.QueryPerformanceCounter
 ...
 ...
 ...

So, from other sources I have read that these functions above GetTickCount, etc. are anti-debug tricks. But I could not find a way to defeat them. So, look at b) again. Now, when I step over the JMP instruction at b) then the process is terminated.

my question: What must I do to handle that problem?

PS: a) I have the ollydbg plugin OllyAdvanced, and I have checked the box TerminateProcess in ollyAdvanced without a success. b) I also know that it is packed with UPX, but I try to make my own learn process a little bit harder and for that reason I try to manuelly unpack it

best regards,

Answer 1

 .....
 CALL DWORD PTR DS:[109407C]       kernel32.GetSystemTimeAsFileTime
 MOV ESI, DWORD PTR SS:[EBP-4]
 XOR ESI, DWORD PTR SS:[EBP-8]
 CALL DWORD PTR DS:[10940F4]       kernel32.GetCurrentProcessId
 XOR ESI, EAX
 CALL DWORD PTR DS:[10940E0]       kernel32.GetCurrentThreadId
 XOR ESI, EAX 
 CALL DWORD PTR DS:[10942BC]       kernel32.GetTickCount
 XOR ESI, EAX
 LEA EAX, DWORD PTR SS:[EBP-10]
 PUSH EAX
 CALL DWORD PTR DS:[109442C0]      kernel32.QueryPerformanceCounter
 ...

So, from other sources I have read that these functions above GetTickCount, etc. are anti-debug tricks.

The code above is not being used as an anti-debug trick, but rather to calculate a security cookie (also known as a canary).

See https://books.google.com/books?id=aidqstv38G8C&pg=PA167 for a decompilation of the code above, and Compiler Security Checks In Depth for more information on security cookies as implemented in Microsoft's Visual C++ compiler.