Redscan Labs: Malware unpacking – How to uncover hidden threats - Redscan
Contact Us

Contact Us

Please get in touch using the form below

1000 characters left
View our privacy policy

To evade detection by antivirus software, malware uses a number of techniques to prevent its true purpose from being discovered. One common method is to hide its contents through the use of packer or crypter software.

 

In this Redscan Labs article, we examine the process required to remove a packing routine from an executable in order to conduct static malware analysis.

 

What is a software packer?

 

Software packers function by compressing the contents of a program and, in the process, inserting into it a decoder stub for decompression.

Packers can be used for legitimate purposes, to decrease the size of an executable file, however are also commonly used by malware authors to evade signature-based security detection. The majority of antivirus software does not scan system memory so if malicious code is unpacked or decrypted in memory it is unlikely to be detected.

The use of packers makes performing static analysis difficult as the original underlying program will be obfuscated while it remains in packed form.

Removal of packing software involves the following steps:

  • Verifying packer usage
  • Determining a program’s Original Entry Point (OEP)
  • Dumping the uncompressed executable from memory to disk
  • Reconstructing a program’s Import Address Table (IAT)

 

1. Verifying software packer usage

 

Microsoft Windows uses a standard file format for programs, known as Portable Executable (PE). The screenshot below shows an executables section table for an unpacked program.

Note: Viewing a program’s excutable table requires installation of a PE detection tool. In this example we use PEid.How to verify software packer usage

Data is stored in different sections to allow for various levels of memory protection. For instance, the .text section, which holds program code, would have execute and read-only permissions, whereas the .data section, which holds global variables, would only have read/write permissions.

The next image shows sections of an executable that have been packed. The limited number of sections is suspicious. Section names UPX0 and UPX1 provide a good indication that UPX packing software has been used.How to verify software packer usage

In this example, PEiD confirms the usage of the UPX packing routine, and shows the program’s Entry Point (EP), where it will commence code execution – 00CF9DE0. Other signs of a packer being used could include a low number of imported sections and use of LoadLibraryA and GetProcAddress, which are widely used by packers. Another indicator of packer usage is that the executable image on disk will have a high degree of entropy and a small number of text strings.

How to verify software packer usage

2. Determining a program’s OEP

 

In this example, the packer has changed the program’s entry point to its decoder stub. To find the Original Entry Point (OEP), we run the program in a debugger for a step through execution. On initialisation, the program stores the current register status using a PUSHAD instruction, as seen in the screenshot below.

How to verify software packer usage

The next step is to set a hardware breakpoint on the Extended Stack Pointer (ESP) register address to reach the unpacking stub. This section of code unpacks the original executable’s code to memory, then executes a JMP instruction to return to the program’s OEP.

Next, we set a software breakpoint on the JMP instruction to allow the unpacking routine to execute and step through to reach the OEP.

How to verify software packer usage

Now the original code has been unpacked in memory it’s possible to determine the address of the Original Entry Point (0086A810).

How to verify software packer usage

We can now use OllyDumpEx to dump the process, using the OEP address we previously uncovered.

How to verify software packer usage

In order to produce a working executable, the next step to perform is reconstruction of the Import Address Table (IAT).

 

3. Understanding the IAT

 

When a program is first executed, the Windows loader reads the PE structure and loads the executable to memory. The IAT is a component of the PE file listing the dynamically linked libraries (DLL) loaded by the program and the functions required from each DLL.

The function addresses within a DLL might change as new DLL versions are released so programs cannot use static function addresses. Because of this, the operating system completes the IAT when a program is executed.

The below image shows the Import Address Table viewed within a debugger:

How to verify software packer usage

Scylla is a tool that can be used to reconstruct the IAT. This attaches to the currently running process. Supplying the OEP address enables us to determine, via a debugger, that the memory dump’s IAT table can be fixed.

How to verify software packer usage

The result of this process is an unpacked executable ready for full static analysis.

How to verify software packer usage

About Redscan Labs

 

Redscan Labs is a specialist hub within our cyber security operations centre dedicated to in-house threat research and analysis. By conducting regular threat investigation, such as in-depth malware analysis, our experts maintain a detailed understanding of the latest malicious actors and use this knowledge to improve our range of award-winning security services. This includes the creation of new signatures and rulesets to improve threat hunting plus detection and response to attacks.

 

Read more:

An introduction to endpoint security and how it can benefit your business

Why your business needs to adopt a proactive approach to cyber security

The key challenges of intrusion detection and how to overcome them

 

Last updated on

Redscan Logo

Redscan Labs is a specialist division of our SOC dedicated to in-house threat intelligence, analysis, research and development.