OpenRCE: Blog

Thanks Fravia! Rest In Peace

Mon, 04 May 2009 20:32:00 -0500

Yesterday, May 3rd, the great Fravia passed away.
He ran his lengendary fravia pages and searchlores. A lot of people in the reverse engineering world are (and will be) definitely indebted to him for his teachings. He will definitely will be missed.

Some friends notes on the sad news here, here and here

More syscall ordinals

Fri, 23 Jan 2009 18:44:00 -0600

Daniel Reynaud has improved on the script I described a while ago and has posted on his blog the system call ordinals for Windows XP SP2 x64.

pefile and LOAD_CONFIG

Fri, 23 Jan 2009 01:58:00 -0600

Following a conversation in twitter Ive noticed pefile was lacking support for parsing one data directory in the PE format that is rather interesting, the IMAGE_LOAD_CONFIG_DIRECTORY.

Ive added support for it and fixed a few small bugs and released it as pefile-1.2.10-60

Now one can access this structures fields like, for instance, pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SecurityCookie or pe.DIRECTORY_ENTRY_LOAD_CONFIG.struct.SEHandlerTable and also modify their values and write the result to a new PE file, all the usual handling & mangling that pefile allows.

Tips and tricks

Thu, 08 Jan 2009 17:39:00 -0600

A couple of interesting things Ive found out lately:

When packaging the latest pefile I noticed the dot-underscore files in the tar.gz. If one extracts the contents there are no such files to be found (if youre working on OSX) while they will show up in other operating systems. Those dot-underscore files are OSX way of storing the resource fork (metainformaion). While it might be handy to keep it around when moving files between Macs, its not nice to have such dot-underscore files show up in other systems. How to get rid of them is not too well documented.

There are two oddly named environment variables (they changed between OSX versions) that control the creation of such files. Setting the following envionment variables to true will make tar not create those dot-underscore files when archiving a file with a resource fork.

COPYFILE_DISABLE
COPY_EXTENDED_ATTRIBUTES_DISABLE

One can just set them in the python setup.py script, so when the source distribution is created, no resource forks are dumped into those files.

import os
os.environ[COPY_EXTENDED_ATTRIBUTES_DISABLE] = true
os.environ[COPYFILE_DISABLE] = true

In my case it was TextMate that was using a resource fork to store some metainformation about the Python files I was working with.

Now a useful tip for subversion. I always knew CVS and subversion had to have such feature but never was able to find how to use, I finally tracked it down.

This might not be knew to anyone that has spent some time with svn... but was to me. The things is, I was sure there had to be a comfortable way of having SVN automatically add the revision number to the source code. That would allow to have version numbers with a revision appended to them automatically, which would make lots of things much nicer, like tracking errors with specific versions.

To achieve that, one can use subversion keywords. SVN will replace those keywords with the appropriate information. In this case the cool one is "$LastChangedRevision$", whereever we write it, it will get replaced by "$LastChangedRevision: XXX $" where XXX is the revision number.

You need to tell subversion you want it to replace that keyword in a given file(s). To do that just issue a: svn propset svn:keywords "Rev" path/to/the/file to set the property on that file.

A practical example for Python code would be:

__revision__ = "$LastChangedRevision$"
__version__ = %d % int( __revision__[21:-2] )

The keyword would be replaced as described above and then we can fetch the revision number and add it to the version number transparently. Subversion will handle it cleanly.

Thoughts on "Using dual-mappings to evade automated unpackers"

Tue, 21 Oct 2008 15:29:00 -0500

Uninformed 10 was released recently. On it Skape brings about a simple, yet beautiful and powerful idea. The paper itself is short and concise but a quick summary would be along the lines of: some generic unpackers use, either as their main technique or as an heuristic, the tracking of memory writes and whenever the execution flow hits those written areas an assumption is made that unpacked (or self-modifying code) has been reached. This is an over-simplification because of multi-staged unpackers and other details, but will suffice for the sake of the discussion. Skape basically introduces a technique by which hes able to write into a range of virtual addresses an execute from another range, both pointing to the same real data.

This is a well supported technique and nothing strange of itself. It is its use what is creative and rather amusing as it breaks the assumption mentioned earlier. Given that no writes are seen in the area of memory that will be executed. The technique relies on the possibility of having several virtual addresses refer the same physical memory. The Memory Management Unit (MMU) allows pages of virtual memory to map to common physical locations in order to avoid, for instance, the need of having multiple copies of shared components between different processes.

Some of the tools having trouble with this trick cant really do much about it but other tools he mentions in the paper should have no issue handling it in some way or another.

Ive been working with Bochs for a few years. The technique should be (and is) easily defeatable by tools providing a birds eye perspective like Bochs or by tools running in kernel mode.

Analyzing the generally one-to-one mapping of virtual-to-physical memory to find a one-to-many relationship is not all that difficult, and the case where a set of virtually mapped pages receive writes and not much more and another set pointing to the same physical ranges is only (or mostly just) executed should be easy to determine. Thatd be a simple heuristic but attempting to defeat it by writing to the execute-only mapping would break down the whole idea...

Its definitely a beatiful idea but its easy to detect if youre on the right spot.

One can take a quick look at it if you have Windbg lying around. Just connect to your test machine running a test process that implements the code that Skape outlines.

Do a quick process listing to find it by issuing:

!process 0 0

Then, take a look at the Cid of the process of interest and get its details with:

!process <Cid>

In that listing the page directory base DirBase will be given. With that we can tell Windbg to do the mapping of a virtual address using the virtual-to-physical mapping of that process by pasing the directory base to the !vtop command. In my case the DirBase of my process was f5a and Ill instruct Windbg to give me the corresponding physical address to which the virtual addresses 0x419000 and 0x519000 are mapped (those addresses are specific to the example code I wrote implementing skapes idea)

lkd> !vtop f5a 0x419000
Pdi 1 Pti 19
00419000 14a79000 pfn(14a79)
lkd> !vtop f5a 0x519000
Pdi 1 Pti 119
00519000 14a79000 pfn(14a79)

As you can see both lead to the same physical location 14a79000. So its easy to see this from kernel mode by walking the page directory of a process under surveillance.

If you want to see all physical-virtual mappings the following command provides that:

!ptov f5a

Ive also implemented detection of this trick in some Python scripts Ive developed for my Python-weaponized Bochs environment. On that front. I have an up-to-date patch for Bochs (improved from what I introduced at HitB in Dubai). While I hope to be able to eventually work with the Bochs developers to merge it anyone that wants to give it a shot it welcome to shoot me an email...

Ill be talking on packers and their techniques on the forthcoming Hack in the Box in Kuala Lumpur. Ill be there next week and later in November at Power Of Community in Korea.