Home > Articles
Cracking the nutshell
21th September 2007
Frank Boldewin / www.reconstructer.org
Table of Contents
STAGE DECRYPTER OR HOW TO FOOL ANTIVIRUS EMULATOR-ENGINES
ANTI-DEBUGGING AND DEFEATING
TEA DECRYPTION AND THE
AND WINDOWS DRIVER-CODE INFECTION
THE OEP AND DUMPING THE NATIVE PEACOMM.C
THE NATIVE CODE FROM VME DETECTION TRICKS
DISSECTING THE ROOTKIT DRIVER
"No nutshell is as hard as it can't be cracked with the right
tools. My tools are my teeth and I'm mad about nuts of every
On 22th August 2007 I received an email informing me about "New Member
Confirmation", including Confirmation Number, Login-ID and Login-Password.
To stay secure I should immediately change my Login info on a provided
website link. So I've started investigating what surprises are awaiting
people clicking on such kind of links. Next to a friendly message
telling me that my download should start in some seconds, I also got
a browser exploit for free, to ensure the "software package" gets
really shipped. "Hey that's cool", I thought by myself. "It's like
Kinder SurpriseŽ - three in one!" Unfortunately, at this time I hadn't
enough incentive for a deep analysis and so I just stored the malicious
file called applet.exe in my archive for later fun with it. Last week
I had enough free time to throw it into IDA and my debuggers. After
approximately one hour of investigation it was clear for me that the
time had come for a new research paper, as this malware disclosed
several interesting techniques, especially in the rootkit area. The
opponent for this paper is called "Peacomm.C" and outlines the currently
latest variant of this infamous P2P malware. The security industry
gave it also several other names like "Storm Worm", "Nuwar" or "Zhelatin".
The first variant "Peacomm.A" was detected in the mid of January 2007
and since then it has grown to one of the most successful botnets
ever seen in the wild. It uses an adjusted Overnet protocol for spreading
and communication. Its main intense is spamming and DDoS attacking.
Also the fast-flux service
network which is being used by the criminals behind the attacks is
really amazing and frightening at the same time. As its botnet activities
are not the focus of this essay, I've included interesting other papers
covering these topics.
This paper mainly focuses on two topics. The first
one aims to extract the native Peacomm.C code from the original
crypted/packed code, which means the following issues are covered
- First stage XOR decrypter
- Second stage TEA decrypter
- TIBS Unpacker
- Anti-Debugging code
- Files dropping
- The driver-code infection
- Finding the OEP to the native Peacomm code
- Finding and patching the VM-detection tricks
The second topic covers all the rootkit techniques of the spooldr.sys
driver. These issues are:
Security products monitoring/disabling
- SSDT file hiding
- Shellcode injection for process spawning
- System files locking
As goody to this paper, also included are the different binary
dumps and commented IDA .idb files.
As always use caution when reproducing the work described here.
Consider employing a virtual machine like VMWare or Virtual PC and
perform the analysis on an isolated network to avoid the damage
that could be caused by this malware. Use at your own risk!
3. Target Overview
To get an overview of our target first let's have a look at the
chart in figure 3.1
The first thing that happens in "area 1" right after the start of
applet.exe is an easy XOR decryption of the data in "area 3" followed
by jumping to this area which contains code now and performs several
tasks, like files dropping, decrypting and unpacking the native
Peacomm code in "area 2" and so forth. In the end all the imports
for the native binary are being collected/set and the code in "area
2" gets executed to attend to its "real business". But let's cover
this step by step.
4. 1st Stage decrypter or how to fool Antivirus
The figure 4.1 shows the complete routine used to decrypt the code
in "area 3". The instruction at 0x40101e tells us the data of EAX
it getting XORed with the value of 0x0149594f. But also take a look
at the instructions above. Next to XORing the data the return value
of a call to the function FreeIconList is added at 0x401019 as well.
Why this? - You might ask now, because the FreeIconList call should
always return the same value in EAX. So, this is a really useless
behaviour, right? The solution is, that this is an often used malware
trick, to crash or trigger an exception in Antivirus sandbox engines,
because FreeIconList is a legacy function of windows and thus often
not emulated by AV engines. While doing the research for this paper
I've downloaded several samples of applet.exe and found out that
next to the XOR key also lot's of other legacy API functions are
used. Additionally, I've also discovered that the decryption engine
completely changes from time to time. All of these routines were
easy to understand for a reverser, but definitely doing its jobs
to hide from AV signature based malware detection. Right after all
the data has been decrypted (0x38d0 bytes) a jump at 0x40102d executes
the code in "area 3" at 0x42321f. If you try to load applet.exe
into the IDA disassembler, you won't be able to see the decrypted
data at 0x42xxxx, because the binary works with fake PE- Header
information. This could be fixed to see everything in the idb file,
but you still would have crypted data in this area and an extra
idc-script would be needed to emulate the decryption. A much faster
way is to load applet.exe into Ollydbg, setting a breakpoint at
0x40102d with F2, running the code until breakpoint occurs, pressing
F7 for one single step into "area 3" at 0x42321f and then dumping
the whole binary using the Ollydump plugin. This is what I have
done to have one idb file for commenting.
5. Anti-debugging and defeating
The next step before we can start reading the disassembly on a
relaxed basis is to defeat a small anti-debugging trick. If you
load the lately dumped "after 1st stage decryption" binary into
IDA the new entry point will be 0x42321f. If you scroll down a little
bit to address 0x42330d now, you'll see (figure 5.1) a lot of junk
instructions (insb, arpl ...). As this code runs in user mode and
insb/arpl instructions are privileged, meaning only usable from
kernel mode without an exception and further the last
instruction that makes sense at 0x423308 calls 0x423324, this junk
must be something other than code. A short look using the "hexview"
of IDA discloses that these "instructions" are for real data or
better a string.
So, to get a "clean" disassembly, just mark the area between 0x42330d
and 0x423322, press `U' and then `A' in IDA. This should give the
result seen in figure 5.2 There are several of these little anti-debugging
tricks in the second stage and it's wise to clean the complete disassembly
before moving on with manual decompilation. Fortunately for this
binary, I have already done all the boring work. ;)
6. TEA decryption and the TIBS unpacker
Like in many other sophisticated malware, also Peacomm makes use
of an established cryptographic algorithm. One of the first things
that can be done to quickly find signatures of well-known crypto
functions is to scan for them. Ilfak Guilfanov, the developer of
IDA Pro, wrote a small plugin called findcrypt to do this job. Also
an Ollydbg port of this tool is available, but personally I always
count on KANAL v2.82 (figure 6.1), a PEID plugin, which has the
most signatures from my experience.
As we can see from the snapshot above two signatures were found.
The first one at 0x423f44 and the second one at 0x423f93. Furthermore,
we get the information, that KANAL found a single DWORD which is
used by multiple algorithms like TEA/N, RC 5/6, SERPENT and ISAAC,
means we have to read some disassembly.
In figure 6.2 you can see the main function of the TEA algorithm.
It uses a 128bit key (at 0x426A90) for decryption and will be called
several times in a loop until all the data of every PE-section was
For further infos and sample implementations of the TEA algorithm
consult the link in the references
Right after decrypting all the data with the tiny encryption algorithm
the TIBS unpacker routine is called. It enumerates all PE-sections
as well and then unpacks its data. The unpacking code can be found
between 0x4269f7 0x426a6e.
This non-public packer is used very often in malware nowadays and
most Antivirus companies have a generic detection implemented in
their scanning engines by now. So, if a malicious code is not detected
by its variant, e.g. because of its polymorphic behaviour, most
AV-engines still detect it by reporting something like: Trojan:Win32/Tibs.DU.
7. Files dropping and Windows driver-code
After all that decrypting/unpacking has been done, a routine at
0x4239df is called, which disables the windows file protection for
tcpip.sys and its cached copy using the non-exported sfc_os.dll
function 5 called SfcFileException (see the reference link for further
information). Confusingly enough, no more action is done with this
file, so I thought it must be an artefact from former variants.
First I believed an earlier version of Peacomm patched the max number
of outbound connections, which is typical for malware used for DDoS
attacks, but friends like Elia Florio from Symantec research told
me, that older variants infected tcpip.sys to load the rootkit driver
spooldr.sys. But for this special case the kbdclass.sys driver and
its cached copy gets infected with additional code for loading the
spooldr rootkit driver. Nicolas Falliere added the info, that the
SFC infection trick was broken for about 3 weeks. So they've started
infecting other driver like kbdclass.sys or cdrom.sys.
Next to the infection of kbdclass.sys two files are dropped. First
one is a self-copy of applet.exe saved as spooldr.exe in %systemroot%
and the second file is the overlay containing the spooldr.sys driver,
which gets detached to %systemroot%\system32.
8. Finding the OEP and dumping the native
Right after dropping the files and infecting the keyboard driver,
a routine at 0x423e5b scans the decrypted/unpacked native Peacomm
binary for its libraries and belonging function names and stores
the matching addresses to the functions.
Then a system command is executed to allow spooldr.exe at the windows
firewall with the following command:
netsh firewall set allowed program "%systemroot%\spooldr.exe"
The last action is a jump to the OEP at 0x403531 (see figure 8.1).
To get a clean native Peacomm.C binary, just load applet.exe into
Ollydbg, set a breakpoint with F2 at 0x40102d, run using F9, clean
bp with F2, step into with F7, set a breakpoint at 0x423283, run
again, clean bp, step into the allocated memory and search for the
jump instructions to the OEP, as this is a dynamic address for sure.
Then set a bp, run again, clean bp, step into with again and use
the Ollydump plugin to save the binary. That's all! Or if you are
lazy, just use my dumped version, shipped with this paper. ;)
9. Cleaning the native code from VME detection
Ok, now as we have a clean native Peacomm.C code for analysis it
would also be nice to run it on a virtual machine like VMWare or
Unfortunately, we have to defeat two vm-detection routines before
achieving this. The first check is right after the OEP at 0x403389,
calling a routine at 0x4031bc. It's a VMWare detection using the
ComChannel VMXh magic trick (see Figure 9.1)
Just some instructions away from the VMWare detection is the second
call to a virtual machine detection routine at 0x40339c jumping
This time it is a Microsoft VirtualPC detection using the illegal
Opcode exception trick (see Figure 9.2). For further information
on both VM- detection tricks, read Peter Ferries excellent paper
on virtual machine attacks v2. A Link to this paper is included
in the references.
If one of the environments is being detected, a jump to a "sleep
forever" loop at 0x403524 is called. One easy way to circumvent
this, would be to patch 2 bytes at 0x40338f with a direct jump to
0x4033a9 (push ebx).
Use your favourite hex-editor or just Ollydbg, if want to do this.
10. Dissecting the rootkit driver
Ok, you've reached the last part of this small essay. In my opinion
the most interesting one, as this rootkit uses some techniques I
haven't seen in the past. But before I get into detail, first let's
observe what the RkUnhooker report said.
The figure 10.1 just shows an oldschool SSDT hook of the native
function NtQueryDirectoryFile and the figures 10.2 and 10.3 reveal
the therewith related hidden processes/files.
The figure 10.4 also shows the call to the hooking code for all
But this is definitely not really a cutting edge rootkit, right?
And any run-of-the-mill AV solution or personal firewall would detect
or block this.
So, where's the news?
Take a look at figure 10.5 and you will see a call to the function
PsSetLoadImageNotifyRoutine with a parameter that points to a driver-
supplied callback routine.
On the windows driver developers site OSR-Online we can read:
"PsSetLoadImageNotifyRoutine registers a driver-supplied callback
that is subsequently notified whenever an image is loaded for execution."
For detailed information on this function consult the link in the
Figure 10.6 shows us this routine in detail.
As you can clearly see from the commented code at the beginning
it checks if a driver or a normal user mode program has been loaded.
If it is a program it gets terminated using the ZwTerminateProcess
function and if it is a driver, the routine scans for its EntryPoint
and patches it with:
XOR EAX, EAX
So, after the driver starts, it just returns with 0 and ends.
As we learned from the former chapters this all happens right after
loading an early driver that was infected before, like kbdclass.sys,
cdrom.sys or tcpip.sys, who then immediately spawns our rootkit
driver. Every driver and program that is loaded after spooldr.sys
is under full control of the rootkit. And now it should be clear
why a normal SSDT hook for hiding the driver is enough. No security
products, no problems. ;)
Here is a complete list of security products which are disabled
at system start:
Jetico Personal Firewall
McAfee Personal Firewall
Symantec Norton Antivirus
Symantec Norton Internet Security
Check out the After-1st-XOR-Decryption-Dump.idb file for details
which executables are in conjunction with these products.
Another sneaky trick can be seen in figure 10.7. This special function
scans the explorer.exe process and hooks the import entry of the
PeekMessageW function, which is called very often by explorer, with
a special shellcode that deletes the import entry for PeekMessageW
and spawns the spooldr.exe in this trusted space. This is a nice
trick to omit the usage of CreateRemoteThread, which most security
products monitor today and as not all available sec-software were
included in the termination list, it was a wise decision to use
this much more sophisticated way.
The last thing what is worth being mentioned, can be seen in figure
The rootkit also locks two files, ntoskrnl.exe and the infected
kbdclass.sys driver, using NtLockFile. My assumption was that this
is to reject access to these files from user mode, e.g. when tools
Hijackthis try to scan for suspicious changes in these files, because
file locking is no stumbling block for kernel mode tools like rootkit
scanners or AV-products.
After this small excursion into the world of Peacomm.C it should
be clear that the developers of this malware deal with a lot of
nasty tricks to gain access to victims' machines and hide from detection,
even on standard protected boxes. Analyzing malware gets harder
and just using the usual auto-analysis tools, seems not very target-aimed.
The AV and PFW industry has to think of better heuristics in behaviour
analysis, smarter ways of generic unpacking and more reliable system
integrity mechanisms to safely recognize such cunning tricks used
in sophisticated malware like
this one. As 100% solutions will stay a pious hope, reverse engineering
knowledge is still the weapon of choice for the analyst. I hope
you enjoyed this paper a little and as always - constructive reviews
are much appreciated.
Catch me if you can
Botnets: Overview and Case Study
Tiny Encryption Algorithm (TEA)
on Virtual Machines v2
Disabling WFP on a file for 1 minute via undocumented SFC
Big thanks go to Elia Florio and Nicolas Falliere/Symantec, Val
Smith/Offensive Computing and Thorsten Holz/German Honeynet Project
for reviewing this paper!
Reproduced with kind permission of Frank Boldewin