From Collaborative RCE Tool Library

Jump to: navigation, search

Ring 3 Debuggers


Tool name: IDA Pro
Rating: 5.0 (6 votes)
Author: Ilfak Guilfanov                        
Website: http://www.hex-rays.com/idapro
Current version: 6.1
Last updated: April 8, 2011
Direct D/L link: http://95.211.133.202/files/idademo_windows60.exe
License type: Commercial
Description: The IDA Pro Disassembler and Debugger is an interactive, programmable, extendible, multi-processor disassembler hosted on Windows or on Linux. IDA Pro has become the de-facto standard for the analysis of hostile code, vulnerability research and COTS validation.

There is also a free (crippled) version available (IDA Pro Free). See its own entry in the library for more info.

As of January 7, 2007, the official IDA Pro website moved from the old URL (http://www.datarescue.com/idabase) to the one listed above.
Also listed in: .NET Disassemblers, Disassemblers, IPhone Tools, Linux Debuggers, Linux Disassemblers, Mobile Platform Debuggers, Mobile Platform Disassemblers, Symbian Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: OllyDbg
Rating: 5.0 (4 votes)
Author: Oleh Yuschuk                        
Website: http://www.ollydbg.de
Current version: 1.10 (and 2.01)
Last updated: September 27, 2013
Direct D/L link: http://www.ollydbg.de/odbg110.zip
License type: Free (disassembler under GPL v3)
Description: The world's most famous ring 3 debugger.

The first public (pre-alpha) version of OllyDbg 2.0 was released on December 25, 2007, so you can now test it yourself if you want!
OllyDbg v2 : http://www.ollydbg.de/version2.html
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)



Tool name: radare
Rating: 5.0 (2 votes)
Author: pancake                        
Website: http://www.radare.org
Current version: 0.9.7
Last updated: March 3, 2014
Direct D/L link: http://www.radare.org/get/radare2-0.9.7.tar.xz
License type: LGPL
Description: The radare project aims to provide a complete unix-like toolchain for working with binary files. It currently provides a set of tools to work with 6502, 8051, arc, arm64, avr, brainfuck, whitespace, malbolge, cr16, dcpu16, ebc, gameboy, h8300, tms320, nios2, x86, x86_64, mips, arm, snes, sparc, csr, m68k, powerpc, dalvik and java.

The main program is 'r2' a commandline hexadecimal editor with support for debugging, disassembling, analyzing structures, searching data, analyzing code and support for scripting with bindings for Python, NodeJS, Perl, Ruby, Go, PHP, Vala, Java, Lua, OCaml.

Radare comes with the unix phylosophy in mind. Each module, plugin, tool performs a specific task and each command can be piped to another to extend its functionality. Also, it treats everything as a file: processes, sockets, files, debugger sessions, libraries, etc.. Everything is mapped on a virtual address space that can be configured to map multiple files on it and segment it.

If you are interested or feel attracted by the project join us in the #radare channel at irc.freenode.net.

See website for more details.
Also listed in: .NET Disassemblers, Assemblers, Binary Diff Tools, Code Injection Tools, Debuggers, Disassemblers, Hex Editors, Java Disassembler Libraries, Linux Debuggers, Linux Disassemblers, Linux Tools, Memory Dumpers, Memory Patchers, Process Dumpers, Reverse Engineering Frameworks, String Finders, Symbol Retrievers, SysCall Monitoring Tools, Tracers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: EDB Linux Debugger
Rating: 4.0 (2 votes)
Author: Evan Teran                        
Website: http://codef00.com/projects#debugger
Current version: 0.9.20
Last updated: January 15, 2014
Direct D/L link: http://codef00.com/projects/debugger-0.9.20.tgz
License type: GPL
Description: Features
* Intuitive GUI interface
* The usual debugging operations (step-into/step-over/run/break)
* Conditional breakpoints
* Debugging core is implemented as a plugin so people can have drop in replacements. Of course if a given platform has several debugging APIs available, then you may have a plugin that implements any of them.
* Basic instruction analysis
* View/Dump memory regions
* Effective address inspection
* The data dump view is tabbed, allowing you to have several views of memory open at the same time and quickly switch between them.
* Importing of symbol maps
* Plugins
o Search for binary strings
o Code Bookmarks
o Breakpoint management
o Check for updates
o Environment variable viewer
o Heap block enumeration
o Opcode search engine plugin has basic functionality (similar to msfelfscan/msfpescan)
o Open file enumeration
o Reference finder
o String searching (like strings command in *nix)

One of the main goals of this debugger is isolation of the debugger core from the display you see. The interface is written in QT4 and thus source portable to many platforms. The debugger core is actually a plugin and the platform specific code is isolated to just a few files, porting to a new OS would require porting these few files and implementing a plugin which implements the "DebuggerCoreInterface" interface. Also, because the plugins are based on the QPlugin API, and do their work through the DebuggerCoreInterface object, they are almost always portable with just a simple recompile. So far, the only plugin I have written which would not port with just a recompile is the heap analysis plugin, due to it's highly system specific nature.
Also listed in: Debuggers, Linux Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: WinAppDbg (Python module)
Rating: 4.0 (1 vote)
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: Debugger Libraries, Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: WinDbg
  • Currently3.6666666666667/5
  • 1
  • 2
  • 3
  • 4
  • 5
Rating: 3.7 (3 votes)
Author: Microsoft                        
Website: http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
Current version: 6.2.9200.16384
Last updated: December 28, 2012
Direct D/L link: N/A
License type: Free
Description: Note: version 6.2 came with Windows 8 and is actually newer than the latest version 6.12.0002.633 for Windows 7.

Microsoft's own ring 0 debugger. Quite unfriendly to use, but one of the remaining stable options since the discontinuation of SoftICE.

You will find some extensions that make it at least somewhat easier to use, in the WinDbg extensions category.
Also listed in: Ring 0 Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: IDA Pro Free
Rating: 3.5 (4 votes)
Author: DataRescue                        
Website: https://www.hex-rays.com/products/ida/support/download_freeware.shtml
Current version: 5.0
Last updated: November 2, 2007
Direct D/L link: http://out7.hex-rays.com/files/idafree50.exe
License type: Free
Description: This is the (crippled) freeware edition of the IDA Pro debugger (see its own entry in the library for more info).

Differences from the commercial version is, among others:

* No remote debugging
* No Linux debugging (disassembling only)
* No other OS support at all (Mac OSX, WinCE)
* Only PE, COFF, OMF, ELF and Dos is supported (not NE)
* No console version (idaw.exe)
* Only x86 family processor module included (metapc)
* No x64 support at all
* Some FLIRT signatures are out-dated
* Fewer included plugins
* Difficulty identifying parameters in some cases (no PIT)
* Buggy WINE support
* Incompatible with plugins for commercial versions (plugins can be patched with another tool available in this library to work with the free version though!)
Also listed in: Disassemblers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Immunity Debugger
Rating: 3.0 (1 vote)
Author: Immunity Inc / Oleh Yuschuk                        
Website: http://debugger.immunityinc.com
Current version: 1.6
Last updated: March 27, 2008
Direct D/L link: N/A
License type: Free
Description: Immunity Debugger is based on OllyDbg.

Immunity Debugger is a powerful new way to write exploits, analyze malware, and reverse engineer binary files. It builds on a solid user interface with function graphing, the industry's first heap analysis tool built specifically for heap creation, and a large and well supported Python API for easy extensibility.

* A debugger with functionality designed specifically for the security industry
* Cuts exploit development time by 50%
* Simple, understandable interfaces
* Robust and powerful scripting language for automating intelligent debugging
* Lightweight and fast debugging to prevent corruption during complex analysis
* Connectivity to fuzzers and exploit development tools
Also listed in: OllyDbg Custom Versions
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: W32DASM
Rating: 2.0 (2 votes)
Author: URsoftware                        
Website: N/A
Current version: 8.94
Last updated: March 11, 2003
Direct D/L link: Locally archived copy
License type: Commercial (abandonware)
Description: Before IDA Pro, W32DASM was the king of Windows 32 bit executable disassemblers.

It also has a ring 3 debugger built-in.
Also listed in: Disassemblers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Jeremy Gordon's Go Tools for Win32 and Win64
Rating: 0.0 (0 votes)
Author: Jeremy Gordon                        
Website: http://www.godevtool.com/
Current version:
Last updated:
Direct D/L link: http://www.godevtool.com/
License type: free
Description: This collection of free tools contains:

* A free assembler (GoAsm.exe), which produces COFF object files ready to be given to a linker to create the final executable. The author's aim has been to make an assembler with clean and obvious syntax, which is very quick, and which always tries to produce the smallest code. GoAsm also has some useful extensions to make programming for Windows easier. It has enhanced support for making Unicode programs and can produce programs for both Win32 and Win64(x64) platforms.

* A free resource compiler (GoRC.exe), which produces RES files from RC files, or OBJ files from RC or RES files, together with documentation.

* A free linker (GoLink.exe), which takes COFF object files and a Res file and creates EXE or DLL executables able to run under Windows Win32 or Win64(x64). This is a full featured but "reduced baggage" linker which keeps files to a minimum. You do not need Lib files to identify what functions reside in the DLLs. Instead GoLink looks inside the DLLs themselves. Used with GoAsm, this linker can report on redundant data and code in your programs. It also allows use of Unicode filenames and labels (exports and imports).

* "GoBug" - A free Win32 symbolic debugger for assembler programmers, together with "Testbug", its accompanying test program and Win32+assembler demo program. It is itself written entirely in assembler, using GoAsm and GoLink.
Also listed in: Assemblers, Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Obsidian
Rating: 0.0 (0 votes)
Author: deneke                        
Website: http://www.deneke.biz/obsidian
Current version:
Last updated: January 16, 2010
Direct D/L link: http://www.deneke.biz/obsidian/Obsidian_source.zip
License type: Free / Open Source
Description: Obsidian is a non-intrusive debugger, which means that it doesn't change the targets process as a normal debugger would. Being in beta state there can be some minor issues but it should be mostly stable.

The main advantage would be that you don't have to care anymore about those anti-debugger-tricks like:

* IsDebuggerPresent() which boils down to checking the debugger-flag in the PEB
* self-debugging: creating another thread or process which attaches itself to the target in order to keep other debuggers from doing so and probably doing some code 'corrections' during runtime.
* timing checks to recognize delays due to an attached debugger.


* Windows API

The debugging functions are implemented by using standard Win32-API calls like:

* CreateProcess
* SuspendThread / ResumeThread
* ReadProcessMemory / WriteProcessMemory
* GetThreadContext / SetThreadContext


* Breakpoints

To implement breakpoints I used a trick I learned from a very interesting paper in Codebreakers Journal. Its name is "Guide on How to Play with Processes Memory, Write Loaders and Oraculumns" and was written by Shub Nigurrath. Shub Nigurrath references the trick itself to yates and his paper "Creating Loaders & Dumpers - Crackers Guide to Program Flow Control", so kudos to him too. The trick is to place the opcode EB FE at the address you want to stop. This code stands for "jmp -2" which is the shortest way to code a while(1); loop I know of.


* Dis-/Assembling

To dis-/assemble the opcodes, I used the awesome code of the disasm zip-file Oleh Yuschuk, creator of OllyDbg, has put on his site. OllyDbg has rightfully gained a reputation for being intuitive and a real alternative to SoftICE when it comes to ring 3 applications.


* File-information

To extract some information about code and data segments and other stuff about the process I used the information gained from the paper "Portable Executable File Format – A Reverse Engineer View" written by Goppit. This paper can also be found at Codebreakers Journal.


* Singlestep and stepping into calls

Since I couldn't use debug-events, I chose the simple way out and "just" set a breakpoint on the instruction which would be executed next. This involved checking for jumps, calls and returns to make sure to get the right instruction. Checking for conditional jumps was easy since the disasm files (mentioned above) could already do this for me with the Checkcondition function. The same applies for calls. With the exception of calls that got their destination from a register. After searching for a while I found that the lower nibble of the call-opcode gave away the register that should be used. Last time I wrote about StackWalk-function and I have to admit that I was wrong about using it for returns since intel-documentation states that ret in any case uses the first element form the stack. So there's nothing to be done except reading the DWORD pointed to by the ESP.


* Thread Local Storage (TLS)

The first piece of code that will be executed when a new process is started isn't at the address pointed to by AddressOfEntryPoint. Actually DataDirectory[IMAGE_DIRECTORY_ENTRY_TLS] in the optional header points to a IMAGE_TLS_DIRECTORY32 structure which contains a pointer to a list of functions executed before going to the AddressOfEntryPoint.


* Process dumping

When I started writing the code, I was wondering why there didn't seem to be any tutorial about dumping a running process with your own program. Most tutorials I found used existing tools for it. There are some really good papers about rebuilding the IAT by the way. Which I will keep in mind for one of the next releases. As I began to reread the PE documentation it occurred to me that this is about all you need to dump an unprotected process. You can get the headers directly from the imagebase of the module and from them you can gather all the other parts. So the job is reassembling the parts scattered through process space by the loader and writing them into a file. Just keep boundaries and offsets in mind.


* Symbols

Working with symbols is much easier than I first thought. Most work is done by the Sym*-functions provided by the imagehlp library (for example use SymGetSymFromAddr to get a symbols name by its address). So the only part which requires a bit of work, is to determine the levels of indirection so calls via a jumptable could be resolved correctly. The same goes for applying the IDA map file. Once it is parsed, it's back to analysing references again. By the way, IDA is a very impressive disassembler by Ilfak Guilfanov (DataRescue). It provides a deeper analysis and another view to an executable than most debuggers do. Plus, as the name implies, you don't need to actually execute the target, which is pretty cool, especially for malware analysis.


* Basic block analysis

After the construction of the (more or less) needed basics I decided to take a shot at improving the code analysis. A short research yielded the magical words 'basic block', which is a term that originated from optimization concepts of compilers. But perhaps it's better to first explain what basic blocks are. A basic block is, generally spoken, a sequence of commands that doesn't contain any jumps and isn't jumped into. Where jump doesn't mean the jmp instruction but generally everything that explicitly moves the eip anywhere. The commands I used the determine the end of a basic block are:

* all jumps, conditional and unconditional (e.g. jmp, je...)
* call
* ret

How are blocks and addresses handled? The Analyser contains two lists, where one holds all addresses not analysed yet and the other contains the generated blocks. By doing this there is a clean separation between unknown and known blocks. To avoid an infinite loop e.g. when dealing with backward jumps the analyser only processes addresses that do not lie on the beginning of an already processed code-block. Also no processing of addresses out of the modules scope will be performed. This is done to keep the processing-time at an acceptable level. The analysis of the code starts at the entrypoint and moves onward from there on. Calls and conditional jumps both yield at best two addresses where the analysis of a new block could be started. The 'at best' results from the fact that at the time of analysis indirect addressing with register can't be resolved, so this is a path that can't analysed. When an address points into a known block this means that the block needs to be split, since an address can only come from a jump to this location which means the former block ends there and a new one begins. At the moment the analyser doesn't make any assumptions about what could be meant but only cares for definate information. Thus there are blocks of code which haven't been recognized and therefore are treated as filling. This affects the readability of the disassembled code. Since any opcode not flagged as code will be disassembled in byte steps. For example an opcode like 74 53 at address 00403F52 will result in the following output:

00403F52 74 53 JE 403FA7
00403F53 53 PUSH EBX

Mind the addresses, that is what was meant by 'in byte steps'. This can be fixed by telling the analyser to process the code from the current selection onwards.


* Modular approach

After starting with a single executable, I decided to break it up into the GUI which in itself still contains a lot of intelligence and the basic obsidian class which contains all of the debugger- like functions. The main reason for this was to be able to pass the obsidian class to a plugin. But this way you can also easily use the obsidian class in other programs.


* Plugin interface

At the moment there is only a by call interface available, which means that the plugin will only be called when the user selects the plugin from the list. To write a working plugin for obsidian you need to export the following two functions from a dll.

extern "C" void EXPORT GetName(char* p, unsigned int len);
extern "C" DWORD EXPORT Go(Obsidian* p);


As the name of the first function implies its only purpose is to store the name of the plugin in the supplied buffer. The second function gets called when the user clicks on the menu entry. This is the place where your plugin can do its work. The paramer you receive is a valid class pointer which should be used by you instead of the singleton construct. To make Obsidian recognize a plugin you need to create a folder called "PlugIns" in the Obsidian-directory and put the dlls into that folder.
Also listed in: Non-Intrusive Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Poke
Rating: 0.0 (0 votes)
Author: Toolcrypt Group                        
Website: http://www.toolcrypt.org/tools/poke/index.html
Current version:
Last updated:
Direct D/L link: http://www.toolcrypt.org/tools/poke/poke.zip
License type: Free
Description: Poke is a run-time process examination tool. It reminds slightly of a debugger, but is injected into a running process and does not use the Debug API. This tool can give you some valuable help if the process you want to examine has some heavy anti-debugging features. Poke is under development and is tested and works on Win2K.
Also listed in: Non-Intrusive Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Visual DuxDebugger
Rating: 0.0 (0 votes)
Author: Douglas Schillaci                        
Website: http://www.duxcore.com
Current version: 3.6
Last updated: May 22, 2012
Direct D/L link: http://www.duxcore.com/fs_files/VisualDuxDbgSetup.zip
License type: Freeware
Description: Visual DuxDebugger is a 64-bit debugger disassembler for Windows.

Main features
Fully support 64-bit native processes
Fully support 64-bit managed processes
Full code analysis
Full memory analysis
Code edition
Memory edition
Module export formats (EXE/DLL/CSV)
Debug multiple processes
Debug multiple child processes

Minimum Requirements
O.S: W7(64) / WS2008-R2
Processor: Pentium 4 3.0 GHz

Recommended Requirements
O.S: W7(64) / WS2008-R2 or higher
Processor: Dual Core 2.5 GHz or higher
Display: 1920 x 1080 or higher
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)



Tool name: Wintruder
Rating: 0.0 (0 votes)
Author: FutureVision                        
Website: http://mitglied.lycos.de/wintruder/wintruder.zip
Current version: 1.0.0.1
Last updated: October 17, 2008
Direct D/L link: Locally archived copy
License type: Free
Description: Wintruder is an extendable debugger for Windows 9x and Windows XP.
By default, it includes debug interfaces for:
- Win32 Debug API
- Intel x86
- Microsoft VisualBasic p-code
- Virtual Dos Machine (XP only)
- Win32 Stealth (XP only)
- Intel x86
- Microsoft VisualBasic p-code
- Virtual Dos Machine
- Microsoft .Net (.Net 1.0 and up)
- .Net CIL

You can use Wintruder for free. For more information read license.txt. If this file does not exist, type wintruder.exe -l


This version of Wintruder is a development snapshot and far from being a final release.

Most important limitations:
- You may encounter several bugs and deficiencies.
- The use of debug information is limited to bare function definitions.
- The native .Net debugger is missing.
- The script engine is not really working.
- Much, much more…

By the way:
- The DiaDbg plug-in requires the Microsoft Debug Interface Access library. (msdia80.dll, msdia71.dll or msdia20.dll)
- To be more precise: None of the libraries Wintruder is bound to is included in this distribution.
Also listed in: .NET Debuggers, Visual Basic Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)


RSS feed Feed containing all updates and additions for this category.

RSS feed Feed containing all updates and additions for this category, including sub-categories.





Views
Category Navigation Tree
   Code Coverage Tools  (13)
   Code Ripping Tools  (2)
   .NET Debuggers  (4)
   Debugger Libraries  (5)
   Ring 0 Debuggers  (8)
   Ring 3 Debuggers  (14)
   Symbol Retrievers  (4)
   VM Debugging Tools  (1)
   Helper Tools  (3)
   Hex Editors  (13)
   Memory Patchers  (7)
   Packers  (19)
   Profiler Tools  (11)
   String Finders  (10)
   Tool Hiding Tools  (7)
   Tracers  (20)
   Needs New Category  (3)