So we are taking a short break from my 4 part series on Maltego to bring you a guest post on runtime packers done by your friendly neighborhood Security Shoggoth. Packers are one of those mystical tech items out there that for most people sound too complicated to even look into. What SecShoggoth and I aimed for with this post is to have understandable yet technical and I think he did an awesome job:
What is a packer?
What do they do?
A packer, also known as a run time packer, is a program which compresses another executable to a smaller size on disk. When executed, the packed executable is uncompressed in memory and executes. The time to uncompress the executable in memory is usually not noticeable, making it very advantageous to use one.
There are hundreds of packing programs available. One of the most commonly used is UPX (http://upx.sourceforge.net) which will pack a number of executable formats. Unlike most packers, UPX can unpack a program to its original, uncompressed state. Many packers do not have this functionality and analysts who wish to unpack a program have to find a separate unpacker or manually unpack the program in a debugger.
Why do virus/malware developers use them?
There is one side effect of packers that malware developers have found useful. Not only does the packer make the malware smaller and easier to transfer, but they also obfuscate or encrypt the internal components of the malware making static analysis virtually impossible.
For example, normally an analyst would be able to look at the internal strings of a malware sample and determine some of its functionality – such as what registry keys it adds, what URLs it contacts, what functions it loads, etc. However, by using a packer on the malware, the internal strings would be compressed and obfuscated, hiding them from view. The only way to view to internal strings would be to unpack the malware – something which is not always an easy thing to do.
Some packers also contain anti-virtual machine, anti-sandboxing and anti-debugging “features” which prevent the packed executable from running if it detects any software analysts typically use to analyze malware. This makes it much harder for the malware to be analyzed and will extend the amount of time before it can be reliably detected by AV software.
How do they work?
When an executable is packed, the packer compresses the original program and places some wrapper code around it. When the packed program is executed, this wrapper code runs and uncompresses the original program in memory, loads any dynamic libraries needed by the import table and jumps to the original entry point (OEP) of the now uncompressed program where it begins execution.
Will AV detect packed programs?
It depends. Not being in the AV industry I can’t comment on every anti-virus program but from my experience with anti-virus and bypassing them, I can make some educated guesses.
From my experience, most AV programs handle packers in two ways. First, if they can detect the packer being used they may try to unpack it – provided they have an unpacking routine for that packer. For example, UPX is a common packer (with it’s source available). I would bet that most AV have a UPX unpacking routine which, when it detects a UPX-packed executable, unpacks and scans it. Therefore, if you packed pwdump with a known or common packer, the AV will still detect it.
However, if you used a packer the AV did not know how to unpack (such as a custom packer or one the AV does not have a routine for), then the AV would most likely not be able to detect the malicious program on disk and would have to wait until it was launched into memory to detect it. Malware authors already know this so some are starting to use custom packers. The Race To Zero contest at this year’s Defcon was about just this – trying various methods to hide an executable from AV on disk.
There are still ways AV can determine if a program has been packed even if it doesn’t know what packer was used. When a program is packed various things happen to the header and the internal structures of the program. AV can detect these signs and make an educated guess that the program is packed by a custom packer and, if it meets some internal AV criteria, the AV may flag the program as malicious.
If the AV is able to detect the packer but does not have a routine to unpack it, the AV may still flag the executable as malicious based on the packer it detects. As you blogged about a few days ago, Alex Eckelberry at SunBelt Software did an experiment by packing Windows notepad with various packers and submitting it to VirusTotal. Based on his results, some AV programs are flagging programs as malicious based only on the packer that was used on it. (http://sunbeltblog.blogspot.com/2008/09/how-to-make-notepadexe-malicious-file.html)
What are some resources that I can learn more about packing?
If you want to learn the basics on packers, I would recommend Paul Craig’s 2006 Ruxcon presentation “Unpacking Malware, Trojans and Worms. (www.openrce.com) and the forums at http://www.reverse-engineering.net. I also like the Websense Security Labs blog (http://securitylabs.websense.com/) as they have posted in the past about their experiences with unpacking malware.
There really are way too many resources out there for me to list. In the end, Google is your friend.
Where can people find out more about me?
They can always check out my blog at http://secshoggoth.blogspot.com, follow me on Twitter (secshoggoth) or listen to me on the Security Justice webcast (www.securityjustice.com). :P
A commenter who was unable to post their comment for some reason had this to say:
PeID is a nice little tool for looking at an exe and finding what it is packed with, what encryption it may be using, and also to look at the strings. It also lets you unpack a lot of exe’s, but can be dangerous as it can let the programs run to do this. It’s nice to use it if you do not want to trace through a debugger and just want a quick way to look at the dll’s it hooks to and the strings in the program.
— digip
