Packed Executables

I have to apologize again for the lack of recent updates. I've been spending a lot of time looking for work and havn't had a lot of time to spend on this blog. Over the last little while I've been getting a lot more traffic so I'm vowing to start paying more attention to my readers.

The other day Didier Stevens posted on his blog about viewing strings in executables. Its an excellent explanation of how printable data is stored in binary files, and how an enduser can find that data, and even modify it. In his post he mentions that this technique will almost always fail against malware, as malicious executables are often 'packed or encrypted'. This post will elaborate on reverse engineering 'packed' executables.

"BTW, this technique to dump files will almost always fail when analyzing malware, because these files are often packed or encrypted. A simple trick to view the strings of such malware code is done with Process Explorer by Sysinternals. When the malware is running (you’ll want to run it on an isolated machine, like a virtual machine), start Process Explorer and display the properties of the running malware. The Strings tab will show you the strings in the file (Image) and in memory (Memory). Since the malware as unpacked/decoded itself when it started, you’ll be able to view the strings in memory."

Packing an executable file is a way of compressing executable code firstly to minimize filesizes, but often it is also used to complicate the reverse engineering process. Now, packing is quite different from standard compression like zip or rar. Zipped files exist in archives, from where they must be decompressed. Packed executables are standalone files that can be executed while still compressed. A packer will use standard compression techniques on the file, of course these modifications make the binary code unrecognizable to the OS, but the packer prepends an unpacking routine to the executable as well. When the file is run, the unpacking routine 'unpacks' the executable code, and loads it into ram in its original state.

Didier mentions using Mark Russinovich's Process Explorer to dump strings from the process as its running. This will work because the program has been unpacked into ram. This is an excellent method, but incase you're only planning on running a preliminary/pre-execution analysis and you don't have an isolated testbed machine/virtual machine, I'll show you a few other ways.

The first thing to know is that not ALL the data/code in a packed executable is compressed. Some of it, namely the unpacking routine, remains unchanged. There are many public packers available on the internet, and most of them leave a very recognizable signature in the unpacking routine. This makes it trivial to determine what packer was used to pack the code.

Following are some examples:

C:\utils\strings>strings strings.exe | more

Strings v2.2
Copyright (C) 1999-2005 Mark Russinovich
Sysinternals - www.sysinternals.com

(null)
         (((((                  H
!This program cannot be run in DOS mode.
Rich8
.text
`.rdata
@.data
Rh8
t'h

Here I've run strings against itself as an example of an unpacked executable. You'll notice near the top under a string from the DOS stub, (!This program cannot be run in DOS mode.) and Rich8 is a list of the various segments of the binary file: .text, .rdata, .data, etc. Here is the same exe packed using UPX, a very common packer:

C:\utils\strings>strings strings.exe | more

Strings v2.2
Copyright (C) 1999-2005 Mark Russinovich
Sysinternals - www.sysinternals.com

(nu
!This program cannot be run in DOS mode.
Rich8
UPX0
UPX1
UPX2
2.00
UPX!
Rh8
h<'
t;e
'h\3

As was mentioned, the packer has left a recognizable signature in the unpacking routine. This would be a clear indication that we should look into unpacking UPX. You'll find that the upx packer comes with an unpacking feature built right in. Other packers might not be so nice, but you'll likely find unpackers for most packers available online.

If a simple strings analysis isn't enough to determine the packer used on the file, you might try a PE analysis tool such as PEID available from peid.has.it. This application will recognize MOST packers.

Hope this helps someone somewhere.