Anti-disassembler techniques 2019

Recommendations:

• When you are dealing with assembly that has been handcrafted to confuse the disassembler, it is usefull to look at the machine language bytes of each instruction or data. You can activate this by: Options - General - Number of opcode bytes (non-graph) set to 6.

In this lab we will be analyzing a PE binary that uses anti-disassembly techniques to hide its true evil nature. It is classified as malware by virustotal.com, however we will only be doing static analysis from linux, so no worries.

This lab is an adaptation of Lab 15-3 from the awesome "Practical Malware Analysis" book.

1. Download the executable available at http://rarceresearch.fun/misc/Lab15-03-pr.exe. Perform static analysis using IDA Pro to follow the steps below and answer the questions.

2. The code imports some functions that can be used for dubious purposes. For instance, a call to URLDownloadToFileA might be used to download a malware executable file from a website, then WinExec can be called to execute the malware. Just as evidence that you accesed the Imports view: what is the name of the Library that contains the function URLDownloadToFileA.

3. Examine the calling functions to URLDownloadToFileA by double clicking on its name on the Imports, then choosing 'Xrefs graph to' on the IDA View-A. Does the graph illustrate a path from the main function to URLDownloadToFileA?

   What name did IDA give to the function that calls URLDownloadToFileA?

   According to IDA, does any function invoke the function that then invokes URLDownloadToFileA?

4. Lets go back to the main function and use your anti-disassembly knowledge to try to understand how the seemingly harmless main ends up calling other malicious subroutines.

5. When IDA paints text in a red background, it usually means it found something fishy. The instruction at address 0x401016 is mov [ebp + 4], eax and was painted red by IDA.

   

   The instruction mov [ebp + 4], eax is fishy because it will rewrite main's return address, i.e. when main ends, it will jump to the new adress that was written to [ebp+4] instead of the function that really called main. What is the address being written to [ebp+4]?

6. Explore the function at the address where the main will return. It contains a jmp that was marked by IDA as suspicious:

   

   1. Examine the two instructions before the jmp near ptr 4054D503h. Explain the disassembly trick that is being used.

   2. Use the d and c keys to turn the code into something more meaningful, i.e. to correctly identify what is data and what are instructions. What is the first instruction after the db 0E9h?

7. The two instructions after the db 0E9h are part of another anti-disassembly plot. What are they doing?

8. What exception is forced by the instructions that follow, which cause the flow to jump to the subroutine at 0x004014C0?

9. Did IDA initially identify the content of address 0x004014C0 as instructions or data?

10. Use c or d to turn 0x004014C0 into its right interpretation (instructions).

11. The first instructions at 0x004014C0 removing the exception record from the linked list (notice the references to fs:0). What comes next is the instruction:

    

    Notice the red message. Once again this is IDA telling something's fishy. The instruction itself seems a bit odd: the jump target is the address of the second byte of the jump instruction! But IDA cannot interpret two instructions from the same bytes. Lets help IDA by converting the byte at 0x004014D7 to data, and the bytes starting at 0x004014D8 to code. What is the instruction at 0x004014D8?

12. Now give the sequence of subroutines beggining with main that are invoked to eventually call URLDownloadToFile.

13. From what URL is a file downloaded? The subroutine sub_401534 uses a simple XOR deciphering scheme which translates each byte by XORing it with 0xFF. Instead of painfully translating each byte by hand, you can use IDA's scripting habilities. Double click on the first string that is passed as parameter to sub_401534 so that you are looking at a weird byte sequence:

    

    Now run the following script using File -> Script Command:

    #define here  get_screen_ea()
    
    static main(){    
        auto i = 0;
        while (byte(here + i) != 0xff) {
          Message("%c", byte(here + i) ^ 0xff);
          i++;
        }
        Message("\n");
    }
    

    From what URL is the file downloaded?

14. What is the name of the file that is downloaded and run by WinExec?