0

during an analysis, I have found the following :

  ...
  call program.00401535
  ...
  (a few lines later)
  ...
  ...
  call program.00401535
  ...
  ...

So, it call the same function. When I step over that first call, nothing happens. But later, when I step over the second call, suddenly I get the message "000004C0 terminated, exit code 0" and ollydbg is running, running...and running. So, I have decided to look into that function and I see the following:

                    PUSH EBP
                    MOV EBP, ESP
 00401538           PUSH 1000
     |              CALL DWORD PTR DS:[40241C]    ; which is kernel32.Sleep
     -------------- JMP  SHORT program.00401538
                    LEAVE 
                    RETN

So, it is simple what it is doing here. Since we have unconditional jump, it always lets the program sleep for a while. In other words, that function should never return.

But my question would be: Why it was possible for me to step over the first call, and not over the second ? I googled for Sleep() as anti-debugging trick but I did not find anything about that. Can somebody tell me what can I do in such a case?

best regards,

1

Are you sure the contents of DS:[40241C] haven't been changed between the first and the second call? Maybe it's not the sleep function called at all, at the first time.

Something like

....
fptr=generateException;
ExceptionReturnOrEndleesLoop();
if (shenanigans) {
    fptr=sleep;
    ExceptionReturnOrEndlessLoop();
}

ExceptionReturnOrEndlessLoop() {
    for (;;) {
        try {
            (*fptr);
        } catch  (someexception Ex) {
            return;
        }
    }
}

Or even, have the function pointer refer sleep() all the time, but create a second thread that waits for exactly 500 ms, then interrupts the main thread (and the sleep, thus causing an exception). If you're singlestepping, the interrupt will occur before the sleep() gets executed, and the exception handler won't ever get executed.

  • To start digging, you can break on TerminateProcess, TerminateThread and analyse the stack. This will help to find what thread/code is responsible to nock you out. – PhoeniX Jan 12 '15 at 8:58
0

This is a possible scenario in a multithreaded application. Here the anti-debugging check is run in a dedicated thread. When the main thread calls Sleep, it means that it is giving up cpu-time so that the other thread have higher chances to execute.

To debug such an application in Ollydbg, look in the threads Window. If you find another thread running, you need to analyze it too.

  • Just to add to the above, in Options->Debug->Events menu, you can ask to break on every new thread to ensure that you will not miss anything. You will likely to do it in several inebriations to find the "bad" thread. – PhoeniX Jan 12 '15 at 8:56

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.