At the end of our BlackHat presentation on which we unveiled our TitanEngine project we promised to keep supporting it and to publish one unpacker demo per week. And this was true since our first update release for TitanEngine contained quite a few samples.
But since the next update isn't all that close we will stick to our word and publish and blog about the samples ReversingLabs itself contributes. In that spirit we are revisiting the packer we created for mPack ages ago.
So why is mPack interesting? Just because we haven't yet published a source for unpacker that uses overlay to store the compressed file. Interested? Read on...
Ovelay is by definition a piece of data appended to the end of the PE file. In this case that appended data is a compressed executable which sounds logical since we know that mPack was written in Delphi as a proof of concept packer, and since overlay packing is the most simplest form of packing it was used here. The trouble with this is that the compression method weren't documented so we need to "guess" what kind of compression was used and how it was implemented. Which is the fun part of reverse engineering.
There are two things we can do here and we are going to use both approaches for both supported and known version of mPack. Firstly we can reverse the stub which decompresses the packed overlay and this is fairly easy. We can set a few breakpoints on CreateFileA and ReadFile to see when the overlay is read and then just trace until we find the algorithm in charge of decompression and just rip it so that it can be used to unpack compressed memory segment. When talking about mPack 0.2 you need to realize that compressed overlay is segmented and compressed by chunks of 0x1000 bytes of code. Each segment in the compressed overlay begins with the DWORD which tells you the size of the compressed segment. Therefore you need to keep decompressing and reconstructing the file while that DWORD is greater then zero. Once all segments are unpacked you are done.
Second approach can be used and applied to mPack 0.3. This is a lazy man approach and that means no code tracing whatsoever. Like it? We did too. So what you want to do is just extract the overlay and take a look at the compressed overlay. Once again there is a DWORD before the compressed data. Since that DWORD is greater then the size of the overlay and its a nice and round number its safe to assume that that is the size of decompressed that. But what compression algorithm was used. First byte of the compressed overlay is 0x78, so one quick Google search and we get to this website which kindly points us to zlib compression. Yes, just that easy. No code tracing at all. But same info could be found if we got our hands dirty for a few seconds and did some file analysis.
Once the two are put together you come up with a nice unpacker which demonstrates how to use TitanEngine to write static unpackers, more specifically how to unpack packers which store compressed binaries inside overlay. And that is something we haven't shown in our samples which makes this a nice Monday exercise.
