The art of unpacking Conficker worm

Over the past two years, rarely did a worm get as much attention that Conficker (aka Downadup) is getting now. Its last variant, the infamous W32/Conficker.C, which surfaced in early March and is set to time-bomb on April 1, is literally all over the media. Of course, its features are well known and documented and some papers (such as SRI’s excellent analysis and a blog post from Sourcefire) even give interesting insights on the reverse engineering process. Indeed, while understanding the behavior of the malware is important to most people, learning how to understand it is even more important to some. Does the fable of the fisherman who gives the hungry man a fishing rod rather than a fish sound familiar?

That is the purpose of this post. While not delving into the depths of reverse engineering Conficker, it aims at providing a few tips to whomever may want to participate in the community efforts, for a better understanding of the infamous worm variants. And the best part is that part of these tips apply to other malware pieces.

1. Equipment

The first thing to note is that Conficker is encrypted/compressed by a custom “run-time packer”, which is a very common strategy to prevent static analysis. Indeed, should you load a copy of the worm in a disassembler, all you’ll see is the assembly code of the said run-time packer, and a bunch of compressed data.

The first thing to do, therefore, is to unpack it, to reveal the actual assembly code of the worm.

The following gives some insights that may be useful to achieve this, using OllyDbg and IDAPro.

Note: It is assumed that doing this in an isolated and safe lab machine is required to avoid possible infection of internal networks.

2. Loading the malware into the debugger.

The Conficker worm is in fact a DLL file, sometimes obfuscated by a first layer of UPX run-time encryption/compression. Thus it’s a good idea to give it a first pass of unpacking with the appropriate UPX version, before loading it into the debugger.

We all have our own methods for debugging DLLs, and my personal choice is to modify the DLL bit flag to turn it into an EXE to the eyes of the debugger. Among other PE editors, CFF Explorer from ntcore is a tool that allows to do that.

Now open the file in OllyDbg and ‘Step into’ the DllMain() function.

3. Choosing the unpacking method

Run time packers are commonly hard to trace due to many anti-debugging tricks being employed by the malware authors. Yet all of them will certainly undergo some stages before jumping to the actual malicious code.  We can roughly divide the unpacking process flow into the following simplified flowchart:

Conficker follows roughly this sequence, decrypting byte by byte and saving the data in non-contiguous location, before reconstructing it again to copy somewhere in memory. That said, there are really two methods to unpack the actual malicious code:

• Either you reverse-engineer the unpacking algorithm, re-implement it in a scripting language, and run the script on the packed file (long and tedious)
• Or you let the run-time packer do the unpacking job for you, and catch a break right before the execution flow is passed to the actual malicious code

The latter method is the one we’ll explore here; while it is quicker, it has a drawback: it implies defeating the anti-debugging tricks scattered over the unpacking code, which are precisely meant to prevent the code to run inside a debugger.

Read the rest of this entry »