From Collaborative RCE Tool Library

Jump to: navigation, search

Non-Intrusive Debuggers

Tool name: Frida
Rating: 0.0 (0 votes)
Author: Ole André Vadla Ravnås (@fridadotre)                        
Current version: 9.1.19
Last updated: March 22, 2017
Direct D/L link: N/A
License type: Open Source
Description: Inject JavaScript to explore native apps on Windows, macOS, Linux, iOS, Android, and QNX.

It’s Greasemonkey for native apps, or, put in more technical terms, it’s a dynamic code instrumentation toolkit. It lets you inject snippets of JavaScript or your own library into native apps on Windows, macOS, Linux, iOS, Android, and QNX. Frida also provides you with some simple tools built on top of the Frida API. These can be used as-is, tweaked to your needs, or serve as examples of how to use the API.


Your own scripts get injected into black box processes to execute custom debugging logic. Hook any function, spy on crypto APIs or trace private application code, no source code needed!


Stealthy code tracing without relying on software or hardware breakpoints. Think DTrace in user-space, based on dynamic recompilation, like DynamoRIO and PIN.


Works on Windows, macOS, Linux, iOS, Android, and QNX. Install the Node.js bindings from npm, grab a Python package from PyPI, or use Frida through its Swift bindings, .NET bindings, Qt/Qml bindings, or C API.

Why do I need this?

Great question. We’ll try to clarify with some use-cases:

* There’s this new hot app everybody’s so excited about, but it’s only available for iOS and you’d love to interop with it. You realize it’s relying on encrypted network protocols and tools like Wireshark just won’t cut it. You pick up Frida and use it for API tracing.

* You’re building a desktop app which has been deployed at a customer’s site. There’s a problem but the built-in logging code just isn’t enough. You need to send your customer a custom build with lots of expensive logging code. Then you realize you could just use Frida and build an application- specific tool that will add all the diagnostics you need, and in just a few lines of Python. No need to send the customer a new custom build - you just send the tool which will work on many versions of your app.

* You’d like to build a Wireshark on steroids with support for sniffing encrypted protocols. It could even manipulate function calls to fake network conditions that would otherwise require you to set up a test lab.

* Your in-house app could use some black-box tests without polluting your production code with logic only required for exotic testing.
Also listed in: API Monitoring Tools, Android Tools, Code Injection Tools, IPhone Tools, Memory Data Tracing Tools, Network Monitoring Tools, Programming Libraries, Reverse Engineering Frameworks, Ring 3 Debuggers, Tracers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)

Tool name: oStudio - Live Tuning
Rating: 0.0 (0 votes)
Author: Objectis                        
Current version: 1.3
Last updated: January 17, 2014
Direct D/L link:
License type: Free
Description: Accelerates the integration, testing and development phase by a factor of 2 to 10, in one easy-to-use application.
oStudio - Live Tuning brings a new development and real time debugging method. It's easy to connect embedded systems, automation and .NET applications to oStudio - Live Tuning, and to interact with them LIVE!

Traditional step by step debugging techniques are now history. A system doesn’t need to be halted to verify and validate its behavior anymore! This method, called live debugging, consists of observing and interacting with a real-time system while it’s still running. oStudio – Live Tuning is a new generation of debugger. It regroups new debugging tools for embedded systems and the machine industry with automated testing.
Also listed in: .NET Debuggers, .NET Tools, .NET Tracers, API Monitoring Tools, COM Debugging Tools, COM Monitoring Tools, Debug Output Monitoring Tools, Debuggers, FPGA Tools, Microcontroller Tools, Visual Basic Debuggers, Visual Basic Tools
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                        
Current version:
Last updated: January 16, 2010
Direct D/L link:
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: Ring 3 Debuggers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)

Tool name: OepFinder
Rating: 3.0 (1 vote)
Author: deroko of ARTeam                        
Current version: X.Y.Z
Last updated: March 10, 2006
Direct D/L link: Locally archived copy
License type: Free
Description: Generic Oep finder, uses PAGE_GUARD to locate good range. Supports debugging using win32 debug subsystem, and nonintrusive traceing.
Also listed in: OEP Finders
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                        
Current version:
Last updated:
Direct D/L link:
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: Ring 3 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.

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