When malware has been packed, an analyst typically has access to only the packed file, and cannot examine the original unpacked program or the program that packed the malware. In order to unpack an executable, we must undo the work performed by the packer, which requires that we understand how a packer operates.
All packers take an executable file as input and produce an executable file as output. The packed executable is compressed, encrypted, or otherwise transformed, making it harder to recognize and reverse-engineer.
Most packers use a compression algorithm to compress the original executable. A packer designed to make the file difficult to analyze may encrypt the original executable and employ anti-reverse-engineering techniques, such as anti-disassembly, anti-debugging, or anti-VM. Packers can pack the entire executable, including all data and the resource section, or pack only the code and data sections.
To maintain the functionality of the original program, a packing program needs to store the program’s import information. The information can be stored in any format, and there are several common strategies, which are covered in depth later in this chapter. When unpacking a program, reconstructing the import section can sometimes be challenging and time-consuming, but it’s necessary for analyzing the program’s functionality.
Nonpacked executables are loaded by the OS. With packed programs, the unpacking stub is loaded by the OS, and then the unpacking stub loads the original program. The code entry point for the executable points to the unpacking stub rather than the original code. The original program is generally stored in one or more extra sections of the file.
The unpacking stub can be viewed by a malware analyst, and understanding the different parts of the stub is fundamental to unpacking the executable. The unpacking stub is often small, since it does not contribute to the main functionality of the program, and its function is typically simple: unpack the original executable. If you attempt to perform static analysis on the packed program, you will be analyzing the stub, not the original program.
The unpacking stub performs three steps:
Unpacks the original executable into memory
Resolves all of the imports of the original executable
Transfers execution to the original entry point (OEP)
When regular executables load, a loader reads the PE header on the disk, and allocates memory for each of the executable’s sections based on that header. The loader then copies the sections into the allocated spaces in memory.
Packed executables also format the PE header so that the loader will allocate space for the sections, which can come from the original program, or the unpacking stub can create the sections. The unpacking stub unpacks the code for each section and copies it into the space that was allocated. The exact unpacking method used depends on the goals of the packer, and it is generally contained within the stub.
As discussed in Chapter 1, nonpacked PE files include a section that tells the loader which functions to import, and another section that stores the addresses of the names of all the imported functions. The Windows loader reads the import information, determines which functions are needed, and then fills in the addresses.
The Windows loader cannot read import information that is packed. For a packed executable, the unpacking stub will resolve the imports. The specific approach depends on the packer.
The most common approach is to have the unpacking stub import only the LoadLibrary and GetProcAddress
functions. After the unpacking stub unpacks the original executable, it reads the original import
information. It will call LoadLibrary for each library, in order
to load the DLL into memory, and will then use GetProcAddress to
get the address for each function.
Another approach is to keep the original import table intact, so that the Windows loader can load the DLLs and the imported functions. This is the simplest approach, since the unpacking stub does not need to resolve the imports. However, static analysis of the packed program will reveal all the original imports, so this approach lacks stealth. Additionally, since the imported functions are stored in plaintext in the executable, the compression possible with this approach is not optimal.
A third approach is to keep one import function from each DLL contained in the original import table. This approach will reveal only one function per imported library during analysis, so it’s stealthier than the previous approach, but analysis will still reveal all the libraries that are imported. This approach is simpler for the packer to implement than the first approach, since the libraries do not need to be loaded by the unpacking stub, but the unpacking stub must still resolve the majority of the functions.
The final approach is the removal of all imports (including LoadLibrary and GetProcAddress). The packer must find
all the functions needed from other libraries without using functions, or it must find LoadLibrary and GetProcAddress, and use
them to locate all the other libraries. This process is discussed in Chapter 19, because it is similar to what shellcode must do. The benefit of this
approach is that the packed program includes no imports at all, which makes it stealthy. However, in
order to use this approach, the unpacking stub must be complex.
Once the unpacking stub is complete, it must transfer execution to the OEP. The instruction that transfers execution to the OEP is commonly referred to as the tail jump.
A jump instruction is the simplest and most popular way to
transfer execution. Since it’s so common, many malicious packers will attempt to obscure this
function by using a ret or call instruction. Sometimes the tail jump is obscured with OS functions that transfer
control, such as NtContinue or ZwContinue.
Figure 18-1 through Figure 18-4 illustrate the packing and unpacking process, as follows:
Figure 18-1 shows the original executable. The header and sections are visible, and the starting point is set to the OEP.
Figure 18-2 shows the packed executable as it exists on disk. All that is visible is the new header, the unpacking stub, and packed original code.
Figure 18-3 shows the packed executable as it exists when it’s loaded into memory. The unpacking stub has unpacked the original code, and valid
.textand.datasections are visible. The starting point for the executable still points to the unpacking stub, and the import table is usually not valid at this stage.Figure 18-4 shows the fully unpacked executable. The import table has been reconstructed, and the starting point has been edited to point to the OEP.
Note that the final unpacked program is different than the original program. The unpacked program still has the unpacking stub and any other code that the packing program added. The unpacking program has a PE header that has been reconstructed by the unpacker and will not be exactly the same as the original program.
