Quick reference for manual unpacking II

Unpacking is a critical step in the process of analysing malware. Malware authors use packers to make it difficult for their malware to be reversed – the packers encode the original instructions. By packing a malicious executable, the author can be sure that when it is opened in a disassembler it will not show the correct sequence of instructions. Packers add some instructions at the top of the binary to unpack the executable.

In [1] we described the steps that can be used to manually unpack malware packed with a number of commonly used packers. In this article, we will cover another set of packers that are popular with malware authors.

(The purpose of this article is to provide a quick reference guide that will assist analysts in the unpacking of malware and reduce the response time for malware analysis – the full technical details of each packer have thus been omitted.)

Molebox is a runtime executable packer for Windows applications. It can be used to pack an application and all its data into a single executable file. As shown in Figure 1, Molebox starts with a CALL instruction, followed by PUSHAD.

The first step in the process of locating the original entry point (OEP) of a file packed with Molebox is to put a breakpoint on PUSHAD. PUSHAD pushes the contents of the general purpose registers onto the stack. The registers are stored on the stack in the following order: EAX, ECX, EDX, EBX, EBP, ESP (original value), EBP, ESI and EDI (if the current operand-size attribute is 32), AX, CX, DX, BX, SP (original value), BP, SI and DI (if the operand size attribute is 16).

Figure 1. The initial instructions for Molebox.

Step once after the breakpoint has triggered, since EDI is the last value which is pushed (as shown in Figure 2). The next step involves setting an access hardware breakpoint at the memory location pointed to by ESP. As shown in Figure 2, the address location at ESP stores the value in EDI.

Figure 2. EDI in the memory location pointed to by ESP.

When the hardware breakpoint triggers, a POP EAX instruction is followed by the CALL EAX instruction (see Figure 3). Step into CALL EAX, and we have reached the OEP.

Simply dump the process to obtain the unpacked file.

Figure 3. The instructions when the breakpoint triggers.

PE-Pack was released by ANAKiN. It is commonly used by malware authors to hide code. When a packed file is launched in a debugger, it starts with a JMP instruction (see Figure 4).

Figure 4. The initial instruction for PE-Pack.

To unpack the file, put a breakpoint on the JMP instruction. When the breakpoint triggers, the debugger will reach the PUSHAD instruction, as shown in Figure 5.

The PUSHAD instruction will push all the registers onto the stack. Next, set an access hardware breakpoint on the uppermost dword of the stack. As shown in Figure 5, the top dword will be the same value as that stored in the EDI register. This can be confirmed by looking in memory at the address value pointed to by ESP.

Figure 5. The hardware breakpoint when PUSHAD is encountered.

When the hardware breakpoint triggers, as shown in Figure 6, the debugger will reach the instruction JMP EAX. This is the jump to the OEP. Step once on it and we have reached the OEP.

Figure 6. Instructions encountered when the debugger reaches the OEP.

WinUpack is a command-line program for compressing/decompressing Windows EXE/DLL files. The program is mainly used for compression, rather than for protection. When the file is executed, the compressed EXE/DLL will decompress and run normally without any additional software. In order to unpack a WinUpack packed file, it should be loaded in OllyDbg. Once the file has been loaded in the debugger, scroll down to find the following set of instructions:

46            inc esi
AD            lodsd
85C0          test eax, eax
0F84xxxxxxxx  00  jz xxxxxxxx

When JZ triggers, we have reached the OEP. Dump the process to get the unpacked file.

Figure 7. Assembly instructions just before the OEP.

PolyCryptPE is used for encrypting PE files and can also be used to protect PE files from disassembly. The packer starts with the PUSHAD instruction. However, as seen in Figure 8, it employs various anti-debugging tricks.

Figure 8. Assembly instructions checking for a debugger.

The instruction MOV EAX, DWORD PTR FS:[30] loads the value FS:[30] (or process environment block) in the EAX register. The next instruction, MOVZX EBX, BYTE PTR DS:[EAX+2], loads the third value of PEB. When the process is being debugged, the third value in the PEB structure will be set. So when a file packed with PolyCryptPE is being debugged, either the isDebugged() flag must be set, or the HideOE plug-in must be used in order to hide the debugger.

The packed file starts with the POPAD instruction. In order to debug the packed file, the POP EBP, POPFD, POPAD instructions must be located. When the debugger executes the RETN instruction, the debugged process has reached the OEP. The process should be dumped to get the unpacked version of the file.

Figure 9. The assembly instructions before the OEP.

SimplePack is another packer that is often used by malware authors. It uses LZMA compression. When the packed process is opened in a debugger, the packed code starts with the PUSHAD instruction, as shown in Figure 10. The instruction will push all the general purpose registers onto the stack, with the value stored in EDI being on top of the stack.

Figure 10. Starting instructions of the packed file.

The next obvious step in unpacking the file is to set a hardware access breakpoint on the uppermost dword of the stack when the PUSHAD instruction is executed. When the breakpoint triggers, as shown in Figure 11, the POPAD, PUSH and RETN instructions are encountered.

Figure 11. Assembly instructions when the hardware breakpoint triggers.

When the debugger executes the RETN instruction, we can see the initialization of the stack frame (Figure 12).

Figure 12. SimplePack initialization of the stack frame.

Upon initialization of the stack frame, the debugged process can be dumped to get the unpacked file.

PECompact 1.x is a commercial packer. It compresses the code, date, import directory, selected resources and other portions of Windows executables (DLL, EXE, SCR, OCX etc.). The concept for unpacking PECompact 1.x is pretty much the same as that described for SimplePack above. After loading the packed file in a debugger, step down a few instructions and find PUSHAD. The instruction will push the registers onto the stack. When the instructions have been pushed, set a hardware access breakpoint on the top dword of the stack. Basically, the hardware access breakpoint will be on the ESI value at the address pointed to by ESP. When the breakpoint is triggered, the following instructions will be encountered:

9D               popfd
50               push
68 xx xx xx xx   push xxxxxxxx
c2 04 00         retn 04

RETN 04 is a jump to OEP. Step on the instruction and then dump the process to get the unpacked file.

Unpacking is a key step for the static analysis of malware. Loading a packed malicious executable and executing step-by-step instructions in a debugger is one of the best ways to locate the OEP. In this article, we have provided assembly instructions for Molebox, PE-Pack, WinUpack, PolyCryptPE, PECompact 1.x and SimplePack – these instructions can be used to manually unpack malware. It is also possible to generate OllyScript for the methods mentioned in the article. Open RCE [2] provides a good reference collection of OllyScripts for unpacking these packers.