Unpacking

[zero_tolerance]

By Max_Power

A lot of people have been bugging me about re related junk lately, something I wish they wouldn't do, but anyway, the latest big this is, "OMG HOW DO I UNPACK THIS!!!!"

Unpacking is an art that must be learned through trial and error. I would also like to add a new quote to my unique quotation database by saying, "In order to meet and exceed your potential it is necessary to become well versed in the fundamentals of all of your endeavors as to have a solid base from which to propel yourself toward the unknown." God I am a geek...

Anyway, get a solid base by reading up on some well known packers and maybe go through a walk through or two on how to unpack them. It would also be a good idea to get some literature on how a packer actually works, and even maybe how to make one.

The next step is to cross into the unknown and expand your knowledge without a safety net, something tutorials act as way too often for some people. The best way to get really good at unpacking is to create a dummy program on which you will test packing and unpacking x packer on with variable settings. This program should have several attributes to make your job easier:

1. It should have a message box near the entry point so that you know exactly when you have come across the original entry point (oep) in the packed executable.

2. It should have a dialog, simple or not so that you can test any resource packing junk.

3. It should have multiple imports as to get practice manually fixing an import address table (IAT).

4. It should have several string constants sprinkled about so that you can both get your bearings in a packed executable while debugging, and get quick feedback on your success.

5. It should be programmed in a low level language (LLL), asm is a 10/10, but if you don't know asm well enough to program in it then C/C++ will act as a good 7/10. The reason for this is that an LLL will have much neater code present in the end product then a high level language (HLL) will due to the conversoin from HLL to LLL or because of compiler optimizations, as you will run into with C/C++ unless you do your settings properly. With asm, the code you write is the code in the end product, thus you know it like the back of your hand (literally each instruction) when debugging.

Minimum tools required:

1. A debugger (I usually use OllyDebug, in fact I basically use it exclusively).

2. Procdump (for dumping the exe).

Once you have used the minimum tools awhile and can call yourself a master you can justify using other tools to make life easier, like something to fix the IAT for you. I also suggest you have a packed version and an unpacked version of this dummy program when manually unpacking (MUPing) a new packer so that you can see them side by side. Also a pe editor (one is built into procdump, although I prefer the one that comes with PETools) will save your life when you are getting confused.