Packer – Keep Calm and Hide the Evidence (Malware Analysis – Chapter 4)

No wonder, these days Packer is quite popular and widely used by developers and malware authors. Not only the binary executable but also the scripts such as Javascript are being compressed by using a Packer. Reasons behind it are very obvious:

  1. To compress: The executable are transformed into another file containing the data and one program to unpack back to its original form.
  2. To thwart analysis or detection: Analysis and detection are two different things. An application developer would never like his executable to get analysed without his concern. Same way, a malware author would like to keep his malicious creation to avoid detection from any anti-virus program and live forever.

Let’s begin with an intro..

Like explained earlier in Chapter 3 – ObfuscationA technique to obfuscate the file by compressing it along with a decompression program(unpacker) is called packing and the tool responsible for it is called Packer. When the malicious executable file is packed, the analyst has only access to the packed file. The packing program and the original code becomes some weird looking unreadable code. In order to get the original file, the work done by packed file needs to be reversed which first demands on knowledge on how was it operated.

How does a Packer operate?

It’s quite simple actually, one executable is taken as input and another executable is produced as output. In this process, the file is encrypted and compressed to make it hard for analysts to reverse it. New generation packers are quite smart, they don’t only use complicated compressing algorithms but also use various anti-reverse techniques like anti-debugging, anti-disassembly or anti-VM. Unpacking program embedded with the compressed executable perform three very important functions ones the file starts execution:

  • First is to load the original executable into memory.
  • Then, the required imports is resolved.
  • And last, shifting to the entry point of the original executable.

Step 1: Loading

Likewise normal executable files, the packed one also consists in PE file format so that it’s treated like an authentic executable and loads its section into memory space. These sections could be the same one from original file or the new ones created by the unpacker program.

Like in below image, the code section and data section are transformed into a section named UPX1 and while execution, the UPX1 is loaded to memory space into UPX0.

Packer Process

Step 2: Resolving Imports

In most common cases, the decompression program contains two import functions namely LoadLibrary and GetProcAddress. LoadLibrary loads the DLL files into memory and GetProcAddress gets the address of the exported functions. Once the unpacking program is done with decompressing the original executable, the original import information also becomes accessible. Loadlibrary starts loading the libraries into the memory and GetProcAddress, once the load part is finished, gets the address of each function.

Step 3: Relocate Entry Point

The job is not done yet. The file is unpacked, the libraries and functions are loaded and ready to execute. But there is one thing still missing “where to begin”. Yes, the first step of execution is to find the entry point or shall I say “Original Entry Point”. There is a instruction called tail jump which makes this execution transfer happen. These days, smart malware authors used to obscure it using a ret or call instruction. I’ll explain all about these instructions in the next chapter.

So, now you know how all this works. Now, let’s talk about some commonly used packers:

How to check if the file is packed or not?

Following signs can help you identifying them:

  • If there are very few imports present in the program, specially when the only imports present are LoadLibrary and GetProcAddress.
  • When the program, if opened in IDA Pro, shows very few lines of code by automatic analysis.
  • Other way around could be opening the file in OllyDbg, One straight sign is found in written that the file may be packed.
  • If the section names if read, indicate a particular packer name such as UPX0.
  • Or, The program got non-typical section sizes, for example, .text section with size of 0 and the virtual size of nonzero.
  • Entropy calculation is another way of verifying if the file is packed or not. As explained in Chapter 2if the randomness of the file is higher than 6 Shanon, high chances are that the file is packed.

There are various tools available online to identify if the file is packed or not, such as PEiD. Let me show you a snippet of how a FSD packed file looks like when opened in PEiD.

FSG Packed

Well Known Packers

There are so many tools available online to pack the files. Most commonly used of them are:

  • Ultimate Packer for Executables(also known as UPX)
  • Exe Stealth Packer
  • PackWin
  • PELock
  • CExe
  • Armadillo
  • FSG
  • dotBundle

And thee are various tools available online to unpack the packed files compressed by commonly used packers. One of the most common one is PE Explorer. It can open UPX, Upack and NsPack compressed files seamlessly without long workarounds.

Now, you must be thinking..

What is the point of packing a malware if there are unpackers available online to easily unpack them?

There is one little dark secret I have been hiding from you yet or it was always here you just couldn’t find it. Packers, like I said earlier, is nothing more than an algorithm to achieve one target, to compress. One outcome may have many ways to attain it. Sometimes simple like in this case UPX, FSG or any other ordinary way of packing a PE file and sometimes, malware author would push himself to use a custom way by writing his own algorithm to pack a PE file.

Please comment whatever comes in your mind after reading this post.

Kindly like our page Talent Cookie on Facebook, be a part of our Facebook group to keep yourself updated and also, you can follow us on Twitter.

Related Posts

Leave a Reply

Your email address will not be published.