1

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,

3
 .....
 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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