Recognizing Packed Malware and its Unpacking Approaches-Part 1

October 28, 2016 by

Security Ninja

In this article series, we will learn about the characteristics possessed by a packed malware specimen and how to unpack them. In the unpacking section, we will see the both automated and manual ways to unpack the malware.

Most malware authors want their malware specimen to be protected from most antimalware products, and it is well achieved through packers. With packers, it is sometimes difficult to reverse engineer the specimen to deduce its functionality. However as well all know that whenever a compressed, encrypted or packed malware needs to run, it will in decompressed, decrypted form while in memory.

Become a certified reverse engineer!

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

Start Learning

When we see packed malware specimen we will notice that it will reveal very limited information about itself, for example, there will be many fewer strings that can be visible from the specimen, a very limited no of Import Address Table (IAT) calls, etc.

Now there are various packers available out there. UPX is the famous among them and is commonly found as the packer. In the below section, we will look at the various tools that can help us to conclude that a specimen under investigation is packed. Note here that not all packed executables are malicious. Packing legitimate executables is a common practice.

We will start discussing tools where can use to analyze the static properties of a specimen to see if it is packed or not.

• Strings: As mentioned above strings utility can be used to extract the strings from the specimen. In some specimen, we will see very little strings or we will even see the name of known packers like UPX. For example, below is screenshot of a packed malware using strings2 utility:

  

• Histogram: Normal executables usually have varying bit frequency whereas packed executable has uniform bit frequency. Below is an example of where the difference between a packed and unpacked version of the same specimen can be seen. A tool named as 'bytehist' is used to draw these histograms.

• Other tools: We can also analyze the static properties of a malicious specimen using tools like pescanner as can be seen below

There are other tools available like ExeInfo PE that can be used to find if the malware specimen is packed or not.

Once we have concluded that the malware specimen is packed, our next step is to find a way to unpack it. There are a couple of approaches to do the same i.e. via automated or manual unpacking. We will start with automated unpacking process where we will use some tools to unpack the specimen:

As we have seen earlier that the malware specimen is packed with upx. UPX utility also has an inbuilt feature to unpack the specimen using the following command:

• Upx -d -o <name of the unpacked specimen with output directory> <location of the packed specimen>

After unpacking now let's run our strings2 utility on unpacked malware:

We can compare the string2 output from our earlier string2 output. In the unpacked version, there are lot more strings visible.

Now since we have the unpacked version of the specimen. What should we do? Run it, right? But wait if I run this specimen I get the below error in ollydbg.

Why is that? If you know, then bonus point to you. If you do not, then it's a built in security feature in Windows known as Address Space Layout Randomization(ASLR) which loads the image randomly in the image completely ignoring the ImageBase field value set up in the executable. This is implemented to make it hard for an attacker to guess the memory location where the image is loaded, and it is enforced by default on all executables from Windows 8.1. Then you must be wondering how are other sections gets aligned in memory if the image itself is loaded randomly. It is due to another section named 'relocation' value the other sections address gets adjusted while loaded in memory. With Windows XP ASLR was not enforced by the OS, so this specimen could have run smoothly without any issues.

To run these specimens on recent Windows releases or on OS where ASLR feature is enforced, we should first disable ASLR for our malware specimen so that ImageBase field comes into effect. We can do this using various utilities such as CFF Explorer. In CFF Explorer, under optional header > DLL characteristics -> uncheck 'DLL can move'. This will disable image to be loaded randomly in the image.

We could also use a utility such as setdllcharacteristics to disable ASLR on a specimen using the switch -d to disable dynamic base. Below is a screenshot of setdllcharacteristics in action:

So, in this article, we have seen how to recognize packed malware and how to unpack then using utilities like UPX. We have also seen how to deal with ASLR problem to run unpacked malware specimen. In the next article, we will see how to deal with unknown or custom packers for which there is no automatic utility. Stay Tuned!