Malware analysis

Analyzing packed malware

Malware is created with deception in mind. Malware authors want to go undetected in order to steal, alter or delete as much information as possible. 

Obfuscating malware is a way to keep the files associated with the malware from detection and easy analysis. Packing is a type of obfuscation technique.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

Obfuscation

Obfuscation takes code and basically makes it unreadable without destroying its intended functionality. This technique is used to delay detection and/or to make reverse engineering difficult. Obfuscation does have legitimate purpose. It can be used to protect intellectual property or other sensitive code.

Packing 

Packing is a subset of obfuscation. A packer is a tool that modifies the formatting of code by compressing or encrypting the data. 

Though often used to delay the detection of malicious code, there is still legitimate use for packing. Some legitimate use includes protecting intellectual property or other sensitive data from being copied.

A stub is a small portion of code that contains the decryption or decompression agent used to decrypt the packed file

The packing process consists of:

1. The original code is uploaded into the packer tool and goes through the packer process to compress or encrypt the data
2. The original portable executable header (PE header, which consists of executable image and object files) and original code are compressed or encrypted and stored in the packed section of the new executable
3. The packed file consists of:
1. New PE header
2. Packed section(s)
3. Decompression stub — used to unpack the code
4. During the packing process, the original entry point is relocated/obfuscated in the packed section. This is important for anyone trying to analyze the code. This process makes identifying the import address table (IAT) and original entry point difficult
5. The decompression stub is used to unpack the code upon delivery

Some malware creators use custom packers, but commercial/open-source packers are also used. Some popular packers include:

1. UPX
2. Themida
3. The Enigma Protector
4. VMProtect
5. Obsidium
6. MPRESS
7. Exe Packer 2.300
8. ExeStealth

Analysis 

It is possible to automate the evaluation of packed code. The packing tool embeds the stub into the executable during the packing process. So if you can determine the tool used to pack the code, you may be able to use the same tool to extract the original file.

The best (and quickest) way to unpack packed malware is to use a tool. Exeinfo PE is one such tool that will analyze the code to determine if it has been packed. It can often identify the packer used as well. 

UPX is one commonly used packer tool that includes the unpacking feature. If the malware was packed using UPX, it is possible to use the command line within the tool to unpack the malware code and further analyze it with a reverse engineering tool. A command line example is given below, based on a file named packed.exe:

• upx -d -o unpacked.exe packed.exe

Running that command will unpack the packed.exe file and create a new file named unpacked.exe. You can then place the unpacked malware file into a debugger like Ollydbg to perform further analysis.

There are manual ways to analyze the malware. One way to begin the malware analysis process is to run the strings command to analyze the strings associated with the malware. However, in packed code there are no identifiable strings.

Also, as stated earlier, the original entry point is concealed in the packed file. Knowing the original entry point is important to any analyst trying to analyze the code. It is how they will be able to recover the original code. The IAT is used by running programs to reference the functions it needs to use in order to run properly. In packed files, the IAT information is obfuscated which makes disassembly difficult. This is another challenge to malware analysts.

Ollydbg can be used to unpack malware. While in Ollydbg, you can manually evaluate the code. If you know assembly, you can scan through the code to look for valid assembly commands versus items that do not appear to resemble assembly.

You can upload the code into Ollydbg. Upon upload, Ollydbg will ask if you want to analyze the code. Do not analyze the code. Packed malware does not show the import information. You can press Ctrl -n to see information.

Press F9 to run the program.

You want to look for tail jump, which could be a sign of the packing stub. The end of an unpacking stub could jump to a place in memory far away, which could be where the unpacked memory resides.

One way to identify a jump is that it could be followed by non-valid assembly language. For example, a bunch of scrambled code or repeated numbers preceded by a JMP <#######> identifier, with a JNE short close above it.

For example, it would look something like this:

 

Hit F2 to create a breakpoint, then F9 to execute the malware, then F8 to take the jump. This should be the unpacked area. You could then use OllyDumEX to reset a new entry point. It will dump this new data. You can then use a tool like Scylla to examine the dumped file. In Scylla, or a similar tool, update the Original Entry Point (OEP) based on the jump point in memory you identified earlier.

This will create a new file that you can upload into Ollydbg again. If successful, you will see all of the available API calls and the full IAT. With this file, you can proceed to further evaluate the now-unpacked malware.

Conclusion 

The purpose of packed malware is to avoid detection and reverse engineering. Analyzing packed malware takes skill, as well as the proper tools.

There are multiple packing tools available, but many malware authors use custom-made tools. Tools such as Exeinfo PE can examine packed code and determine what tool was used to pack the file. Knowing this means an analyst could use that same tool to possibly unpack the code. 

Debuggers can also be used to manually analyze the malware. Manual analysis takes more time and a more advanced skill set. And since malware is becoming more and more sophisticated, security professionals need to stay savvy in order to continue fighting these vulnerabilities.

Become a certified reverse engineer!

Get live, hands-on malware analysis training from anywhere, and become a Certified Reverse Engineering Analyst.

Start Learning

 

Sources

• Obfuscation, Techopedia
• Practical Malware Analysis, Kris Kendall and Chad McMillan
• Three and a half ways to unpack malware using Ollydbg, Colin Hardy (YouTube)
• Malware Packers Use Tricks to Avoid Analysis, Detection, McAfee