:wq - blog » reverse http://writequit.org/blog Tu fui, ego eris Mon, 22 Dec 2014 14:54:59 +0000 en-US hourly 1 http://wordpress.org/?v=4.1.5 Example malware unpacking and analysis: part 1, unpacking http://writequit.org/blog/2008/05/09/example-malware-unpacking-and-analysis-part-1-unpacking/ http://writequit.org/blog/2008/05/09/example-malware-unpacking-and-analysis-part-1-unpacking/#comments Fri, 09 May 2008 23:22:47 +0000 http://writequit.org/blog/?p=165 Lo! I still live! I apologize for the very very long delay that I’ve been putting everyone through lately, I’m sure I was terribly missed ;) *Ahem*, anyway, on with the post:

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.

]]>
http://writequit.org/blog/2008/05/09/example-malware-unpacking-and-analysis-part-1-unpacking/feed/ 3
Get disass-cli working properly on OSX and Freebsd http://writequit.org/blog/2008/04/11/get-disass-cli-working-properly-on-osx-and-freebsd/ http://writequit.org/blog/2008/04/11/get-disass-cli-working-properly-on-osx-and-freebsd/#comments Fri, 11 Apr 2008 19:20:49 +0000 http://writequit.org/blog/?p=162 I’ve been digging into the world of exploit writing lately, working on Defcon‘s previous year’s CTF qualification programs, I ran into Atlas’ presentation on “Kiddie to Hacker in 5 sleepless nights”, which talks about some of his mindset when he first got into binary exploitation.

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 :)

]]>
http://writequit.org/blog/2008/04/11/get-disass-cli-working-properly-on-osx-and-freebsd/feed/ 3
Tutorial: Finding the OEP of an Upacked binary file http://writequit.org/blog/2008/02/25/tutorial-finding-the-oep-of-an-upacked-binary-file/ http://writequit.org/blog/2008/02/25/tutorial-finding-the-oep-of-an-upacked-binary-file/#comments Mon, 25 Feb 2008 19:57:26 +0000 http://writequit.org/blog/?p=150 …because all the other tutorials I’ve been able to find on this subject are not so easy to read.

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:

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:

0peid.png

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:

1idastart.png

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:

2pushbp.png

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:

3running.png

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:

4hwbp.png

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

5hwbp2.png

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:

6afterhwbp.png

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:

7lordpe.png

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

8lordpedump.png

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

9sizecmp.png

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

10iatmissing.png

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):

11imprecnewoep.png

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

12autosearch.png

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

13importsfound.png

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:

14fixdump.png

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

15sizecmp2.png

And now, try and run the file:

16running.png

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…

]]>
http://writequit.org/blog/2008/02/25/tutorial-finding-the-oep-of-an-upacked-binary-file/feed/ 3