When talking about new concepts, its always best to demonstrate them on something everyone is familiar with. In our case that's of-course UPX with which we are fairly familiar. It almost feels like we write one UPX unpacker each week, doesn't it?

Today we are presenting an optimization concept that enables us to unpack everything in a single go. Now, when talking about file unpacking we always unpack everything in one go, but we never unpack both the main executable module and all of its packed dependencies in a single run. Normally, you wold do this by batching through individual files.  But from a speed perspective, the best optimization imaginable comes from unpacking the main module and all of its dependencies at once. Since TitanEngine wasn't really designed to do that out-of-the-box, it needs just a little bit of help to pull it off.

The problem is the existence of multiple relocation tables, and more importantly multiple import tables. Since TitanEngine was designed to unpack files one at the time, we must do some additional coding around these boundaries to achieve our goal. Compared to a traditional TitanEngine dynamic unpacker, the only difference is the need to collect import table data for modules in one place, and use that data for any module that has reached its entry point jump. The UPX is a special case because it always imports packed file dependencies through the import table. This is, of course, a static way of importing libraries but our approach must be flexible enough to cover both dynamic and static importing.

To achieve our goal we have to scan the main module and all loaded libraries and try to find  the appropriate patterns. Once the patterns are found, we set breakpoints and store info about them so we know which module triggered which callback event. Normally we have three callbacks for UPX unpackers (LoadLibrary, GetProcAddress and EP jump) but since we are doing transverse unpacking we need one more: the load library event custom handler, which determines whether the loaded dependencies are packed with UPX by trying to find the neccessary breakpoint patterns. Even though it is impossible to have more than one module loading at a time, we still need to store the import data because the import tables for the main executable and dependencies might overlap if the modules are loaded dynamically. Once stored, the import info for each module is retrieved when it hits its entry point callback. Relocations aren't really a problem since there is just one module loading at a time, so we can use our "snapshot and compare" model, provided that modules load on non-default image bases. This can be done in numerous ways - one of the easiest is to compile the sample files so that they do that by default (which is considered cheating in the unpacking game), alternatively, we can pre-allocate the memory so that the modules have no choice but to pick another base address. For the purpose of this blog we cheated, in a real world application of this approach you mustn't.

In the real world you will hardly ever see this kind of case but if you do, you now know how to get everything in one go. Until next week...

TitanEngine ReversingLabs Corporation

RL!deUPX (package contains the unpacker with source and the samples used)

As we said in the blog dedicated to our latest TitanEngine release we are continuously working on expanding our SDK to support as much programming languages as possible. That is why the next major version update for TitanEngine will feature a support for LUA scripting language. This is it from ReversingLabs for this year. Enjoy the holidays!

TitanEngine just became Linux friendly! Even though this framework was and is designed only for Microsoft Windows x86/x64 platforms it can work with no problems under Linux with the help of WINE. Small modifications were necessary in order to make this possible but from next release you will be able to execute all ReversingLabs unpackers under Linux distribution of your choice. We have chosen Ubuntu, what is your choice?

This ensures maximum safe environment for live malware analysis for those reverse engineers that make Linux their platform of choice.

The reason we chose to do MEW (again) is that in its version 5 it is a simple crypter which can be used as a perfect example on how to write static unpackers for these kind of crypters. That kind would be the kind that doesn't do anything to imports but only encrypts the executable code section. Next time we revisit static unpackers we will be talking about such cases. We are going to leave that aside for now because this Monday is all about simple and fast unpacker writing. Start your timers we will do in under 10 minutes.

Minute 1 - 2:

We load our sample into Olly and see the entire MEW5 code at the entry point.

  MOV ESI,0040005B
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,ECX
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,EBX
  PUSH EBX
  LODS DWORD PTR DS:[ESI]
  XCHG EAX,ESI
  PUSH ESI
  POP EDI
L010:
  LODS BYTE PTR DS:[ESI]
  ROL AL,29
  ADD AL,BA
  ROR AL,50
  STOS BYTE PTR ES:[EDI]
  LOOPD L010
  RET

Yes, that it. The whole code. So what does it do? First it loads a pointer to all internal information into ESI register. We follow ESI in the hex dump to find that there are 3 DWORDs that have the data necessary for unpacking. First DWORD is 0x3000 which is the size of the first section, second DWORD is 0x004012c0 which is the address of the original entry point and third DWORD is 0x00401000 which is the virtual address of the first section. Code following this loads 0x3000 bytes one by one and decrypts them with a custom decryption algorithm. Here instruction sequence ROL, ADD and ROR is used to decrypt data.

Minute 3 - 4:

We make a copy of existing TitanEngine SDK sample for DEF and use that as a template for our unpacker. We are making a Delphi unpacker since,... well since TitanEngine is low on Delphi samples and this is a nice and quick exercise.

Minute 5 - 9:

We code the unpacker. First we need to read the ESI pointer and read the data from the file. Once we make that we convert third DWORD to physical address inside mapped file and we also convert the original entry point address to relative one. Simple call to StaticMemoryDecryptEx makes sure that our StaticCallBack decrypts the data by executing this custom decryption algorithm. Lastly we add the code to store the new entry point to PE32 header and we're done.

Minute 9:47 - 10:

We run the compiled unpacker to test if it works... Success!

TitanEngine ReversingLabs Corporation

Download RL!deMEW5 unpacker (package contains unpacker binary, source and samples used)