Collaborative RCE Tool Library - Debugger Libraries (including sub-categories)

Tool Updated: PaiMei

Sun, 28 Jun 2009 13:33:19 GMT

Listed in categories: Debugger Libraries, Reverse Engineering Frameworks

Most recent version:
1.1-REV122

Most recent release date:
May 22, 2007

Description:
PaiMei, is a reverse engineering framework consisting of multiple extensible components. The framework can essentially be thought of as a reverse engineer's swiss army knife and has already been proven effective for a wide range of both static and dynamic tasks such as fuzzer assistance, code coverage tracking, data flow tracking and more. The framework breaks down into the following core components:

* PyDbg: A pure Python win32 debugging abstraction class.
* pGRAPH: A graph abstraction layer with seperate classes for nodes, edges and clusters.
* PIDA: Built on top of pGRAPH, PIDA aims to provide an abstract and persistent interface over binaries (DLLs and EXEs) with separate classes for representing functions, basic blocks and instructions. The end result is the creation of a portable file that when loaded allows you to arbitrarily navigate throughout the entire original binary.

A layer above the core components you will find the remainder of the PaiMei framework broken into the following over-arching components:

* Utilities: A set of utilities for accomplishing various repetitive tasks.
* Console: A pluggable WxPython GUI for quickly and efficiently rolling out your own sexy RE utilities.
* Scripts: Individual scripts for accomplishing various tasks. One very important example of which is the pida_dump.py IDA Python script which is run from IDA to generate .PIDA modules.

The documentation for the framework is available online at: http://pedram.openrce.org/PaiMei/docs

A very informative discussion thread about PaiMei, including a bunch of tutorials on how to use the different aspects of it, can be found at:
http://www.woodmann.com/forum/showthread.php?t=10851

Tool Added: Ragweed

Sun, 28 Jun 2009 13:32:39 GMT

Listed in categories: Debugger Libraries

Most recent version:

Most recent release date:

Description:
Ragweed is available as a gem through github:

sudo gem install tduehr-ragweed

Why a scriptable debugger?

When reversing, the usual debugging tools for developers aren’t as useful. They’re built for stepping interactively through programs you have source code for. They don’t generally have methods to get data out.

Reversing also requires being able to do mean and nasty things to the running process. When tracing calls, you want to watch how they interact. The last thing you want to do is anything manual. Automation is a requirement.

Also helpful is the ability to automate information gathering tasks, or the ability to dynamically add, remove or change breakpoints. These features are why scriptable debuggers have been created: To play with black boxes in a more dynamic and seedier manner.

What’s available already?

There are already scriptable debuggers out there. The most notable are PaiMei/PyDbg, Immunity Debugger and IDA.

PaiMei is written in Python, bills itself as “a reverse engineer’s swiss army knife” and uses the Python ctypes library for low level win32 calls.

Immunity Debugger is a GUI debuggger for win32 that uses Python for its scripting functionality.

IDA Pro is largely a win32 disassembler, but it is scriptable, again in Python, and includes a debugging module.

Before I get run off by a screaming mob with pitchforks, flightless birds, members of the family bovidae, etc., I will also mention GDB which has a library in development (libgdb) and can be scripted through macros.

With the exception of GDB which runs on most platforms and has its own macro language, these all share two common problems: Win32 and Python. Matasano is a Ruby shop. We like Ruby. It is good to us. We also wanted a tool for non-Win32 applications. But mostly, we just wanted something in Ruby.

Enter Ragweed

I’m going to stick to the OSX side of Ragweed for this article since I’m most familiar with it and there is still work to be done to unify the (currently) three debugging APIs —- Win32, Linux, and OSX —- inside Ragweed.

Under the hood, Ragweed (on OSX) uses Ruby/DL to perform the various low level system calls necessary to create a debugger. (More about that in my post from last year). These calls are abstracted somewhat to provide a smoother, more Ruby-like interface.

There are two caveats for Ragweed in OSX:

* Due to the changes in Ruby 1.9 to DL, it is currently incompatible with 1.9.
* Also, under OSX, Ragweed wants to run as root due to restrictions on
Code:

task_for_pid

.

A quick example (this we can do in IRB):

# debugging ftp using default signal handlers, printing registers every stop and logging calls to _lpwd

require ‘ragweed’
class DebugFtp < Debuggerosx

# print the registers every time the process stops

def on_stop(signal)

puts "Stopped with signal #{signal}"

self.threads.each {''

Tool Updated: WinAppDbg (Python module)

Tue, 16 Jun 2009 18:21:25 GMT

Listed in categories: Debugger Libraries

Most recent version:
1.2

Most recent release date:
Jun 16, 2009

Description:
The WinAppDbg python module allows developers to quickly code instrumentation scripts in Python under a Windows environment.

It uses ctypes to wrap many Win32 API calls related to debugging, and provides an object-oriented abstraction layer to manipulate threads, libraries and processes, attach your script as a debugger, trace execution, hook API calls, handle events in your debugee and set breakpoints of different kinds (code, hardware and memory). Additionally it has no native code at all, making it easier to maintain or modify than other debuggers on Windows.

The intended audience are QA engineers and software security auditors wishing to test / fuzz Windows applications with quickly coded Python scripts. Several ready to use utilities are shipped and can be used for this purposes.

Current features also include disassembling x86 native code (using the open source diStorm project, see http://ragestorm.net/distorm/), debugging multiple processes simultaneously and produce a detailed log of application crashes, useful for fuzzing and automated testing.