Introduction

Firstly, malware analysis and reverse engineering has always been incredibly interesting to me and I noticed that ever since my OEP finding tutorial for UPACK, I’ve also gotten a lot of google searches for “how to reverse malware” and other such things, so, I figured I’d share my meager knowledge, seeing as how other blogs have been so helpful thus far, and they always say the best way to learn something is to teach it. I decided that it would be cool to start a series about analysis from start to finish, explaining how I analyze the file. Anyhow, enough of my rambling, on with the analysis!

Part 1: Unpacking the malware

Disclaimer: I’m using real malware, in a Windows VM. If you don’t know what you’re doing, you can get infected. I’m not responsible for that part

Tools for part 1:
– Malware – For this entire series I’m going to use a piece of malware I got from the Vulnerable Minds blog, specifically from this post. It’s called “microsoft110.exe”. You can also find the malware on offensivecomputing.net under md5 “426504b6cadf2331ef980858316349ed” if you have an account (it’s free).
– PEiD – For checking the type of packer used.
- Ollydbg 1.10 – For the unpacking part, I’m going to use Olly, just because it’s easier for this section of the analysis. You’ll also need the Ollydump plugin for ollydbg.
- ImpREC – For fixing imports, this is what you need.

Alrighty, microsoft110.exe uses a fairly standard packer, UPX, which is easily unpacked, both manually and automated. There are a fair number of tutorials about unpacking it already and some scripts to automatically unpack it for you, but I’m going to do it manually. You can tell that microsoft110.exe is packed with UPX by loading it up into PEiD:

Okay, now that the packer was verified, load it up into Olly, you should see the following starting instructions:

00424230 > $ 60 PUSHAD
00424231 . BE 00804100 MOV ESI,microsof.00418000
00424236 . 8DBE 0090FEFF LEA EDI,DWORD PTR DS:[ESI+FFFE9000]
0042423C . C787 00770100 >MOV DWORD PTR DS:[EDI+17700],4707FE20
00424246 . 57 PUSH EDI
00424247 . 83CD FF OR EBP,FFFFFFFF
0042424A . EB 0E JMP SHORT microsof.0042425A
... etc etc etc ...

The instruction highlighted in red (PUSHAD) is (most of the time) the indication that you can use this kind of unpacking to get an inflated executable. This instruction is used to save all the general registers onto the stack, so that UPX can do it’s decryption/decompression (I’m unfamiliar with UPX internals, so I can’t say which it is out of certainty). After unpacking, the registers are restored with the POPAD instruction and regular execution is started. So basically that’s where we need to stop and dump the process.

Anyway, back to the analysis, press F7 once to step into the PUSHAD instruction, note on the right you’ll see the registers change color, see the figure below:

We’re going to be following the stack pointer in memory, so right-click on the ESP value (00424231) and click on “Follow in dump”, the bottom window will display a hex dump of the memory at this address:

Note the values in ESP and the first value in the Address column match. Next we’re going to want to set a hardware breakpoint on the 4 bytes (08 02 91 7c) at the 0x0013ffa4 offset, so select the 4 bytes, right click and select breakpoint -> hardware, on access -> dword.

Now that a breakpoint was set, press F9 once to continue execution until we hit the breakpoint. When a breakpoint is hit, scroll up a little and you should see something like this:

0042437E .^EB E1 JMP SHORT microsof.00424361
00424380 > FF96 B0410200 CALL DWORD PTR DS:[ESI+241B0]
00424386 > 61 POPAD
00424387 .-E9 BC1AFFFF JMP microsof.00415E48
0042438C A4434200 DD microsof.004243A4
00424390 AC434200 DD microsof.004243AC
00424394 00874100 DD microsof.00418700

The blue line above is where the breakpoint stopped us, as you can see after scrolling up, a POPAD instruction (in green) was used immediately prior to the JMP instruction. In this simple example, all that’s required is to press F7 once to step into the JMP command, and you should have reached your OEP.

Now that the OEP was reached, use the ollydump plugin to dump the process in memory to a file, you can see the new OEP in this window, make sure that you uncheck the “Rebuild Import” option before dumping:

Take note of the modified OEP, which in this case is 0x15e48 (for later). Now that you have a dumped file, the imports have to be fixed, so fire up ImpREC and attach to the process for microsoft110.exe

In the box labeled OEP, put your new OEP (00015e48) and click on IAT AutoSearch, hopefully you will see this:

Which means the import address table was found. Now you can click on “Get Imports” and then “Fix Dump”, select the executable you dumped with ollydmp and ImportREC will fix the dump. Analysis may now begin.

This post is getting overly long, so I’ll stop here and pick it up with the next post. Be on the lookout for part 2 coming soon.

Well, regardless of whether this helped someone else or not, I’m much more likely to remember the process the next time I unpack some malware since I wrote/typed it down. Currently I’d say I’ve gotten about a third of the analysis done on the actual malware itself using IDA, so it’s slow going but picking up the pace. If you have any corrections or suggestions, *please* let me know, I’m not an expert in this subject, and I appreciate any feedback I get.

Atlas has written a tool call disass to aid in disassembly and analysis, which is a really cool tool, but can be kind of annoying to get running on different operating systems thanks to Python’s amazingly helpful error messages </sarcasm>

Firstly, make sure you install the dependencies, Python (duh), psyco, atlasutils (from Atlas’ blog), libdisassemble and vtrace (from the Kenshoto guys). Then, install disass-cli (also from Atlas’ blog) just like you would any other python program. You might need to symlink /usr/local/bin/python to /usr/bin/python since disass-cli’s sharp-bang is hardcoded for /usr/bin/python

The first time you run disass-cli, you’ll probably hit this error:

# disass-cli
Traceback (most recent call last):
File "/usr/local/bin/disass-cli", line 3, in <module>
from disass3 import *
File "/usr/local/lib/python2.5/site-packages/disass3/__init__.py", line 105, in <module>
import bsddb
File "/usr/local/lib/python2.5/bsddb/__init__.py", line 51, in <module>
import _bsddb
ImportError: No module named _bsddb

Cryptic eh? Googling is not so helpful on this one (“Recompile Python!”) Well, to fix the problem on FreeBSD, you need to install /usr/ports/databases/py-bsddb, which will rebuild Python with the necessary libraries, easy fix.

On OSX, you’ll need to download the newest Python distro .dmg from python.org (which will have the correct libraries). Now you can update the symlink by doing:

# rm /usr/bin/python
# ln -s /Library/Frameworks/Python.framework/Versions/2.5/bin/python /usr/bin/python

as root. Now you should be able to reinstall the dependencies for disass using the newer Python distribution and disass-cli shouldn’t complain anymore, silly broken Apple versions of Python.

Note: Alternatively, you can edit the disass-cli Python file (in /usr/local/bin/disass-cli) to use the Python distribution you installed directly without changing the symlink, that way everything else still uses Apple’s version of Python (don’t forget to install the dependency libraries for the newer version of Python also).

Hope this helps someone, exploit writing is new to me, coming from more of a network-side, always fun to learn new things