Dear readers, how are you? Few days I ago, I received a request to publish few tips about reversing. Unfortunately, my time for writing is almost zero, but I’ve been trying to do something and it is a quick write up explaining a simple anti-debugging trick.
Look at the following code lines from a malware below (the numbering is mine):
- 0040866A call $+5
- 0040866F pop ebp ;
- 00408670 lea eax, [ebp+54h]
- 00408671 inc ebp
- 00408673 push eax
- 00408674 xor eax, eax
- 00408676 push dword ptr fs:[eax]
- 00408679 mov fs:[eax], esp
- 0040867C int 3
- 00408694 nop
- 00408695 xor ebx, ebx
- 00408697 div ebx
- 00408699 pop dword ptr fs:0
Line 1: Although the call $+5 instruction appears to be complicated, it is calling the next instruction because $ means the current address (0x0040866A) and it is adding 5 = 0x0040866F. Furthermore, the call instruction pushes the next address , which it will be the return address (RET), onto the stack.
Line2: The pop ebp instruction saves the top stack content (exactly the RET=0x0040866F) into EBP register.
Line3: The lea (load effective address) instruction (lea eax, [ebp+54h]) only sum up values. Therefore, the eax register will hold the ebp value (0x0040866F) + 0x54 = 0x004086C3
Line 4: The instruction inc ebp increases ebp register by 1. Thus, ebp = 0x00408670.
Line 5: The push eax instruction pushes the eax value (0x004086C3) onto the stack. Looking ahead (at line 8), this address will be the address of an exception handler function.
Line 6: The xor eax,eax instruction makes eax=0.
Line 7 and 8: Both lines (push dword ptr fs:[eax] and mov fs:[eax], esp) set up an exception handler function by first “saving” the address of the current exception handler address onto stack and then copying the esp value (0x00408663) to FS register. Please, remember that Windows prepares the FS register to hold the base address address of the current TEB (Thread Environment Block). Additionally, the first item of this structure (which is at offset zero) is the head of a linked list of pointers to exception handler functions.
Line9: Purposely, the program generates an exception (through int 3 instruction), which is used by the debugger to implement a software breakpoint and, in this case, it causes a software trap (a kind of interrupt) to the debugger.
Therefore, if there was an attached debugger, it would take the control and it would be a terrible mistake because the int 3 instruction is a simple anti-debugging technique. The reason is that the malware expects to handle the exception (thus, the debugger should pass the exception to the malware) to dictate next steps of its operation, but if it doesn’t happen, so probably the program either will crash or make a strange thing.
Line 12: The xor ebx,ebx makes ebx =0.
Line 13: The div ebx instruction will trigger a division by zero and it is possible that the execution finishes. Note that the div ebx instruction is wouldn’t be executed whether the debugger had passed the exception to the malware (as it expects).
Line 14: The prior exception handler address (saved at line7) is restored from stack into the FS register through the pop dword ptr fs:0 instruction.
As a conclusion, the malware author configured an exception handler and forced the malware to trigger an exception to make additional steps (maybe changing registers and executing other instructions) during the exception handler function. If the analyst permit the debugger to catch the exception, so the malware won’t execute the intentioned steps and she/he won’t be able to understand the malware’s details.
Relax! I know that these few lines are very simple to analyze, but my intention it is to help students and beginners because the code above reflects a daily procedure of a malware analyst struggling against all kind of anti-forensic techniques (most them more complicated than this one).
Soon I will try to make a new and short post about malware analysis. Stay tuned.
I hope you have a nice day and…keep reversing. 😉
(LinkedIn: http://www.linkedin.com/in/aleborges and twitter: @ale_sp_borges)