Anti Debugging tricks and Control Flow obfuscations
Saturday, December 07, 2013 | Author: Deep Flash
Recently while analyzing a virus, I came across an interesting sample. It is a package of several anti debugging, anti sandbox and control flow obfuscations tricks. All these are used to deter the reverse engineering.

Let us discuss them one by one:

It invokes certain subroutines by triggering an exception. It first registers an exception handler. Then it decrypts the code of that exception handler. Once this is done, it triggers an exception by executing a privileged instruction like CLI and STI (both these instructions are privileged in the protected mode).

Since an exception is triggered, the corresponding exception handler from the SEH chain will be invoked. This is a control flow obfuscation trick. Below screenshot shows an exception triggered after executing the CLI instruction. On the stack we can see the exception handler address as: 0x00401610. To continue the analysis in Olly Debugger, we can press, Shift + F9 and pass the exception to the exception handler or we can just set the EIP to 0x00401610.

Inside this handler, it uses a well known anti debugging trick. It checks the value of BeingDebugged field of PEB (Process Environment Block), at offset 0x2. If the program is being debugged, then this field is set to 0x1. There are Olly Debugger plugins available which will patch this value in the PEB structure to protect from such anti debugging tricks. If you do not have the plugin, you can just patch the conditional jump after the comparison.

The below screenshot shows the encrypted code of the exception handler at address, 0x00401577. The decryption routine is an easy single byte XOR decryption routine. Once decrypted, we find an INT 2D instruction after the LOOPD instruction.

INT 2D has a special behavior in Olly Debugger. Olly will skip the next byte in execution as a result of which the control flow is obfuscated. We need to manually set the EIP to the exception handler code at: 0x00401577.

Inside the second exception handler, it again uses a well known anti debugging trick by checking the value of NtGlobalFlags inside the PEB at offset 0x68. If this value is set to 0x70, then the program is being debugged. Once again, there are plugins available to patch these fields in the PEB structure.

Now, it decrypts the code of the third exception handler which is invoked using another privileged instruction, STI.

Inside the third exception handler, it uses the strstr() function to find the substring, "sample" inside the full path name of the virus.

Though this trick is simple, it can be effective since many malware analysts set the name of the virus or the folder in which they store it, as "sample". If it finds this substring, it exits the process using ExitProcess().

The next trick checks the volume serial number of C: Logical Drive by calling GetVolumeInformation(). It compares the volume serial number with: 0x0CD1A40 and 0x70144646. If either of these matches are true, it exits the process.

00401160   817D 00 401ACD00 CMP DWORD PTR SS:[EBP],0CD1A40
00401167   74 09            JE SHORT gvtfifjh.00401172
00401169   817D 00 46461470 CMP DWORD PTR SS:[EBP],70144646
00401170   75 05            JNZ SHORT gvtfifjh.00401177

Next, it queries the following registry key to get information about the Disk.


For example, in the case of VMWare the value of the subkey, "0" is set to:


This string is converted to lowercase and then using the strstr() function, it checks for the presence of following substrings inside the above string:

1. xen
2. vmware
3. virtual
4. qemu

If it finds any match, then it exits the process.

In the next trick, it tries to get the module handle for dbghelp.dll and sbiedll.dll files using GetModuleHandleA. If the module handle is returned, then it exits the process. These DLL files are used by common sandboxes like Sandboxie and ThreatExpert.

It also uses a recently discovered bug in Olly Debugger where it does not break at the exception handler when we trigger an exception by calling RaiseException() with the exception code, 0x80000003.

It first registers an exception handler which has the malicious subroutine code and then triggers the exception by calling RaiseException.

In this case, we can manually set the EIP to 0x0040126D as shown below and continue debugging from there:

This entry was posted on Saturday, December 07, 2013 and is filed under . You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.