Practical Malware Analysis - Chapter 15 Lab Write-up

15 minute read

PMALab

Chapter 15. Anti-Disassembly

There are 2 types of disassembler algorithms.

Linear disassembly: Widely used. Iterates over blocks of code one instruction at a time in a linear fashion. Uses size of disassembled instruction to determine next byte to disassemble. No regard for control flow instructions and unable to determine the difference between code and data.
Flow-oriented disassembly: Used more commonly in commercial disassemblers. Examines each instruction and uses that to build a list of locations to disassemble. Generally prevents data from being interpreted as code.

Disassemblers generally process the “False” branch of a conditional jump first which can be abused much to their detriment when there’s conflicting code with the “True” branch that gets ignored. Relevant opcodes of interest include E9 (5-byte jmp) and E8 (5-byte call). If these are disassembled it can lead to 4-bytes being hidden from view. We can use ‘D’ and ‘C’ in IDA to transform components from ‘Data’ to ‘Code’ and vice versa.

Anti-Disassembly Techniques:

Jump with same target: Most common anti-disassembly technique and is made up of multiple conditional jump instructions pointing to the same location. Cross-references in red may indicate anti-disassembly is being used.
Jump with constant condition: Common anti-disassembly technique and is made up of a single conditional jump where the condition is always the same.
Impossible disassembly: Occurs when a ‘rogue byte’ e.g. E9/E8 mentioned above is required and executed at runtime and can’t be ignored e.g. the byte is used by multiple instructions. An example is where ‘FF’ could be part of a jmp, but also part of the following operation e.g. inc eax, and the disassembler is unable to show this as both a jmp, and the inc operation. Only real way to resolve is to patch with ‘NOP’ operations, or convert to data.

NOP Out Instructions in IDA:

Note: This is taken directly from the PMA material. It adds a hotkey to allow converting an instruction to a ‘NOP’ at the current cursor location.

import idaapi
idaapi.CompileLine('static n_key() { RunPythonStatement("nopIt()"); }')
AddHotkey("Alt-N", "n_key")
def nopIt():

 start = ScreenEA()
 end = NextHead(start)
 for ea in range(start, end):
 PatchByte(ea, 0x90)
 Jump(end)
 Refresh()

Obscure Flow Control:

Function Pointer Issues: By using function pointers in hand-written assembly or crafted in a nonsensical manner, it can make analysis difficult by preventing decompilers such as IDA from showing all the correct cross-references to a particular function. This can also remove function argument names which would otherwise be present.

We can manually add comments containing function arguments if required; however, to add missing cross-references, we need to leverage IDC (AddCodeXref) or IDAPython. Example executions are shown below where fl_JF is a jump instruction, and fl_CF is a call instruction as flow types.

AddCodeXref(0x004011DE, 0x004011C0, fl_CF);
AddCodeXref(0x004011EA, 0x004011C0, fl_CF);

Return Pointer Issues: This is generally ret or retn. Functions like a jmp, except return pointer is pushed to stack. Generally used to return from a function call, but can be abused elsewhere to just pop a value from the top of the stack and jump to it.
Structured Exception Handlers: Method of flow control when errors occur. Manually generated errors and custom handlers (on the top of the SEH chain, generally appears as accessing ‘large fs:0’) can fool debuggers and disassemblers. SEH chain found by examining FS segment register to gain access to Thread Environment Block (TEB). To do this the binary needs to be compiled with Software Data Execution Prevention (DEP or SafeSEH) disabled.

Defeating Stack-Frame Analysis:

When abused by a malware author, this can prevent certain useful components such as the decompiler plugin, as this relies on having knowledge about the stack frame. Can use CTRL + K to view stack frame in IDA and ALT + K to adjust the stack pointer.

Lab 15-1

Analyze the sample found in the file Lab15-01.exe. This is a command-line program that takes an argument and prints “Good Job!” if the argument matches a secret code.

Question 1

What anti-disassembly technique is used in this binary?

Answer 1

By opening the binary in IDA we can immediately see some sort of anti-disassembly has been used due to all the data being marked as text, and calls to non-existant functions.

Lab15-01.exe

Using ‘Options -> General’ we’re able to set the number of opcode bytes we want to see, and in this case setting it to ‘4’ provides us some more information on what is going on.

Lab15-01.exe

In the above we can see 4 instances where an XOR operation has been run for eax and eax (the end result is the return value ‘0’), right before a jump statement occurs if the zero flag is returned (jz). Because of this the return is always true; however, the ‘false’ statement is evaluated by the disassembler first. It’s this false conditional branch use which has caused the disassembly issue.

Question 2

What rogue opcode is the disassembly tricked into disassembling?

Answer 2

The rogue opcode in the disassembly is 0xE8 which makes the disassembler believe the following data is made up of 5-bytes for the call instruction, thus hiding the remaining bytes proceeding this from our view.

Question 3

How many times is this technique used?

Answer 3

To get an idea how many times this technique is used we can take a quick glance at how many operations attempt to jump to a new location near a pointer + an offset.

Lab15-01.exe

This leads us to believe it has been used 5 times. To confirm this assumption, we can begin reassembling this into the code it should be. Starting out we can turn the instruction at ‘00401010’ into data, using ‘D’.

Lab15-01.exe

From here we can see that too many op codes have been converted to data, so we begin converting anything besides the rogue 0xE8 back into code using ‘C’. Once completed this reveals our second false conditional branch.

Lab15-01.exe

Repeating this process for every rogue instance of 0xE8, we can begin to gain visibility into what was previously unknown to us, and the program begins to look more like a properly disassembled program.

Lab15-01.exe

This confirms that the technique was used 5 times.

Question 4

What command-line argument will cause the program to print “Good Job!”?

Answer 4

By highlighting the above sections from ‘main’ to ‘ret’ we can have IDA turn this code into a function by pressing ‘P’. At this point we can now view this in the alternative IDA view.

Lab15-01.exe

This now reveals 2 possible outcomes for comparisons that take place, one where your parent “is disappoint” - sneaky 4chan meme, and one where you’ve done a good job. At this point it is trivial to convert the hex comparisons to their character constances by using ‘r’.

Lab15-01.exe

Taking a look at the above we have found that by passing ‘pdq’ to the program as an argument, all the checks pass and it prints “Good Job!”.

Lab 15-2

Analyze the malware found in the file Lab15-02.exe. Correct all anti-disassembly countermeasures before analyzing the binary in order to answer the questions.