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

This is going to be a long post, but hey, at least it’ll have lots of pictures!

Alright, in this tutorial I’m going to attempt to explain how to find the OEP (Original Entry Point) of a binary executable that has been packed with the Upack/WinUpack packer. I just recently learned this myself, so please excuse any errors this tutorial might have. In this tutorial, the following tools are used:

• PEiD
• IDA-Disassembler (I used the freeware version, 4.9)
• LordPE
• ImpRec
• Windows

Sadly, I haven’t figured out how to get this working the same way in Ollydbg yet, but perhaps for a later tutorial. Alright, let’s dive right in. In this example, I’ll be using the “calc.exe” application (Windows calculator) that I packed with WinUpack. The first thing to do is load the file into PEiD to try and determine what kind of packer was used on the file:

You can see in the red square above that this file was packed with WinUpack 0.39 final, which is good because that’s what this tutorial is about

The next thing to do is load the executable into IDA-pro, IDA will complain about the file, but for the most part these complaints can be ignored, just click “ok” and “yes” until you see something similar to below:

Here, you can see the start of the file, the line we’re most interested in is (in this file), the line at 0100101F, which is a "push dword ptr [esi+34h]” instruction. Select this line and hit F2 to toggle a breakpoint on this line. The line should highlight red just like the picture below:

Now, press F9 to run the file until it encounters the breakpoint. When IDA does encounter it, the display will change to the following style, take note of the IDA-view ESP box highlighted in red below, that’s what’s going to be important coming up:

Right click on the ESP address (in this case 0007FFC0) and set a breakpoint, we want to set a hardware breakpoint or size 4 on this address, see the picture below for what I mean:

After setting it, the line will highlight red like this:

When the breakpoint has been set, continue running the file by hitting ‘F9′ again. When IDA hits the breakpoint, you’ll see the following two windows:

Notice the red box, this is our new OEP: 01012475. Write this number down somewhere (or remember it). Now that we know our OEP, we need to dump the file and fix the imports, the first step to dump the file is to open up LordPE and select the running calc.exe process, as seen below:

Right-click on the file and click on “dump full”, as you see here (I saved my file as calc-dump.exe):

Here you can see a comparison of the sizes of the packed and unpacked files:

Let’s run the file and see what we get, oops, looks like we get the error below:

This means the import table is all messed up, we’ll have to fix it. In order to do that, fire up ImpRec and point it at the active calc.exe process, in the OEP box, enter the OEP we found earlier (just the offset, which in this case is 12475):

Then, click on “IAT Autosearch”, you should see a message like this:

Click on “Get Imports” and the window should be filled with a list of imports found in the file, like this:

In order to fix the dump, click on “Fix Dump” and select the file you dumped earlier (in my case it was calc-dump.exe), ImpRec will fix the dump and save a new file, if it works correctly, you should see these messages in the log:

Let’s compare these size of all 3 of these files:

And now, try and run the file:

Hurray! It worked! From here you can do everything you need with the file, since it is no longer packed. I hope this helps someone, it certainly helped me understand unpacking a little bit better. Now I can get to unpacking that malware I captured earlier…