Unpacking the Malwares

A cura di: Ravi Poonia (team hackerhood)

In this article, we are going to explore different techniques like Packing, Encryption and obfuscation used by malwares authors to bypass the antivirus software. During this article we will mainly focus on Packing a malware and techniques used to unpack a malware. During this article we will diving into the following sections:

● Exploring the packers.

● Identify the packed sample.

● Performing the manually unpacking of a packed malware sample.

Exploring the Packers A packer is a tool that packs together the executable file’s code, data, and sometimes resources and also it contains the code for unpacking the program.

The above image denotes the process of packing and unpacking the malware sample.

Packers may help malware authors to hide the malicious content or code behind this compression layer. This code only gets unpacked and executed once the malware is executed, which helps the malware authors to bypass the static signature based detection. There are multiple tools that can pack/encrypt the binary executables files, but every tool has a different purpose.

● Packers: These programs are mainly used for compressing the binary executable file thereby reducing their total size. Since their purpose is compression, they were not created for hiding the traits and are not malicious on their own. Therefore, they can’t be the indicators that the packed file is likely the malicious file. Some well known packers are UPX, ASPack, the enigma protector, MPRESS, Exe packer etc.

● Legal Protectors: The main purpose of these tools are to protect against the reverse engineering attempts for example, to protect the licensing system of shareware products or to hide implementation details from competitors.

● Malicious Encryptors: Similar to the legal protectors, their purpose is also to make the analysis process harder. However the focus is different to avoid the antivirus detection, you need to bypass the sandboxes and hide the malicious traits of a file. All of these above tools are called packers and may include both protection, compression and bypass detection capablities.

IDENTIFYING A PACKED SAMPLE

Checking static signature Using PE Tools

The first way to identify whether a malware sample is packed is by using static signatures. Every packer has some unique characteristics that can help you identify the malware sample. For example by checking the section name of the binary executables as in case of UPX packer, it renames all the section names to UPX1, UPX2 and so on. While the ASPack packer names the last section .aspack. Following Tools used for identifying the packer that was used for compress the file: otherwise, they will identify the compiler that is used to compile this file.

● PEiD

● CFF Explorer Analyze one of the malware using the above tools. So the packer used in the sample is MPRESS packer.

Analyzing PE Section Names

Section names can reveal a lot of information about the packer used or compiler used, if the file is packed. A packed PE file contains such as .text or .code, .data, .rsrc, ,idata and .reloc, while a packed sample contains the specific names, Such as UPX!, UPX2 for UPX packer or Mpress1, Mpress2 for MPress or .ASPack for aspack packer and so on. Searching the section name on the internet might get some hint about the packer that uses these names for its packed data or its stub(Unpacking Code). You can easily find the section names by opening the file in PEiD and clicking on the > button beside the EP Section as shown in the above screenshot. By doing this, you will see the list of sections in the binary executable.

Using Stub Execution Signs

Most packers compress PE file sections, including the .code section, .text section, .reloc section, .data section and import table and so on. And then add a new section at the end which contains the unpacking code as Stub. Since most of the unpacked PE files start the execution from the first section (.text or .code section), the packed PE files start the execution from one of the last sections, which is a clear indication that a decryption process will be running. There are some key points to remember will identifying the malware sample as follows:

● The Entry Point is not pointing to the first two sections of the binary executable, it would be most probably pointing to the last two sections of the executable and this section’s memory permission is EXECUTABLE(in the sections characteristics).

● The First section’s memory permission will be mostly READWRITE.

Detective a small import table

The normal binary executables import tables is full of APIs from system libraries or third party libraries; however in most of the packed PE files, the import table will be quite small and will include a few APIs from well known libraries that are enough to unpack the malware sample.

Checking the size of sections

While analyzing the IMAGE_NT_HEADERS of a binary file, it contains the section information. So by checking the code section in IMAGE_SECTION_HEADER Code, it contains the virtual size and size of raw data. If there is huge difference between the Virtual Size and Size of Raw Data that’s another indication that a binary executable is packed. We use the PEView tool to get the header information of the binary executable.

Manually Unpacking the packed Malware sample

The unpacking done by the automatic tool is much faster than the manual unpacking but it doesn’t work with all the packers, encryption or protectors. One of the manual approaches is dumping the process memory by running the binary executable, hoping that the unpacked module is available there. But there are many disadvantages to using this approach.

● Original loader might unpack the sample to allocated memory and inject it somewhere else and free the process memory so it won’t be part of the memory dump.

● Relocation of the import table and change the physical address of each section to be equal to the virtual ones might be required in order to run the sample.

Memory Breakpoints on execution

There are a lot of packers which encrypts the first few sections and the unpacker stub unpack those sections and transfer the control to the original entry point for the application to run normally. Steps to follow the unpacking of the sample.

Setting the breakpoints Hardware and memory breakpoints could be used but in case of hardware breakpoints on execution can only be set on maximum 4 bytes that means you should know the OEP to be able to set one. So the effective solution is to use the memory breakpoints on execution of a binary file. First changing the first’s section memory permission to Full Access from READWRITE in ollydbg or x86dbg debuggers.

Turn ON DEP(Data Execution Prevention)

If the memory permission doesn’t include the EXECUTE permission therefore need to enforce the DEP(Data Execution Prevention) on.

Set Memory breakpoint Then the set breakpoint on the VirtualProtect API that might change the permission of the section as if stub try to call VirtualProtect API to change the permission of the section the debugger will set the breakpoint. And then change the New Protect value to READONLY or READWRITE and remove the execute bit from it.

Executing and getting OEP By clicking on Run, the debugged process will break directly on the OEP.