From Collaborative RCE Tool Library
Debugger Libraries
| Tool name: | WinAppDbg (Python module) |
| ||
|---|---|---|---|---|
| Author: | Mario Vilas | |||
| Website: | http://winappdbg.sourceforge.net | |||
| Current version: | 1.4 | |||
| Last updated: | August 24, 2010 | |||
| Direct D/L link: | http://sourceforge.net/projects/winappdbg/files/WinAppDbg/1.4/ | |||
| License type: | Free / Open Source (BSD) | |||
| 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. | |||
| Also listed in: | Debuggers, Ring 3 Debuggers | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
| Tool name: | DynamoRIO |
| ||
|---|---|---|---|---|
| Author: | Hewlett-Packard Laboratories & MIT & Derek Bruening | |||
| Website: | http://dynamorio.org | |||
| Current version: | 1.50.0.1 | |||
| Last updated: | December 29, 2009 | |||
| Direct D/L link: | http://dynamorio.googlecode.com/files/DynamoRIO-Windows-1.5.0-1.zip | |||
| License type: | Free | |||
| Description: | DynamoRIO is a runtime code manipulation system that supports code transformations on any part of a program, while it executes. DynamoRIO exports an interface for building dynamic tools for a wide variety of uses: program analysis and understanding, profiling, instrumentation, optimization, translation, etc. Unlike many dynamic tool systems, DynamoRIO is not limited to insertion of callouts/trampolines and allows arbitrary modifications to application instructions via a powerful IA-32/AMD64 instruction manipulation library. DynamoRIO provides efficient, transparent, and comprehensive manipulation of unmodified applications running on stock operating systems (Windows or Linux) and commodity IA-32 and AMD64 hardware. Previous description: The DynamoRIO Collaboration - Dynamo from Hewlett-Packard Laboratories + RIO (Runtime Introspection and Optimization) from MIT's Laboratory for Computer Science. The DynamoRIO dynamic code modification system, joint work between Hewlett-Packard and MIT, is being released as a binary package with an interface for both dynamic instrumentation and optimization. The system is based on Dynamo from Hewlett-Packard Laboratories. It operates on unmodified native binaries and requires no special hardware or operating system support. It is implemented for both IA-32 Windows and Linux, and is capable of running large desktop applications. The system's release was announced at a PLDI tutorial on June 16, 2002, titled "On the Run - Building Dynamic Program Modifiers for Optimization, Introspection and Security." Here is the tutorial abstract: In the new world of software, which heavily utilizes dynamic class loading, DLLs and interconnected components, the power and reach of static analysis is diminishing. An exciting new paradigm of dynamic program optimization, improving the performance of a program while it is being executed, is emerging. In this tutorial, we will describe intricacies of building a dynamic optimizer, explore novel application areas such as program introspection and security, and provide details of building your own dynamic code modifier using DynamoRIO. DynamoRIO, a joint development between HP Labs and MIT, is a powerful dynamic code modification infrastructure capable of running existing binaries such as Microsoft Office Suite. It runs on both Windows and Linux environments. We are offering a free release of DynamoRIO for non-commercial use. A copy of the DynamoRIO release, which includes the binary and a powerful API, will be provided to the attendees. | |||
| Also listed in: | Code Coverage Tools, Code Injection Tools, Disassembler Libraries, Profiler Tools | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
| Tool name: | PaiMei |
| ||
|---|---|---|---|---|
| Author: | Pedram Amini | |||
| Website: | http://paimei.googlecode.com | |||
| Current version: | 1.1-REV122 | |||
| Last updated: | May 22, 2007 | |||
| Direct D/L link: | Locally archived copy | |||
| License type: | Free / Open Source | |||
| 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 | |||
| Also listed in: | Reverse Engineering Frameworks | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
| Tool name: | Ragweed |
| ||
|---|---|---|---|---|
| Author: | Matasano Security | |||
| Website: | http://www.matasano.com/log/1799/ruby-for-pentesters-the-dark-side-i-ragweed/ | |||
| Current version: | ||||
| Last updated: | ||||
| Direct D/L link: | N/A | |||
| License type: | Free / Open Source | |||
| 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 {|t| self.get_registers(t).dump} end end # no process lookup by name yet d = DebugFtp.new(pid) # where pid is the id of ftp for this example # set breakpoint for lpwd d.breakpoint_set(0x420f,‘lpwd’, (bpl = lambda do | t, r, s | puts "#{ s.breakpoints[r.eip].first.function } hit in thread #{ t }\n"; end)) d.install_breakpoints d.continue d.loop #loop until child exits # now go do stuff in in your other terminal window running ftp That’s it. We just override the signal handlers for the signals we want to know about (or not), attach to a running process, set and install breakpoints, and it’s off to the traces. A simple hit tracer is only a CSV file and read loop away from this. Want info on a region of memory? d.region_info(0x0,:basic).dump What about: thread_info ? d.threadinfo(threadid).dump Break stuff by playing with registers? regs = d.get_registers(thread_id) regs.eip = 0x420f d.set_registers(thread_id, regs) Grope through the child’s memory? Ragweed::Wraposx::vm_read(d.task, address, size) #returns a string of child's memory There you have it. It’s not pretty but it’s only begun. | |||
| Also listed in: | (Not listed in any other category) | |||
| More details: | Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry) | |||
Feed containing all updates and additions for this category.
Feed containing all updates and additions for this category, including sub-categories.
