OpenRCE: Blog

More on pynary

Tue, 15 Jan 2008 01:17:20 -0600

Hey all,

I've unfortunately not made too much progress on pynary due to a horrific machine crash (but you *really* don't want to hear about that!).

I submitted pynary to the new Woodman Collaborative Tool Library in the hope that I can reel in a few more volunteers.

I've also noticed that a number of people here at OpenRCE are working on similar stuff. I really think it'd be a good idea to try and combine our efforts. That way we can really get the most 'bang' for our buck ;)

That's all for now. Look forward to some real updates to pynary in the next couple of weeks!

Introducing pynary

Tue, 11 Dec 2007 12:42:58 -0600

Hey all,

I've posted some very very early code for pynary at http://openrce-snippets.googlecode.com/svn/trunk/standalone/pynary/.

For those of you who haven't been subjected to my speculation and badgering on the irc channel, I'll describe what this is and what it could, hopefully, become.

It all started when I decided that IDA's flirt wasn't doing a good enough job of matching standard library functions - missing many 'trivial to match' functions, incorrectly matching others, ignoring certain functions entirely, forcing the user to pick between 'clashing' function signatures, etc.

I started thinking about the particular issues related to the problem of matching library functions and how each of FLIRT's limitations could be overcome, and eventually decided that what the RCE community needs is a flexible and extensible binary function matching library.

So I started working on a script - in python of course - and it quickly became clear that I could do so much more with the infrastructure I was laying down. I decided to expand my horions a bit, and renamed the project ('gensig') to pynary.

pynary will hopefully become a powerful framework for binary code analysis.

The initial goal is to finish implementation of the signature matching goal using graph isomorphism and an extensible 'write-your-own-heuristic' model to tweak matching for particular targets. I also intend to identify standard library global constants and structure where possible.

Once the initial goal is acheived, I look forward to implementing a number of cool features:
* stack frame analysis
* un-inliner
* exception handling parsing/analysis
* 'functionally equivalent' matching
* c++ template function matching
* meta-data transfer between IDBs
* c++ class reconstruction (with/without RTTI)
* ...

At the moment, the bulk of the work has been to add COFF object support to ero's pefile. This functionality is not yet merged into the mainstream release of pefile, but will hopefully make it in when stable enough.

So far, the pynary.py file opens a .LIB file, enumerates its exported functions and generates a basic-block graph for each function using recursive traversal. These graphs in turn form a 'graph of graphs' of inter-function calls.

Calls to externally defined functions are not resolved, but in the next stage, when multiple .LIBs are loaded, externs will be resolved (sort of reverse-linking).

This graph can be traversed by matching algorithms.

Anyhow, feel free to contact me (email, irc, xmpp) with ideas and comments. Anyone who want's to get their hands dirty is more than welcome.

Kerberos API Tracing

Mon, 14 May 2007 12:28:20 -0500

Hi all,

I'm looking into API tracing, and heard about kerberos (Rustem Fasihov) in this thread: https://www.openrce.org/forums/posts/274.

As I've been grappling with my own hooking engine for a couple of days, I couldn't resist looking under the hood.

I discovered that at it's core, kerberos seems to use 5-byte hotpatch hooks, which isn't surprising, as it's the mechanism I was using and also - to some degree - that favored by Detours.

What is interesting is that there don't seem to be any 'trampoline' functions. In other words, in both my solution and Detours, it is necessary to generate a 'jump function' (which acts as the target of the 5-byte JMP patch) for each API being hooked. The 'jump'/'trampoline' function typically has the address of the instruction immediately following the patch hard-coded into a JMP so that execution can continue.

It seems that kerberos takes a different approach though, all patches, for all hooked functions, jump to the same method, which begins:



    pushf

spin:

    cmp    g_inHookSemaphore, 1

    jz     spin

    mov    g_inHookSemaphore, 1

    popf

    pop    data1

    pop    data2

    pushf

    pusha

    ...