Anti-debugging exercises

PEB tricks, and more

The binary we will be analyzing is from the Practical Malware Analysis book and is available at http://ccom.uprrp.edu/~rarce/ccom4995/misc/Lab16-01.exe. It will not modify or harm your Windows VM. This lab is an adaptation of Lab16-1 from the book.

  1. In the class presentation we saw that one of the techniques that malware uses to detect if its being run by the debugger is by reading the Process Environment Block (PEB) at fs:[30h]. Offset +2 is the first that is checked by the Lab16-01.exe binary. What PEB field is at that offset?

  2. Under what conditions is the first call to sub_4010000 (at address 0x0040356E) made?

  3. The code block that begins at address 0x403573, also accesses the PEB. What field of the PEB is read this time?

  4. Under what condition is the second call to sub_4010000 (at address 0x0040358F) made?

  5. The code block that begins at address 0x403594, also reads the PEB. What field of the PEB. is read this time?

  6. Under what condition is the THIRD call to sub_4010000 (at address 0x004035B0) made? is executed if:

  7. Lab16-01.exe is just a toy malware, but just in case something goes wrong with its contents, create a copy of the file Lab16-01.exe before the next step.

  8. Lets find out what sub_4010000 does, using dynamic analysis. Open Lab16-01.exe in OllyDbg (in your Windows 2008 VM). Put a breakpoint in the first CALL to sub_4010000, then click the run button on OllyDbg. Did the execution hit the first CALL sub_4010000?

  9. Use your breakpoint/step into/ step abilities to execute the program until just before the call to ShellExecuteA (in the sub_4010000) . Inspect the parameters that are being sent to ShellExecuteA. Explain what is the intention of that call. (Hint: https://stackoverflow.com/questions/515309/what-does-cmd-c-mean)

  10. How could you make OllyDbg avoid the traps set by the malware? You could change the control flow of the program by patching the jumps. Alternately you could manually modify the values of the fields that the program is checking within the PEB. Since verifying the PEB is a common anti-debugging technique, some kind programmers have created plugins that allow OllyDbg to "fool" the anti-debugging malware. The PhantOm plugin is one of them.

  11. Install the PhantOm plugin from https://tuts4you.com/e107_plugins/download/download.php?view.1276. Unzip the downloaded file and copy the DLL into the same directory as OllyDbg executable. Rerun OllyDbg and activate the plugin by going to: Plugins -> PhantOm -> Options -> Hide from PEB. Put breakpoints in the CALLS to sub_4010000. PhantOm was designed to work in Windows XP. Some of the locations for PEB fields have changed, so in Windows 2008 PhantOm may protect against only some PEB anti-debugging tricks. Which of the following was PhantOm capable of avoiding?

  12. Patch the conditional jump(s) that are leading the program to CALL sub_4010000 during the first three checks on the PEB. Also put a breakpoint on ther first instruction of sub_4010000 to monitor when it is called. Once you have activated PhanOm and patched the conditional jump(s), restart and run the program through the debugger (you may need to enter the Patch window to re-patch the conditional jumps). You will find out that you are not able to avoid calling the sub_4010000 by managing those three initial PEB reads. Explain why.

  13. Besides verifying the PEB fields, describe at least one other situation that leads this program to call sub_4010000?


A little TLS to ruin your RE day

The binary for this part is also from the Practical Malware Analysis book and is available at http://ccom.uprrp.edu/~rarce/ccom4995/misc/Lab16-02.exe. It will not harm or modify your Windows VM.

  1. Make sure that you are not currently running any OllyDbg windows. Run Lab16-2.exe from the command line. What message is displayed?

  2. Now open Lab16-02.exe in OllyDbg. Notice that it immediately displays Terminated in red font at lower right corner, without giving you a chance to even run the program. This is due in part to the malware setting a TLS callback. Can you find the callback function? (hint: use the [M] button in OllyDbg or find the TLSCallback_0 function in IDA). What is the address the TLSCallback_0 function?

  3. Explain what happens in the TLSCallback_0 function which explains why the program immediately terminates in OllyDbg.

  4. How would you patch the program so that the TLSCallback_0 function does not call exit? In order to perform the patch you need to at least be able to open the Lab16-02.exe without trying to go through the TLSCallback_0 function. To do this: Options - Debugging options - Events: set Make first pause = System breakpoint.

  5. Perform the patch and put a breakpoint in the main function to validate that now your program at least arrives at the main function.

  6. Statically analize the main function and deduce its pseudocode.

  7. The main function decides wether to print a success or failure message based on a comparison with a string at byte_408030? Where is this string assigned its value?

  8. Use OllyDbg (with properly placed breakpoints) to execute the binary to determine what is the parameter that will make the program output "You entered the correct password!". (use Debug - > arguments to pass command line arguments to the debugged program in OllyDbg). Briefly explain how you found the password.