Monday, January 31, 2011

IDA Pro: universal Unpacker

Since some people wrote to me in the past days saying they are interested on IDA Pro, I decided to follow a little bit on this topic. Today I want to show you how to use the IDA pro universal unpacker.

There are many ways to confuse (or to sidetrack) the reverse engineer, but I will cover this topic later in the following posts. One of these many ways is to use a packer and/or encrpter. Packing and Encrypting are two different math functions, the first one is oriented on saving space the second one oriented on making secret the code, but in both ways they are a good to obfuscate the original code. Obviously unpacking is easier then decrypting, in many situations in order to unpack a program is enough to figure out what type of packer has been used, after that many IDA plugins help us in the unpacking procedures. On the other hand if the program has been encrypted we need to figure out the math (and frequently the key too), and this procedure becomes pretty hard.

Fortunately there are many different ways to unpack/decrypt a code; two techniques overall are: (1) the static techniques and (2) the dynamic + dumping code techniques (again I will cover this topic in the next posts). Today I wanna show you how to use the default IDA Pro unpacker plugin (belonging to the (2) techniques set) to find out the Original Entry Point (OEP). The OEP is the original address of the main. Every packer/crypter puts a new Entry Point referring to the unpacking/decrypting function (often added to the header of the binary) which reading directly from itself unpacks/decrypts the further bytes.

As shown in figure the packer/crypter wraps the original PE header with a self routine able to unpack/decrypt the original PE file. Our goal is to find the original "main", in such a way there is no need to understand how the packing/crypting algorithm works. In the above example UPX packer (UPX is a great packer, pretty easy to detect and to bypass but still very interesting since it is opensource. There are many variants of packers, ASPack is only another great one. For a more complete list of packer here) has been used.

The main question when you are decompiling a binary is how can I recognize that this binary has been packed/encrypted ? Again there are at least two ways to do so, but for now I am going to answer using signature detection. Each packer/encryptor has a unpack/decrypt routine which a specified signature. PEID is, probably, the most famous tool able to recognize the used packed. This is possible thanks to the huge community behind the software who writes signatures for each new packer, something like signature based AV.

Under the IDA point of view, when you open a packet/encrypted binary you may see in the import table dynamic-links library functions like the following ones:

Dynamic-link libraries are very commonly used from packers to restore the original executable's import table. Once we recognize the presence of packers lets run the IDA pro unpacker plugin.

Immediately after the execution of the plugin IDA Pro will ask where it has to stop the plugin execution. The plugin calculates the stopping memory area by itself but if you need to modify it (for example you recognized a multi thread packer/crypter) a dialog box appears next to the main window.
Fix your breakpoints on the code dynamically, once the plugin reaches your break points, it will create a new segment refilled with the unpacked code. The unpacked code is basically a representation of what the original code have executed until the breakpoints, it is not the real (or even the original) code at all. You will see something like :

Which is much better than the previous one ;), but still no perfect at all. PEID and yourself (if you keep time to investigate into the strings) after the unpacker/decrypter procedure, will figure what kind of complier has been used.

IDA FLIRT libraries help you to rebuild the original binary knowing the used compiler. Lets apply the right FLIRT and see how better is the resulting code :D

Isn't pretty code ? :D

Friday, January 28, 2011

Yet on Physical Security :)

Hi folks, today I laughed too much seeing this picture. Thanks to Tomas for sharing it !

Unfortunately this scenario is not uncommon at all, I am just remembering my old post on the argument. :D

Tuesday, January 25, 2011

How to Patch Binary with IDA Pro

Last night I received a couple of emails from friends of mine asking how to patch binaries through IDA Pro. I was pretty tired for writing a full answering email so I decided to send them a good link... I wasn't able to find out a good link on the argument. :O !!

For this reason today I want to show you how to patch a binary using IDA Pro. The patching process is maybe the most difficult part of reversing engineering since you need to modify directly the binary code without compromising the program control flow. You need to figure out what the binary does, where it does what, and how it performs the actions you want to modify. For example, if we consider a key-generator design process what is mainly needed is the key generation function. In order to build the generation procedure (in the key-generator)we need to copy the "generator function" (in the binary) and paste it on a generic assembler "print out" template. Running the compiled template you will see as output the generated keys. If you prefer to patch the original key-generator you need inject/modify/delete instructions directly on the binary without altering the control flow and without triggering exception handlers.

To remember: In this post I am not going into the details on "the binary patching process" but I am going to explain how to use IDA for such a process.

First of all you need to edit an IDA configuration file called idagui.cfg . The file has been placed from the installer into your IDAFolder/cfg/idagui.cfg. On my Windows machine it is placed into: C:\Program Files\IDA Free\cfg\idagui.cfg.

You want to change the following two lines: DISPLAY_PATCH_SUBMENU = YES and DISPLAY_COMMAND_LINE = NO (but you might want to see it, so put an uppercase YES)

Running your IDA Pro you now see a new sub menu EDIT -> Patch Program.

Now, using the "Patch program" submenu you are able to edit the IDA database. Don't forget that you are now editing the IDA database which represents the real binary (it isn't the original binary) so you aren't patching you binary yet.

Once you've done with your changes you are now ready to generate the DIFF file through: FILE->Produce File-> Create DIFF File, as shown in the following image.

The DIFF file does NOT include the copy of the modified binary but it simply enumerates what and where changes happened. For example the following listing is an example of what DIFF file includes.


00001545: 7D EB

00001546: 2B 2A

0000158D: 7C 7D

0000158E: B9 B8

000015DE: 75 74

000015DF: 1F 1E

000015E3: 76 75

000015E4: 16 15

00001607: 74 EB

00001608: 29 28

In address 00001545 the byte 7D became EB, in address 000015DF the byte 1F became 1E etc.
Now what you need is to download and compile the following utility called ida_patcher.c (from here). ida_patcher does the real patching.

Lets run the patcher in the following way :

./ida_patcher -i executable.exe -p executable.diff

Where executable.exe is the original binary file and executable.diff is the DIFF file from IDA Pro. Watch out that ida_patcher modifies the original binary, so be sure to have a backup of your original one. Now you've got the patched file ready to be spread ;)

Another great tool to batch binary using DIFF file is here (thanks to StalkR)

Thursday, January 20, 2011

Google Goggles Sudoku Demo

When I saw it ? Only WoW man !

PDF-Online Tools

Today I want to post a little bit about a great and interesting service called PDF Tools Online, pointed me out by CeSeNA's group.
PDF online tolls offer a complete PDF elaboration framework such as: PDF analysis and repair tool, PDF optimization tool, PDF to Image converter, PDF extraction content, Image to PDF convert, PDF password protection and much more.

Since new CTFs are anymore based on attack defense challenges but rather then focused on single "trivia" questions. It turned out that knowing how to modify (and repair) PDF is pretty important to gain points on new generation CTF. So enjoy the PDF tools suite :D

Wednesday, January 19, 2011

AutoDiff Online

Hi Folks,
today (jetlagged and sick to travel :) I want to share the AutoDiff online service available here.
AutoDiff is a project which performs automated binary differential analysis between two executable files. This is especially useful for reverse engineering vulnerability patches and spotting other additional code updates. AutoDiff allows to find executable code similarities and differences among two executable files. Additionally it also includes some heuristics methods for matching variables (objects) between two executable files. AutoDiff is ultra fast, standalone tool. It was especially designed to diff Portable Executable files released by Microsoft every time in the security bulletin.

Lets focalize the output page:

From AutoDiff webpage you may see what files has been modified (in the above picture: Windows 7 dxgkrnl.sys, in date 6 January 2011), what blocks has been updated and the whole detailed page regarding every changed function (see image below).

This post was about remembering the existence of this tool for every time I need to find out the "modified function" during any patch-to-exploit procedure.

Wednesday, January 12, 2011

The Enhanced Mitigation Experience Toolkit 2.0

Hi Folks,
today, from a Quality INN in Monterey I wanna point out the new Microsoft's Buffer Overflow mitigation tool called: EMET 2.0.

For those who may be unfamiliar with the tool, EMET provides users with the ability to deploy security mitigation technologies to arbitrary applications. This helps prevent vulnerabilities in those applications (especially line of business and 3rd party apps) from successfully being exploited. By deploying these mitigation technologies on legacy products, the tool can also help customers manage risk while they are in the process of transitioning over to modern, more secure products. In addition, it makes it easy for customers to test mitigations against any software and provide feedback on their experience to the vendor.

EMET2.0 provides:

SEHOP (Structure Exception Handler Overwrite Protection ). Without SEHOP an attacker can overwrite, with a controlled value, the handler pointer of an exception record on the stack.

DEP (Dynamic Data Execution Prevention). Without DEP an attacker can attempt to exploit a vulnerability by jumping to shellcode at a memory location where attacker controlled data resides such as the heap or stack.

HAP (Heapspray Allocation Prevention). When an exploit runs, it often cannot be sure of the address where its shellcode resides and must guess when taking control of the instruction pointer. To increase the odds of success, most exploits now use heapspray techniques to place copies of their shellcode at as many memory locations as possible. HAP prevents this hunting technique.

NPA (Null Page Allocation).This is similar technology to the heap spray allocation, but designed to prevent potential null dereference issues in user mode.

Last but not least ASLR (Address Space Layout Randomization) . Without ASLR attackers can take advantage of a predictable mapping of those dlls and could use them in order to bypass DEP though a known technique called return oriented programming (ROP).

All these "patches" against BOF attack are very good tries, but do they really stop attackers to compromise systems ? Well, the answer it's easy... nope. But at least having EMET2.0 installed and configured on your box it's a good way to block poor implemented (or not so sofisticate) BOF attacks.

Sunday, January 9, 2011

SMS of Death

Hi Folks,
this morning I wanna point out this interesting article: "SMS of Death"

Using only Short Message Service (SMS) communications—messages that can be sent between mobile phones—a pair of security researchers were able to force low-end phones to shut down abruptly and knock them off a cellular network. As well as text messages, the SMS protocol can be used to transmit small programs, called "binaries," that run on a phone.

The researchers were able to create malicious SMS messages for each type of phone they studied. The messages affect the phones without any response from the user. Because feature phones are so common, Mulliner says, such an attack "could take out a large percentage of mobile communications."

Wednesday, January 5, 2011

First day at HICSS

Finally I reached Hawaii for Hawaiian International Conference on System Sciences (HICSS) .

Today is the first conference day and what I see is a great melting pot of scientists. A good interoperability between different science cultures: from hard core security guys to social scientists through eGov guys. Again my first impression is totally positive, the organization seems to be brilliant and the location is just amazing, the idea of having tons of different scientists closed in a single hotel is the best way to raise up ideas and collaborations.

BTW, except for UC folks is there someone of you who is attending HICSS ? (Shell we meet in the conference hotel talking about security behind a good beer ?).