Quick reference for manual unpacking II

2012-07-01

Abhishek Singh

FireEye, USA
Editor: Helen Martin

Abstract

By packing their malicious executables, malware authors can be sure that when they are opened in a disassembler they will not show the correct sequence of instructions, thus making malware analysis a more lengthy and difficult process. Continuing on from his earlier article on the subject, Abhishek Singh provides a quick reference guide for unpacking malware from some more of the most commonly used packers.


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

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).

The initial instructions for Molebox.

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.

EDI in the memory location pointed to by ESP.

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.

The instructions when the breakpoint triggers.

Figure 3. The instructions when the breakpoint triggers.

PE-Pack

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).

The initial instruction for PE-Pack.

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.

The hardware breakpoint when PUSHAD is encountered.

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.

Instructions encountered when the debugger reaches the OEP.

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

WinUpack

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.

Assembly instructions just before the OEP.

Figure 7. Assembly instructions just before the OEP.

PolyCryptPE

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.

Assembly instructions checking for a debugger.

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.

The assembly instructions before the OEP.

Figure 9. The assembly instructions before the OEP.

SimplePack

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.

Starting instructions of the packed file.

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.

Assembly instructions when the hardware breakpoint triggers.

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).

SimplePack initialization of the stack frame.

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

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.

Conclusion

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.

Bibliography

[1] Singh, A. Quick reference for manual unpacking. Virus Bulletin, April 2012, p.11. http://www.virusbtn.com/virusbulletin/archive/2012/04/vb201204-manual-unpacking.

twitter.png
fb.png
linkedin.png
hackernews.png
reddit.png

 

Latest articles:

VB2019 paper: APT cases exploiting vulnerabilities in region‑specific software

Some APT attacks are carried out by exploiting vulnerabilities in region-specific software. Government agencies frequently use such localized software, and this tends to be the target of attackers. In Japan, there have been many cases where attacks…

Detection of vulnerabilities in web applications by validating parameter integrity and data flow graphs

Web application vulnerabilities are an important entry vector for threat actors. In this paper researchers Abhishek Singh and Ramesh Mani detail algorithms that can be used to detect SQL injection in stored procedures, persistent cross-site scripting…

VB2019 paper: Cyber espionage in the Middle East: Unravelling OSX.WindTail

It’s no secret that many nation states possess offensive macOS cyber capabilities, though such capabilities are rarely publicly uncovered. However, when such tools are detected, they provide unparalleled insight into the operations and techniques…

VB2019 paper: 2,000 reactions to a malware attack – accidental study

This paper presents an analysis of 1,976 unsolicited answers received from the targets of a malicious email campaign, who were mostly unaware that they were not contacting the real sender of the malicious messages. Many of the victims were unaware…

VB2019 paper: Why companies need to focus on a problem they don't know they have

There is a type of crime, breach of company policy, misuse of company assets and security threat that is often overlooked: as one in 500 employees use their work computer to handle child sexual abuse material. This crime and misuse of company assets…


Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.