From Collaborative RCE Tool Library

Jump to: navigation, search

Categorized by Tool Type


Tool name: AQtime
Rating: 5.0 (1 vote)
Author: AutomatedQA, Corp.                        
Website: http://automatedqa.com/products/aqtime/index.asp
Current version: 5.40
Last updated: January 11, 2008
Direct D/L link: N/A
License type: Commercial (with demo)
Description: This tool does reportedly not work at all without having the source code for the analyzed program, which sadly makes it relatively useless for reversing purposes.

See the following for more info:
http://www.woodmann.com/forum/showthread.php?t=11306

-----------------------------
AQtime is AutomatedQA's award-winning performance profiling and memory and resource debugging toolset for Microsoft, Borland, Intel, Compaq and GNU compilers.

The latest version of AQtime, AQtime 5, includes dozens of productivity tools that help you easily isolate and eliminate all performance issues and memory/resource leaks within your code by generating comprehensive and detailed reports for your .NET and Windows applications. AQtime supports .NET 1.0, 1.1, 2.0, 3.0 applications and Windows 32- and 64-bit applications.

AQtime is built with one key objective - to help you completely understand how your programs perform during execution. Using its integrated set of performance and debugging profilers, AQtime collects crucial performance and memory/resource allocation information at runtime and delivers it to you both in summarized and detailed forms, with all of the tools you need to begin the optimization process. This is all done without modifying the application's source code!
Also listed in: Code Coverage Tools, Profiler Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: CodeAnalyst Performance Analyzer
Rating: 5.0 (1 vote)
Author: AMD                        
Website: http://developer.amd.com/cpu/codeanalyst/codeanalystwindows/Pages/default.aspx
Current version: 2.94
Last updated: July 18, 2009
Direct D/L link: http://developer.amd.com/Downloads/CodeAnalyst_Public_2.94.718.0439.exe
License type: Free
Description: This tool works without having any source code or debug information for the analyzed program, which makes it very good for reversing purposes.

See the following for more info:
http://www.woodmann.com/forum/showthread.php?t=11306

-----------------------------
The AMD CodeAnalyst Performance Analyzer is a suite of powerful tools that analyzes software performance on AMD microprocessors. These tools are designed to support Microsoft® Windows XP®, Windows 2003 and Vista® distribution on x86 and AMD64 architectures. Although most users will choose the Graphical User Interface, the profiler is also offered as a command line utility to facilitate the use in batch files.

* System-Wide Profiling : CodeAnalyst is designed to profile the performance of binary modules, including user mode application modules and kernel mode driver modules. Timer-Based Profiling and Event-Based Profiling collect data from multiple processors in a multi-processor system.

* Timer-Based Profiling (TBP) :
o The application to be optimized is run at full speed on the system that is running CodeAnalyst. EIP samples are collected at predetermined intervals and can be used to identify possible bottlenecks, execution penalties, or optimization opportunities.
o On APIC enabled systems, the finest time resolution is 0.1ms and 1.0ms non-APIC enabled systems.

* Event-Based Profiling (EBP) : CodeAnalyst EBP is designed to profile the hardware performance events on AMD Athlon™, AMD Athlon™ XP, AMD Opteron™, AMD Athlon™ 64 and AMD “Barcelona” (AMD Family 10h). With event multiplexing technique, CodeAnalyst EBP is able to profile more than 4 events simultaneously.

* Instruction-Based Sampling (IBS) : Instruction-based Sampling is a new performance measurement technique supported by AMD Barcelona (Family 10h) processors. IBS has these advantages:
o IBS precisely associates hardware event information with the instructions that cause the events. A data cache miss, for example, is associated with the AMD64 instruction performing the memory read or write operation that caused the miss.
o IBS collects a wide range of hardware event information in a single measurement run.
o IBS collects new information such as retire delay and data cache miss latency.

* Call Stack Sampling (CSS) : Combining with TBP or EBP, Call Stack Sampling is able to collect data on caller-callee relationship on the hotspots.

* Pipeline Simulation : Used during the second stage of an optimization effort to find the causes of bottlenecks. During simulation, application execution is first traced, and then simulated on a selected target processor. The detailed data on the execution of each instruction takes into account the previous instructions executed and the state of the processor caches. Simulation only supports single processor execution.

Pipeline Simulation supports the simulation of 32-bit code on:
o AMD Athlon™ XP processor
o AMD Opteron™ processor
o AMD Athlon™ 64 processor

Pipeline Simulation also supports the simulation of 64-bit code on:
o AMD Opteron™ processor
o AMD Athlon™ 64 processor

* Thread Profile : CodeAnalyst thread profiling views show the thread chart and non-local memory access.

* Post Process : CodeAnalyst shows sample distribution without module debug information.
o Interpret performance measurements rather than display raw performance data
o Flexible view configuration and management

---------------
This tool reportedly only works for AMD processors, while its Intel counterpart is the VTune Performance Analyzer.
Also listed in: Profiler Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: jClazzME
Rating: 5.0 (1 vote)
Author: Annimon                        
Website: http://annimon.wen.ru
Current version: 1.2.3
Last updated: June 8, 2009
Direct D/L link: bin_jClazzME_2010-6-1_14.44__jClazzME.jar
License type: Unknown - Open Source
Description: jClazzME is a tool for decompiling Java class file.

jClazzME is a J2ME application . Therefore it would work for any mobile phone that support J2ME with JSR-75.

jClazzME is also a Java disassembler.
Also listed in: Decompilers, Java Decompilers, Mobile Platform Decompilers, Mobile Platform Tools, Symbian Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Javassist
Rating: 5.0 (1 vote)
Author: Shigeru Chiba                        
Website: http://www.csg.is.titech.ac.jp/~chiba/javassist/
Current version: 3.12.0.GA
Last updated: April 16, 2010
Direct D/L link: N/A
License type: Free
Description: Javassist (Java Programming Assistant) makes Java bytecode manipulation simple. It is a class library for editing bytecodes in Java; it enables Java programs to define a new class at runtime and to modify a class file when the JVM loads it. Unlike other similar bytecode editors, Javassist provides two levels of API: source level and bytecode level. If the users use the source-level API, they can edit a class file without knowledge of the specifications of the Java bytecode. The whole API is designed with only the vocabulary of the Java language. You can even specify inserted bytecode in the form of source text; Javassist compiles it on the fly. On the other hand, the bytecode-level API allows the users to directly edit a class file as other editors.

Aspect Oriented Programming: Javassist can be a good tool for adding new methods into a class and for inserting before/after/around advice at the both caller and callee sides.

Reflection: One of applications of Javassist is runtime reflection; Javassist enables Java programs to use a metaobject that controls method calls on base-level objects. No specialized compiler or virtual machine are needed.
Also listed in: Java Code Injection Tools, Java Executable Editors & Patchers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: P32DASM
Rating: 5.0 (1 vote)
Author: DARKER                        
Website: http://progress-tools.x10.mx/p32dasm.html
Current version: 2.8
Last updated: May 24, 2011
Direct D/L link: http://progress-tools.x10.mx/p32dasm.zip
License type: Free
Description: P32Dasm is a Visual Basic 5.0/6.0 PCode + Native code Decompiler. It can generate String, Numbers, Objects, Import and Export function listing. There is also Jump calculator. For VB Native code executables are generated only MSVBVM, External calls and string references. Usefull for setting BPX, you don't need search in debugger where start some Command Button event. You can generate .map files, which you can import to DataRescue IDA (LoadMap plugin) or to Olly Debugger (MapConv plugin).
Also listed in: Disassemblers, Visual Basic Decompilers
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: 2.0.0
Last updated: October 10, 2017
Direct D/L link: http://bin.rada.re/radare2-w32-2.0.0.zip
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, Ring 3 Debuggers, 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: Rebel.NET
Rating: 5.0 (1 vote)
Author: Daniel Pistelli                        
Website: http://ntcore.com/rebelnet.php
Current version: 1.6.0.1
Last updated: September 3, 2010
Direct D/L link: http://ntcore.com/files/RebelDotNET.zip
License type: Free
Description: Rebel.NET is a rebuilding tool for .NET assemblies which is capable of adding and replacing methods and streams.

It's possible to replace only a limited number of methods or every method contained in a .NET assembly. The simplicity of Rebel.NET consists in the replacing process: one can choose what to replace. For instance, one may choose to replace only the method code, instead of its signature or method header.

The interface of Rebel.NET is quite a simple one. As input it requires a .NET assembly to be rebuilded and a Rebel.NET rebuilding file. The Rebel.NET file contains the data that has to be replaced in the original assembly.

Rebel.NET can also create a Rebel.NET file from a given assembly. This is a key functionality, since some times the data of the original assembly has to be processed first to produce a Rebel.NET file for the rebuilding of the assembly. This sort of "report" feature can also be used to analyze the methods of an assembly, since reading the original data from a .NET assembly isn't as easy as reading a Rebel.NET file. It's possible to choose what should be contained in the Rebel.NET file.

All the Rebel.NET features can used through command line, which comes very handy when an automated rebuilding process is needed.

Rebel.NET is, mainly, a very solid base to overcome every .NET protection and to re-create a fully decompilable .NET assembly. As such, Rebel.NET has to be considered a research project, not an encouragement to violate licensing terms.
Also listed in: .NET Code Injection Tools, .NET Executable Editors
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Reflector for .NET
Rating: 5.0 (1 vote)
Author: Lutz Roeder (current owner Red Gate Software)                        
Website: http://www.reflector.net/
Current version: 7.7
Last updated: July 18, 2009
Direct D/L link: http://shop.reflector.net/download
License type: Free until 6.8.2.5
Description: From website:

"Reflector is a very powerful class browser, explorer, analyzer and documentation viewer for .NET. Reflector allows to easily view, navigate, search, decompile and analyze .NET assemblies in C#, Visual Basic and IL."

This is one of the most powerful .NET decompilers that you can't buy - just download :)
Many of the popular commercial tools achieving the same goal "suddenly" got a boost when this masterpiece of work saw a daylights (and besides that those are commercial, still have hard time with obfuscators).

Just give it a try, it will last literally five minutes - load some well known assembly of yours, choose target .NET language (!) and let'em work. Then compare it with the original.

You'll surely not forget this one.
Also listed in: .NET Decompilers, .NET Disassemblers, Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: THYloadergen
Rating: 5.0 (1 vote)
Author: veyl/THY                        
Website: N/A
Current version: 0.6
Last updated: March 6, 2010
Direct D/L link: Locally archived copy
License type: creditware
Description: features:
* memory patch packed targets (except process redirected ones, like armadillo debugblocker)
* patch:VA (patch at a virtual address)
* patch:SnR (patch by search&replace)
* hookAPI (specify an API call that is executed after target is fully unpacked. hit count can be specified)
* hookVA (specify a VA that is executed after target is fully unpacked. hit count can be specified)
* wnd (specify a window that is created after target is fully unpacked)
* inject a dll into the process to have the possibility to include more complex stuff than the patching provided. (no live injecting, as this is a loader)
* optional splash screen at startup (pic can be specified, aswell as the transparency)


veyl/THY, MAR/2010
Also listed in: Code Injection Tools, Loader Generators, Memory Patchers, Patch Packaging Tools, Patcher Generators
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: xADT eXtensible Anti-Debug Tester
Rating: 5.0 (2 votes)
Author: Shub-Nigurrath / ARTeam                        
Website: http://arteam.accessroot.com
Current version: 1.4
Last updated: September 22, 2008
Direct D/L link: http://arteam.accessroot.com/releases.html?fid=33
License type: Free
Description: xADT eXtensible Anti-Debug Tester by Shub-Nigurrath
---------------------------------------------------

1. Description
--------------
The tool is thought to be an unique extensible platform for integrating all the anti-debugging tricks you might see around, using an unique extensible interface you also might easily extend. The tool is useful to test the hiding features of the debugging tools and custom loaders as well as the hiding of any other reversing tool: see how well they're hidden or not. The second advantage is to finally have an unique testing program and to not have hundreds of spare tiny programs. The easiness of adding new external tests, writing new plugins is also one important feature IMHO, which finally frees the author of new anti-debugging tools to concentrate on the logic of the test without having to spend a single second on its user's interface.

Do you think your Olly is well hidden? Try this tool from Olly and all the possible hiding tools around, up to today there's always one test which detects Olly!

2. Interface
------------
The interface is pretty intuitive I think, just check all or some and perform the test with button or double click, the results are then reported on the list.. If you want to have a description of the single tests you might also use the description the program report..
The interface is completely resizable and a color code is used for results: a semaphoric logic for tests result, positive means xADT got you are debugging it! An italic font means the test was not able to say a positive or negative answer, It's undecided.

To select a test you can enable it and then press Start button or double click on it to directly execute the test

2.1 Keyboard shortcuts:
-----------------------
There are several shortcuts available to handle the tool without a mouse. The keys are *not* case sensitive.

SPACE = select/unselect test under cursor
ESC = exit from application
RETURN = do test under cursor
C = it's the same of pressing the Clear button
S = it's the same of pressing the Start Selected button
CTRL-A = It's the same of pressing the Enable checkbox, togles enabling of all the tests

2.2. Internal tests
--------------------
There are several internal tests the program does independently from the plugins. They are marked as "Int" versus plugin's tests which are marked as "Ext". At the moment there's no documentation on each tests detail.

2.3. External Tests
-------------------
The program has the possibility to execute several external plugins (there's no limits), each one implementing one or more tests. The plugin must conform to a specifi interface and can use some services offered by the main program (like OllyDbg does) -see after-. The path where plugins are stored is inside the .ini file, created the first time the program is executed on a PC.

2.4. First launch on a new machine
----------------------------------
Usually at the first launch there's no xADT.ini file still, so the program complains about this and open a Shell Folder to ask you where the plugins are supposed to be. Once chosen this function will not be asked again, till the plugins remain where you told.

4. Create new Plugins
---------------------
The program includes several internal tests, but I also added the possibility to easily write your own tests as plugins with ANY language you want (the only requirement is that the plugin must be a DLL). The plugins' dlls must conform to simple rules..

I added in the distribution the xADT_PDK.h file to be used for your new plugins and a xADT.lib to use some services offered by the program to the plugins.

4.1. The header file
--------------------
The xADT_PDK.h is written in C, but being absolutely easy you can simply conform to it without using C.
The rules the exports of the plugins must follow are simple, just see the examples included in the distribution. For example for the ParentProcess plugin you have a dll with the three following exports:

tst_ParentProcess
tst_ParentProcess_description
tst_ParentProcess_name
tst_ParentProcess_about

Each test dll to be valid must have at least 3 functions for each test, with the following structure:

__declspec (dllexport) Result tst_ParentProcess(char *message)
__declspec (dllexport) char* tst_ParentProcess_description()
__declspec (dllexport) char* tst_ParentProcess_name()
__declspec (dllexport) char* tst_ParentProcess_about()

I included the file xADT_PDK.h which contains some useful declarations you need in order to write a Dll, using this file (for C and C++) or equivalent for other languages, you can write the 3 above functions as following:

EXPORT Result tst_ParentProcess(char *message);
EXPORT char* tst_ParentProcess_description();
EXPORT char* tst_ParentProcess_name();
EXPORT char* tst_ParentProcess_about();

where Result is an enum type. The possible values of this enumeration type are:

typedef enum {UNKNOWN, NEGATIVE, WARNING, POSITIVE} Result;

UNKNOWN is equal to 0, all the following according to the first value (so POSITIVE is the same as returning 3).

4.2 The library of xADT exports
-------------------------------
Like for what happens with OllyDbg the main program exports some function helpers for plugins. The can be used including the xADT.lib into your projects.
See the xADT_PDK.h for further details on the functions available for each release.

4.3 What the single functions should do
---------------------------------------
As I said before there are 3 functions each plugin must export with a specific name structure. 3 functions for each single test. Obviouslly a single dll can contain different test. For example suppose to have a dll with 2 tests inside, named Test1 and Test2. In this situation the Dll will have to export 6 total exports named like following:

tst_Test1
tst_Test1_description
tst_Test1_name
tst_Test1_about
tst_Test2
tst_Test2_description
tst_Test2_name
tst_Test2_about

You can see the example FindWindow_and_Time for a dll which exports more tests into a single Dll

4.3.1 tst_NameOf_the_Test
-------------------------
"tst_NameOf_the_Test" is the real the test function. The function should return a Result (see the PDK) value, according to the test result. As imput parameters a pointer to a char* with can be used to report messages to XADT (it will be shown in lower part of xADT interface). The message must NOT be longer than 260 (equal to system's define MAX_PATH) chars.
There are four possible returning values

UNKNOWN (or 0) -
NEGATIVE (or 1)
WARNING (or 2)
POSITIVE (or 3)

Tests return POSITIVE when a debugger is detected and NEGATIVE otherwhise or even UNKNOWN if no conclusion can be given. The status WARNING is used when the test is not so sure of being debugged (some anti-debug tests reports only a possibility). UNKNOWN is used only when something fails (for example one of the internal tests is working only on specific Windows system or so).

4.3.2 tst_NameOf_the_Test_description
-------------------------------------
Use "tst_NameOf_the_Test_description" as the function returning a char* string descripting the test. The char* should not be longer than 260 chars. No imput parameters. Credits also might go here but I suggest using the _about export described after.
Usually this function is not much more than fo example what follows:

EXPORT char* tst_ParentProcess_description() {
return "Test looking if the ParentProcess is a debugger";
}

4.3.3 tst_NameOf_the_Test_name
------------------------------
Use "tst_NameOf_the_Test_name" as the function returning a char* string containing the test's name. No imput parameters, same rule on max lenght of the string of the functions like tst_NameOf_the_Test_description (max 260 chars).

4.3.4 tst_NameOf_the_Test_about
-------------------------------
Use "tst_NameOf_the_Test_about" as the function returning a char* with a string containing about information or credits. No input parameters, the max lenght of the returned string must be 80 chars, longer strings are cut. The max lenght of the string follows a limitation of Windows tooltips, that are by default no longer than 80 chars. This export is optional, this means that the plugin can not implement it.


"Name_of_the_Test" can be anything you like (according to C names rules of course, so no spaces for example :-))

4.4 Example plugins
-------------------
I included several explanatory examples which should facilitate developing new tests for different languages
[*] FindWindow_and_Time: an example of a C Dll exporting more than one test
[*] ParentProcess: example of a more complex C++ dll exporting just one test
[*] UnhandledExceptionFilter: example of a MASM dll exporting one test

4.5 New plugins
---------------
Please report to me or on the ARTeam forum eventually new plugins you might create, I will include them in future distributions. 10x

5. Miscellanea
---------------
Here I'm reporting some other answers to questions I have not reported before and that have been asked to me, while testing this tool. It's a mini FAQ

Q) How many tests I can place into a single plugin dll?
A) Dlls can have as many tests as they like, given that all the test follow the above rules (3 exports each test with above naming rules).

Q) which is the execution environment of the tests?
A) The tests are performed inside the xADT process, so to get the information about the process is enough to use for functions such as GetCurrentProcessId and similar, or to call OpenProcess or OpenThread on yourself, calling with something like this:
HANDLE hproc=OpenProcess(PROCESS_ALL_ACCESS,FALSE, GetCurrentProcessId());
HANDLE hthread=OpenThread(THREAD_ALL_ACCESS, FALSE, GetCurrentThreadId());

Q) Which language I can use to write plugins?
A) The language used to create the Dlls can be anything, the rules the dll must conform to are very simple and can be implemented with any language you like. Indeed the distribution also has an example of a MASM plugin (UnhandledExceptionFilter) -thanks deroko-

Q) Which language is best to be used?
A) Depends on your knowledge. I'm fo example be used to C/C++ but I must admit that the results are big files filled with useless things, so ASM in this sense is much more efficient. For any choice there are, as like for any medal, pros and cons.

Q) When I first launch the program I receive an error dialogbox telling that it cannot find the plugins
A) If the program at first launch tells that the plugin path cannot be found, just erase the ini file and restart xADT. It will ask again the correct plugin's path and create a new ini file. Or just edit the ini file! The distribution comes without ini file so the program asks for the first time where the plugins are located.

Q) What are the internal plugins?
A) xADT has several internal tests which are built inside the tool. Usually these tests are really simple and the overhead would hve been added placing them as external would have made a basic distribution too big. I have used common parts of the program so the whole size isn't increased that much.

Q) I cannot see the whole list of tests and part of the descriptions
A) The application is designed to be resizable as you like. Enlarge the window :-O

Q) How are sorted the plugins?
A) The sorting is all the internal tests and then all the external..

Q) How can my plugin access to the plugin folder to load external files (e.g. a .sys file)
A) Include in your projects also the xADT.lib and use the xADT_PluginFolder exposed API.

Q) How can I insert credits for the plugin I wrote
A) You might use the _about export for your plugin and write your text there. Note that must be at max 80 chars. The message will be shown in the tooltip that appears for each list entry.

Q) I wrote a new plugin but I want to test it in my development environment
A) I can speak of Visual Studio. Compile the plugin in debug mode, select as executable of the DLL xADT.exe. Before starting just take care to modify the file "xadt.ini". Make it pointing to the debug folder of your new plugin. Visual Studio breaks when the code of the plugin is executed by xADT.

6. Some Notes on the tests
--------------------------
1. Some tests are just PoC and can be improved, I released the sources for them, an example is the test NtQueryInfoProc_hook_detection which can also be used with other anti-debug tests and not only with NtQueryInfoProc
2. The xadt_Allybof test is though to exploit the export name buffer overflow vulnerability of Olly, trying to crash it. This plugin is from Defsanguje. By it's nature the test works perfectly if xADT is debugged by OllyDbg, but crashes xADT if the program is running normally. Then pay attention and eventually do not launch this test or remove the dlls (the test is made of two dlls: xadt_Allybof.dll and Allybof.dll) from the plugin folder.
3. Several tests are connected to execution time thresholds which detect the presence of a debugger, because the same code goes slower than usual. This timing based tests are sensible to slow machines, because in these cases the thresholds should be higher. I didn't coded any thresholds adaptation routine, so you might get some false positive on slow machines or virtually emulated machines (which are slow too). You can disassemble the dll or recompile it to adapt the thresholds to your needs.
4. xADT has been tested with all the combinations:
Operative Systems on real PCs and Virtual PC:
Windows XP SP2/SP3,
Windows Vista
OllyDbg:
SND OllyDbg,
normal OllyDbg,
OllDbg modded using xFile,
hidden using xFile,advancedolly,analyzethis,hidedebugger,ollydump

7. History
----------
version 1.4
-slightly modified the readme FAQ section
-Everything has been tested with Windows XPSP3 and sources are have been tested with VS2008 and VS60
-fixed an error in the PDK _cdecl convention wasn't explicitly declared

plugins:
-minor bugfixing of some previously released plugins
-Updated FindWindow Complex with recent keywords (like PHANTOM, 0LLY, BR3AKPOINTS,...)
-fixed xadt_ollybof.dll. Now it's named Allybof. PAY ATTENTION: due to the nature of the test whole xADT might crash
if tested outside OllyDbg (see paragraph 6 of this same file)
-fixed SIDT Test (now is called ex-SIDT) which was crashing the system on multi-processor machines

new-plugins: total of 20 new tests
+ex-SIDT, a fixup of the old SSIDT test, thanks to deroko who rewrote the driver (now is multprocessor aware). This is a PoC of multi-plugin using drivers
+ex-SIDT also performs a Ring0 test of debug registers
+NtQueryInfoProc_hook_detection (idea of Metr0/SnD), plus standalone Proof-of-concepts
+DeleteFiber (idea of evilcry), plus documentation on the theory of the test
+NtSystemDebugControl (idea of evilcry), plus documentation on the theory of the test. This plugins implements 3 dimostrative tests
+xadt_SofticeServicesTest by deroko, which tests the present of SOFTICE using OpenServiceA/EnumServicesStatusA/EnumServicesStatusExA
(3 internal tests done)
+int2Atrick (idea of ReWolf), plus documentation on the theory of the test
+MiscTricks from ideas documented here http://www.securityfocus.com/infocus/1893 (also included in distribution).
All tests not already implemented in xADT have been included (9 tests)

+full sources (projects tested with VS60/VS2008) of the following plugins, often with explations on theory and how you can hide:
ex-SIDT, sources of driver and plugin
int2Atrick,
DeleteFiber,
NtSystemDebugControl,
SICE_Tricks,
MiscTricks,
xadt_SofticeServicesTest
NtQueryInfoProc_hook_detection sources of standalone C and ASM programs and of the whole plugin
+added ZwQueryObject_readme.txt which explains a possible way to solve the ZwQueryObject test (thanks to deroko)

standalone tools:
+All the tests ChupaChu released since version 1.3 as a separate standalone program too: "testbed_chupachu.exe"
+Included in the distribution the program EDD Extreme Debug Detector by Hellsp@wn, this program does less tests but it's handy to have it in this package too

version 1.3
new-plugins:
+xADTplugin_delphi_source sources of IsDebuggerPresent dll test in Delphi (10x 2 rudikkin), use them as sample to write Delphi plugins
+sources of DBG_PRINTEXCEPTION_C a novel detection method developed by MOID/TSRh
+several plugins developed by ChuPaChu. The same tests are also available into the testbed_chupachu.exe program I included too

version 1.2
main program:
-fixed initial working directory bug which prevented to load the xADT.ini file correctly (e.g from OllyDbg Bar)
-fixed several selections bugs from the list of available tests. Now works in all cases
-fixed a bug into the export browsing routine for plugins with more than one test inside, which prevented multiple plugins
to work
+improved stability of the program for plugins not correctly exporting all functions as foreseen
-fixed tooltips, now it displays the string returned by _about export, when mouse is over the line of a test
+added tooltips with result of the test: now the tooltip of the result column contains the string returned by the test to xADT.
+added keyboard interface: see readme for details
+added horizontal scroll for panels for longer descriptions
plugins:
+improved previous plugins and added an example plugin with several tests inside
+added support for optional _about exports for plugins, now it can be used to specify credits, the string is shown as tooltip
-fixed driver unloading problems in SIDT plugin
new-plugins:
+added RDTSC and INT3 plugin (inside FindWindow_and_Time.dll)
+added GetSystemTime and INT3 plugin (inside FindWindow_and_Time.dll)
+added some anti-SICE plugin (inside FindWindow_and_Time.dll)
+added Find Complex test (inside FindWindow_and_Time.dll), a very complex plugin which perform a lot of interesting tests.
It's also a POC on how plugins might have their own interface
+added SICETricks (SICETricks.dll) plugin which perform several SoftICE Specific tests
+added 3 tests by ap0x: EnumWindows, GetProcessHeaps and PageGuard (into xADT_ap0x.dll)

version 1.1
main program:
+splitter function, panels now can be resized dynamically
+windows and splitter position and size are now saved
+divided the messages panel into two positive and negative panels to separate results list
+now the title bar reports a count of test results
+added a PDK. Now plugin can start using it from the main program (like OllyDbg does)
-fixed internal test ZwQueryInformationThread
-small bugs fixed

version 1.0
main program:
-great code refactoring and general improvements
-changed the plugin's interface
+several new plugin and released examples
+added an example plugin written in MASM (by deroko)

version 0.8
-first released version


Have Phun,
Shub-Nigurrath

Last revision: 30th August 2008
Also listed in: Anti Debug Test Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DeDe
Rating: 4.0 (1 vote)
Author: DaFixer                        
Website: http://dafixer.cjb.net
Current version: 3.50.04 (build 1635)
Last updated: June 25, 2006
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: DeDe is a very fast application that allows you to analyze executables compiled with Delphi 2,3,4,5,6,7, C++ Builder, Kylix and Kol, and gives you the following:

· All .dfm files of the target. You will be able to open and edit them with Delphi.
· All published methods in well commented ASM code with references to strings, imported function calls, classes methods calls, components in the unit, Try-Except and Try-Finally blocks. (By default DeDe retrieves only the published methods sources, but you may also process another procedure in a executable if you know the RVA offset using the Tools->Disassemble Proc menu.)
· A lot of additional information the files.
· You can create a Delphi project folder with all dfm, pas, dpr files. Note: pas files contains the mentioned above well commented ASM code. They can not be recompiled !

You can also:
· View the PE Header of all PE Files and change/edit the sections flags.
· Use the opcode-to-asm tool for translating intel opcode to assembler.
· Use RVA-to-PhysOffset tool for fast converting physical and RVA addresses.
· Use the DCU Dumper (view dcu2int.txt for more details) to retrieve near to pascal code of your DCU files.
· Use BPL(DPL) Dumper to see BPL exports and create symbol files to use with DeDe disassembler.
· Disassemble a target EXE directly from memory in case of a packed exe.

------------
NOTE:
The original site seems to be gone (or at least DeDe seems to be gone from it).
The locally archived copy here in this CRCETL entry only has the 3.10 source (it has the most recent(?) 3.50.04 build 1635 binary though). If you have access to any later source code version than 3.10, please upload it here.
Also listed in: Decompilers, Delphi Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Ultimate Hooking Engine
Rating: 4.0 (1 vote)
Author: deroko of ARTeam                        
Website: http://deroko.phearless.org
Current version:
Last updated: August 10, 2007
Direct D/L link: Locally archived copy
License type: Free
Description: Engine allows anyone to hook APIs very easily using their hooking dll.

Each hooking dll might have 3 types of exports:
1. prefixed HOOK
2. prefixed Detoured
3. hookmain (optional)

1. Whenever you want to hook some API you will put this kind of export:

HOOK_kernel32_GetModuleHandleA
HOOK_user32_MessageBoxA

Also note that inline hook will point to this procedure so this procedure
will have all of your code responsible for certain API.

2. To be able to call original API from your hook you should export also
this variable (in C/C++ it will be function pointer):

Note how variables are prefixed with "Detoured_"

Detoured_GetModuleHandleA
Detoured_MessageBoxA

Here is one example from C/C++ code:

extern "C" __declspec(dllexport) HMODULE (__stdcall *Detoured_GetModuleHandleA)(LPCTSTR modulename) = NULL;

extern "C" HMODULE __declspec(dllexport) __stdcall HOOK_kernel32_GetModuleHandleA(LPCTSTR modulename){
return Detoured_GetModuleHandleA(modulename);
}

Note also that this is optional, if you don't need to call orignal proc,
then you don't need this export.

Note that when working with MSVC2005 it will always screw export name for
procedures while function pointers are properly exported, so add this line
to your .def file:

HOOK_kernel32_GetModuleHandleA = _HOOK_kernel32_GetModuleHandleA@4
Detoured_GetModuleHandleA


3. hookmain

hookmain is export which has this prototype:

void __stdcall hookmain();

This procedure will be called before program jumps to entrypoint of
target, here you may add some extra code, it isn't very useful and
all initialization you may perfrom in DllEntry, but I leave this here
just in case that you want to start your own tracer before code jmps
to entrypoint. At least that's why I'm using it.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Detours
Rating: 3.5 (2 votes)
Author: Microsoft                        
Website: http://research.microsoft.com/sn/detours
Current version: 2.1.216
Last updated: November 10, 2008
Direct D/L link: http://ftp.research.microsoft.com/downloads/d36340fb-4d3c-4ddd-bf5b-1db25d03713d/DetoursExpress.msi
License type: Free
Description: Innovative systems research hinges on the ability to easily instrument and extend existing operating system and application functionality. With access to appropriate source code, it is often trivial to insert new instrumentation or extensions by rebuilding the OS or application. However, in today's world systems researchers seldom have access to all relevant source code.

Detours is a library for instrumenting arbitrary Win32 functions on x86, x64, and IA64 machines. Detours intercepts Win32 functions by re-writing the in-memory code for target functions. The Detours package also contains utilities to attach arbitrary DLLs and data segments (called payloads) to any Win32 binary.

Detours preserves the un-instrumented target function (callable through a trampoline) as a subroutine for use by the instrumentation. Our trampoline design enables a large class of innovative extensions to existing binary software.

We have used Detours to create an automatic distributed partitioning system, to instrument and analyze the DCOM protocol stack, and to create a thunking layer for a COM-based OS API. Detours is used widely within Microsoft and within the industry.

Detours 2.1 is now available. Detours 2.1 includes the following new features:

* Complete documentation of the Detours API.
* Transactional model for attaching and detaching detours.
* Support for updating peer threads when attaching or detaching detours.
* Unification of dynamic and static detours into a single API.
* Support for detection of detoured processes.
* Significant robustness improvements in APIs that start a process with a DLL containing detour functions.
* New APIs to copy payloads into target processes.
* Support for 64-bit code on x64 and IA64 processors (available in Professional edition only).
* Supports building detours with Visual Studio 2005, Visual Studio .NET 2003, Visual Studio .NET (VC8), and Visual Studio (VC7).
Also listed in: API Monitoring Tools, Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: .NET Hook Library
Rating: 0.0 (0 votes)
Author: shokshok                        
Website: http://dotnethook.sourceforge.net
Current version: 2.1
Last updated: May 30, 2002
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: .Net Hook Library is a library (with a sample tool) to manipulate functions in a .NET Assembly. It allows for insertion of arbitrary code at the beginning of each function called in a .NET assembly (whether executable or assembly). Also provides code that reads through metadata and dumps information on it.

The download contains detailed documentation about how it works and what it is.

I'm in the process of converting this from an executable to a library. That way, existing applications can use it to modify the .NET binaries (a.k.a assemblies).
Also listed in: .NET Code Injection Tools, Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Anathema .NET Instrumentation Tool
Rating: 0.0 (0 votes)
Author: Antonio "s4tan" Parata                        
Website: http://www.phrack.org/papers/dotnet_instrumentation.html
Current version:
Last updated: January 11, 2018
Direct D/L link: Locally archived copy
License type: Open Source
Description: |=-----------------------------------------------------------------------=|
|=--------=[ .NET Instrumentation via MSIL bytecode injection ]=---------=|
|=-----------------------------------------------------------------------=|
|=----------=[ by Antonio "s4tan" Parata <aparata@gmail.com>]=-----------=|
|=-----------------------------------------------------------------------=|


1 - Introduction
2 - CLR environment
2.1 - Basic concepts
2.1.1 - Metadata tables
2.1.2 - Metadata token
2.1.3 - MSIL bytecode
2.2 - Execution environment
3 - JIT compiler
3.1 - The compileMethod
3.2 - Hooking the compileMethod
4 - .NET Instrumentation
4.1 - MSIL injection strategy
4.2 - Resolving the method handle
4.3 - Implementing a trampoline via the calli instruction
4.4 - Crafting a dynamic method
4.5 - Invoking the user defined code
4.6 - Fixing the SEH table
5 - Real world examples
5.1 - Web application password stealer
5.2 - Malware inspection
6 - Conclusion
7 - References
8 - Source Code


--[ 1 - Introduction

In this article we will explore the internals of the .NET framework with
the purpose of providing an innovative method to instrument .NET programs
at runtime.

Actually, there are several libraries that allow to instrument .NET
programs; most of them install a hook in the code generated after compiling
a given method, or by modifying the Assembly and saving back the result of
the modification.

Microsoft also provides a profile API in order to instrument the execution
of a given program. However the API must be activated before executing the
program by setting specific environment variables.

Our goal is to instrument the program at runtime by leaving the Assembly
binary untouched; all this by using a high level .NET language. As we will
see, this is done by injecting additional MSIL code just before the target
method is compiled.


--[ 2 - CLR environment

Before describing in depth how to inject additional MSIL code in a method,
it is necessary to provide some basic concepts as on how the .NET framework
works and which are its basic components.

We will only describe the concepts that are relevant to our purpose.


---[ 2.1 - Basic concepts

A .NET binary is typically called Assembly (even if it doesn't contain any
assembly code). It is a self-describing structure, meaning that inside an
Assembly you will find all the necessary information to execute it (for
more information on this subject see [01]).

As we will shortly see, all this information can be accessed by using
reflection. Reflection allows us to have a full picture of which types and
methods are defined inside the Assembly. We can also have access to the
names and types of the parameters passed to a specific method. The only
missing information are the names of the local variables, but as we will
see this is not a problem at all.


----[ 2.1.1 - Metadata tables

All the above mentioned information is stored inside tables called
Metadata tables.

The following list taken from [02] shows the index and names of all the
existing tables:

00 - Module 01 - TypeRef 02 - TypeDef
04 - Field 06 - MethodDef 08 - Param
09 - InterfaceImpl 10 - MemberRef 11 - Constant
12 - CustomAttribute 13 - FieldMarshal 14 - DeclSecurity
15 - ClassLayout 16 - FieldLayout 17 - StandAloneSig
18 - EventMap 20 - Event 21 - PropertyMap
23 - Property 24 - MethodSemantics 25 - MethodImpl
26 - ModuleRef 27 - TypeSpec 28 - ImplMap
29 - FieldRVA 32 - Assembly 33 - AssemblyProcessor
34 - AssemblyOS 35 - AssemblyRef 36 - AssemblyRefProcessor
37 - AssemblyRefOS 38 - File 39 - ExportedType
40 - ManifestResource 41 - NestedClass 42 - GenericParam
44 - GenericParamConstraint

Each table is composed of a variable number of rows. The size of a row
depends on the kind of table and can contain a reference to other Metadata
tables.

Those tables are referenced by the Metadata token, a notion that is
described in the next paragraph.


----[ 2.1.2 - Metadata token

The Metadata token (or token for short) is a fundamental concept in the CLR
framework. A token allows you to reference a given table at a given index.
It is a 4-byte value, composed of two parts [08]: a table index and the
RID.

The table index is the topmost byte wich points to a table. A RID is a
3-byte record identifier pointing in the table, which starts at offset one.

As an example, let's consider the following Metadata token:

(06)00000F

0x06 is the number of the referenced table, which in this case is
MethodDef. The last three bytes are the RID, that in this case has a value
of 0x0F.


----[ 2.1.3 - MSIL bytecode

When we write a program in a .NET high level language, the compiler will
translate this code into an intermediate representation called MSIL or as
defined in the ECMA-335 [03] CIL, which stands for Common Intermediate
Language.

By installing Visual Studio you will also install a very handy utility
called ILDasm, that allows you to disassemble an Assembly by displaying the
MSIL code and other useful information.

As an example let try to compile the following C# source code:

------#------#------#------<START CODE>------#------#------#------
public class TestClass
{
private String _message;

public TestClass(String txt)
{
this._message = txt;
}

private String FormatMessage()
{
return "Hello " + this._message;
}

public void SayHello()
{
var message = this.FormatMessage();
Console.WriteLine(message);
}
}
------#------#------#------<END CODE>------#------#------#------

The result of the compilation is an Assembly with three methods:
.ctor : void(string), FormatMessage : string() and SayHello : void().

Let's try to display the MSIL code of the SayHello method:

------#------#------#------<START CODE>------#------#------#------
.method public hidebysig instance void SayHello() cil managed
// SIG: 20 00 01
{
// Method begins at RVA 0x21f8
// Code size 16 (0x10)
.maxstack 1
.locals init ([0] string message)
IL_0000: /* 00 | */ nop
IL_0001: /* 02 | */ ldarg.0
IL_0002: /* 28 | (06)00000F */
call instance string MockLibrary.TestClass::FormatMessage()
IL_0007: /* 0A | */ stloc.0
IL_0008: /* 06 | */ ldloc.0
IL_0009: /* 28 | (0A)000014 */
call void [mscorlib]System.Console::WriteLine(string)
IL_000e: /* 00 | */ nop
IL_000f: /* 2A | */ ret
} // end of method TestClass::SayHello
------#------#------#------<END CODE>------#------#------#------

For each instruction we can see the associated MSIL byte values. It is
interesting to see that the code doesn't contain any reference to unmanaged
memory but only to metadata tokens.

The two call instructions reference two different tables, due to the
FormatMessage method being implemented in the current Assembly and the
WriteLine method implemented in an external Assembly.

If we take a look at the list of tables presented in 2.1.1 we can see that
the Metadata token (0A)000014 references the table 0x0A which is the
MemberRef table, index 0x14 which is WriteLine. Instead the token
(06)00000F references the table 0x06 which is the MethodDef table, index
0x0F which is FormatMessage.


---[ 2.2 - Execution environment

The CLR execution environment is very strict and forbids any kind of
dangerous operation. If we compare it with the unmanaged world where we
were able to jump in the middle of an instruction to confuse the
disassembler, to create all kinds of opaque instructions or to jump to any
valid address, we will discover a sad truth: everything is forbidden.

The CLR is a stack based machine. This means that there is no concept of
registers and every parameter is pushed on the stack in order to be passed
to other functions. When we exit a method, the stack must be empty or at
least contain the value that should be returned.

As already said, everything is based on the definition of the Metadata
token. If we try to invoke a call with an invalid token we will receive a
fatal exception. This poses a serious problem for our goal, since we cannot
call methods that are not referenced by the original Assembly.


--[ 3 - JIT compiler

When a method is executed we have two different scenarios. The first one is
when the method is already compiled, in this case the code just jumps to
the compiled unmanaged code. The second scenario is when the method isn't
yet compiled, in this case the code jumps to a stub that will call the
exported method compileMethod, defined in corjit.h [04], in order to
compile and then execute the method.


---[ 3.1 - The compileMethod

Let's analyze this interesting method a bit more. The signature of
compileMethod is the following:

virtual CorJitResult __stdcall compileMethod (
ICorJitInfo *comp, /* IN */
struct CORINFO_METHOD_INFO *info, /* IN */
unsigned /* code:CorJitFlag */ flags, /* IN */
BYTE **nativeEntry, /* OUT */
ULONG *nativeSizeOfCode /* OUT */
) = 0;

The most interesting structure is the CORINFO_METHOD_INFO
which is defined in corinfo.h [05] and has the following format:

struct CORINFO_METHOD_INFO
{
CORINFO_METHOD_HANDLE ftn;
CORINFO_MODULE_HANDLE scope;
BYTE * ILCode;
unsigned ILCodeSize;
unsigned maxStack;
unsigned EHcount;
CorInfoOptions options;
CorInfoRegionKind regionKind;
CORINFO_SIG_INFO args;
CORINFO_SIG_INFO locals;
};

For our purpose the most important field is the ILCode byte pointer. It
points to a buffer which contains the MSIL bytecode. By modifying this
buffer we are able to alter the method execution flow.

As a side note, this method is also extensively used by .NET obfuscators.
In fact we can read the following comment in the source code:

Note: Obfuscators that are hacking the JIT depend on this method having
__stdcall calling convention

An obfuscator typically encrypts the MSIL bytecode of a method, then when
the method is bound to be executed they decrypt the bytecode and pass this
value as byte pointer instead of the encrypted one. This also explains why
if we open it in ILDasm or with a decompiler we receive back an error. How
can they know when a method is going to be called? This is pretty easy,
the code in charge for the replacement process is placed inside the type
constructor. This specific constructor is invoked only once: before a new
object of that specific type is created.


---[ 3.2 - Hooking the compileMethod

Since the compileMethod is exported by the Clrjit.dll (or from mscorjit.dll
for older .NET versions), we can easily install a hook to intercept all the
requests for compilation. The following F# pseudo-code shows how to do
this:

------#------#------#------<START CODE>------#------#------#------
[<DllImport(
"Clrjit.dll",
CallingConvention = CallingConvention.StdCall, PreserveSig = true)
>]
extern IntPtr getJit()

[<DllImport("kernel32.dll", SetLastError = true)>]
extern Boolean VirtualProtect(
IntPtr lpAddress,
UInt32 dwSize,
Protection flNewProtect,
UInt32& lpflOldProtect)

let pVTable = getJit()
_pCompileMethod <- Marshal.ReadIntPtr(pVTable)

// make memory writable
let mutable oldProtection = uint32 0
if not <| VirtualProtect(
_pCompileMethod,
uint32 IntPtr.Size,
Protection.PAGE_EXECUTE_READWRITE,
&oldProtection)
then
Environment.Exit(-1)

let protection = Enum.Parse(
typeof<Protection>,
oldProtection.ToString()) :?> Protection

// save original compile method
_realCompileMethod <-
Some (Marshal.GetDelegateForFunctionPointer(
Marshal.ReadIntPtr(_pCompileMethod),
typeof<CompileMethodDeclaration>) :?> CompileMethodDeclaration
)
RuntimeHelpers.PrepareDelegate(_realCompileMethod.Value)
RuntimeHelpers.PrepareDelegate(_hookedCompileMethodDelegate)

// install compileMethod hook
Marshal.WriteIntPtr(
_pCompileMethod,
Marshal.GetFunctionPointerForDelegate(_hookedCompileMethodDelegate)
)

// repristinate memory protection flags
VirtualProtect(
_pCompileMethod,
uint32 IntPtr.Size,
protection,
&oldProtection
) |> ignore
------#------#------#------<END CODE>------#------#------#------

When we modify the MSIL code we must pay attention to the stack size. Our
framework needs some stack space in order to work and if the method that is
going to be compiled doesn't need any local variables, we will receive an
exception at runtime. In order to fix this problem it is enough to modify
the maxStack variable of CORINFO_METHOD_INFO structure before writing it
back.


--[ 4 - .NET Instrumentation

Now it is time to modify the MSIL buffer of our method of choice and
redirect the flow to our code. As we will see this is not a smooth process
and we need to take care of numerous aspects.


---[ 4.1 - MSIL injection strategy

In order to invoke our code the process that we will follow is composed of
the following steps:

1. Install a trampoline at the beginning of the code. This
trampoline will call a dynamically defined method.

2. Define a dynamic method that will have a specific method signature.

3. Construct an array of objects that will contain the parameters
passed to the method.

4. Invoke a dispatcher function which will load our Assembly
and will finally call our code by passing a handle to the original
method and an array of objects representing the method parameters.

In the end the structure that we are going to create will follow the path
defined in the following diagram:

| ... |
| ... | +---------------+
| Trampoline |----> | |
| Original MSIL | | Dynamic |
| ... | | Method |---------+
| ... | | | |
+---------------+ v
+---------------+
| |
| Framework |
| Dispatcher |
| |
+---------------+
|
+----------+
|
v
+---------------+
| |
| User |
| Code Monitor |
| |
+---------------+


---[ 4.2 - Resolving the method handle

As we will see in the next paragraph, it is necessary to resolve the handle
of the method that will be compiled in order to obtain the needed
information via reflection. I have found a method to resolve it, it is not
very elegant but it works :P.

The following F# pseudo-code will show you how to resolve a method handle
given the CorMethodInfo structure:

------#------#------#------<START CODE>------#------#------#------
let getMethodInfoFromModule(
methodInfo: CorMethodInfo,
assemblyModule: Module) =
let mutable info: FilteredMethod option = None
try
// dirty trick, is there a
// better way to know the module of the compiled method?
let mPtr =
assemblyModule.ModuleHandle.GetType()
.GetField("m_ptr",
BindingFlags.NonPublic ||| BindingFlags.Instance)
let mPtrValue = mPtr.GetValue(assemblyModule.ModuleHandle)
let mpData =
mPtrValue.GetType()
.GetField("m_pData",
BindingFlags.NonPublic ||| BindingFlags.Instance)

if mpData <> null then
let mpDataValue = mpData.GetValue(mPtrValue) :?> IntPtr
if mpDataValue = methodInfo.ModuleHandle then
// module found, get method name
let tokenNum =
Marshal.ReadInt16(nativeint(methodInfo.MethodHandle))
let token = (0x06000000 + int32 tokenNum)
let methodBase = assemblyModule.ResolveMethod(token)

if methodBase.DeclaringType <> null &&
isMonitoredMethod(methodBase) then
let mutable numOfParameters =
methodBase.GetParameters() |> Seq.length
if not methodBase.IsStatic then
// take into account the this parameter
numOfParameters <- numOfParameters + 1

// compose the result info
info <- Some {
TokenNum = tokenNum
NumOfArgumentsToPushInTheStack = numOfParameters
Method = methodBase
IsConstructor = methodBase :? ConstructorInfo
Filter = this
}
with _ -> ()
info
------#------#------#------<END CODE>------#------#------#------

This method must be invoked for each module of all loaded Assemblies.

Now that we have a MethodBase object, we can use it to extract the needed
information, like the number of accepted parameters and their types.


---[ 4.3 - Implementing a trampoline via the calli instruction

Our first obstacle is to create a MSIL bytecode that can invoke an
arbitrary function. Among all the available OpCodes, the one of interest
for us is the calli instruction [06] (beware of its usage, as it makes our
code unverifiable).

From the MSDN page we can read that:

"The method entry pointer is assumed to be a specific pointer to native
code (of the target machine) that can be legitimately called with the
arguments described by the calling convention (a metadata token for a
stand-alone signature). Such a pointer can be created using the Ldftn or
Ldvirtftn instructions, or passed in from native code."

Nice, we can specify an arbitrary pointer to native code. The only
difficulty is that we cannot use the Ldftn or Ldvirtftn since they need a
metadata token, and we cannot specify this value. Not too bad, since from
the Ldftn documentation we can read that [07]:

"Pushes an unmanaged pointer (type native int) to the native code
implementing a specific method onto the evaluation stack."

So, if we have an unmanaged pointer we can simulate the Ldftn with a simple
Ldc_I4 instruction (supposing that we are operating on a 32 bit
environment) [09].

Unfortunately now we have another, even bigger, problem. The calli
instruction needs a callSiteDescr. From [08] we can read that:

"<token> - referred to callSiteDescr - must be a valid StandAloneSig".

The StandAloneSig is the table number 17. As I have already said we cannot
specify this Metadata token (since it probably doesn't exist in the table).

I have played a bit with the calli instruction in order to see if it
accepts also other kinds of Metadata tokens. In the end I discovered that
it also accepts a token from one of the following tables: TypeSpec, Field
and MethodDef.

For our purpose, the MethodDef table is the most interesting one, since we
can fake a valid MethodDef token by creating a DynamicMethod (more on this
later). We can now close the circle by using the calli instruction and
modifying the metadata token in order to specify a MethodDef.

We will use the MethodBase object that we obtained in the previous step in
order to know how many parameters the method accepts and push them in the
stack before invoking calli.

The following F# pseudo-code shows how to build the calli instruction:

------#------#------#------<START CODE>------#------#------#------
// load all arguments on the stack
for i=0 to filteredMethod.NumOfArgumentsToPushInTheStack-1 do
ilGenerator.Emit(OpCodes.Ldarg, i)

// emit calli instruction with a pointer to the dynamic method,
// the token used by the calli is not important as I'll modify it soon
ilGenerator.Emit(OpCodes.Ldc_I4, functionAddress)
ilGenerator.EmitCalli(
OpCodes.Calli,
CallingConvention.StdCall,
dispatcherMethod.ReturnType,
dispatcherArgs)

// this index allow to modify the right byte
let patchOffset = ilGenerator.ILOffset - 4
ilGenerator.Emit(OpCodes.Nop)

// check if I have to pop the return value
match filteredMethod.Method with
| :? MethodInfo as mi ->
if mi.ReturnType <> typeof<System.Void> then
ilGenerator.Emit(OpCodes.Pop)
| _ -> ()

// end method
ilGenerator.Emit(OpCodes.Ret)
------#------#------#------<END CODE>------#------#------#------

The functionAddress variable contains the native pointer of our dynamic
method. One last step is to patch the calli Metadata token with a MethodDef
token whose value we know to be correct. As value we will use the token of
the method that it is being compiled.

The following F# pseudo-code show how to modify the MSIL bytecode at the
right offset:

------#------#------#------<START CODE>------#------#------#------
// craft MethodDef metadata token index
let b1 = (filteredMethod.TokenNum &&& int16 0xFF00) >>> 8
let b2 = filteredMethod.TokenNum &&& int16 0xFF

// calli instruction accept 0x11 as table index (StandAloneSig),
// but seems that also other tables are allowed.
// In particular the following ones seem to be accepted as
// valid: TypeSpec, Field and Method (most important)
trampolineMsil.[patchOffset] <- byte b2
trampolineMsil.[patchOffset+1] <- byte b1
trampolineMsil.[patchOffset + 3] <- 6uy // 6(0x6): MethodDef Table
------#------#------#------<END CODE>------#------#------#------

Since this step is a bit complex let's try to summarize our actions:

1. We use the calli instruction to invoke an arbitrary method by specifying
a native address pointer.

2. We modify the calli metadata token by specifying a MethodDef token and
not a StandAloneSig token.

3. We pass as Metadata token value the token of the method currently
compiled. This kind of token describes the method that must be called.

Our next step is to be sure that the method invoked by calli satisfies the
information contained in the referenced Metadata token.


---[ 4.4 - Crafting a dynamic method

We now have to create the dynamic method that satisfies the information
provided by the token passed to the calli instruction. From [10] we can
read that:

"The method descriptor is a metadata token that indicates the method to
call and the number, type, and order of the arguments that have been placed
on the stack to be passed to that method as well as the calling convention
to be used."

So, in order to create a method that satisfies the signature of the method
referenced by the token we will use a very powerful .NET capability, which
allows us to define dynamic method. This step allows the following:

1. Create a method that has the same signature of the method that will be
compiled. This will guarantee that the information carried by the
metadata token is legit.

2. We are now in a situation where we can specify a valid metadata
token, since the new dynamic type is created in the current execution
environment.

This dynamic method will call another method (a dispatcher) that accepts
two arguments: a string representing the location of the Assembly to load
(more on this later) and an array of objects which contains the arguments
passed to the method.

In creating this method you have to pay attention when creating the objects
array, since in .NET not everything is an object.

The following F# pseudo-code creates the dynamic method with the right
signature:

------#------#------#------<START CODE>------#------#------#------
let argumentTypes = [|
if not filteredMethod.Method.IsStatic then
yield typeof<Object>
yield!
filteredMethod.Method.GetParameters()
|> Array.map(fun p -> p.ParameterType)
|]

let dynamicType =
_dynamicModule.DefineType(
filteredMethod.Method.Name + "_Type" + string(!_index))
let dynamicMethod =
dynamicType.DefineMethod(
dynamicMethodName,
MethodAttributes.Static |||
MethodAttributes.HideBySig |||
MethodAttributes.Public,
CallingConventions.Standard,
typeof<System.Void>,
argumentTypes
)
------#------#------#------<END CODE>------#------#------#------

We can now proceed with the creation of the method body. We need to pay
attention to two facts: ValueType parameters must be boxed, and Enum
parameters must be converted to another form (after some trials and errors
I found that Int32 is a good compromise).

------#------#------#------<START CODE>------#------#------#------
// push the location of the Assembly to load containing the monitors
let assemblyLocation =
if filteredMethod.Filter.Invoker <> null
then filteredMethod.Filter.Invoker.Assembly.Location
else String.Empty
ilGenerator.Emit(OpCodes.Ldstr, assemblyLocation)

// get the parameter types
let parameters =
filteredMethod.Method.GetParameters()
|> Seq.map(fun pi -> pi.ParameterType)
|> Seq.toList

// create argv array
ilGenerator.Emit(OpCodes.Ldc_I4,
filteredMethod.NumOfArgumentsToPushInTheStack)
ilGenerator.Emit(OpCodes.Newarr, typeof<Object>)

// fill the argv array
for i=0 to filteredMethod.NumOfArgumentsToPushInTheStack-1 do
ilGenerator.Emit(OpCodes.Dup)
ilGenerator.Emit(OpCodes.Ldc_I4, i)
ilGenerator.Emit(OpCodes.Ldarg, i)

// check if I have to box the value
if filteredMethod.Method.IsStatic || i > 0 then
// this check is necessary becasue the
// GetParameters method doesn't consider the 'this' pointer
let paramIndex = if filteredMethod.Method.IsStatic then i else i - 1
if parameters.[paramIndex].IsEnum then
// consider all enum as Int32 type to avoid access problems
ilGenerator.Emit(OpCodes.Box, typeof<Int32>)

elif parameters.[paramIndex].IsValueType then
// all value types must be boxed
ilGenerator.Emit(OpCodes.Box, parameters.[paramIndex])

// store the element in the array
ilGenerator.Emit(OpCodes.Stelem_Ref)

// emit call to dispatchCallback
let dispatchCallbackMethod =
Type.GetType("ES.Anathema.Runtime.Dispatcher")
.GetMethod("dispatchCallback", BindingFlags.Static ||| BindingFlags.Public)
ilGenerator.EmitCall(OpCodes.Call, dispatchCallbackMethod, null)

ilGenerator.Emit(OpCodes.Ret)
------#------#------#------<END CODE>------#------#------#------

The call will end up invoking a framework method that is in charge for the
dispatch of the call to the user defined code.


---[ 4.5 - Invoking the user defined code

In order to make the code easy to extend, we can implement a mechanism that
will load a user defined Assembly and invoke a specific method. In this way
we have an architecture that resembles that of a plugin-based architecture.
We call these plugins: monitors. Each monitor can be configured in order to
intercept a specific method.

In order to locate the monitors we will use the software design paradigm
"convention over configuration", which implies that all classes whose name
ends in "Monitor" are loaded.

This last method is very simple, it just retrieves the MethodBase object
from the stack in order to pass it to the monitor and finally invoke it.
The assemblyLocation parameter is the one that specifies where the user
defined Assembly is located.

------#------#------#------<START CODE>------#------#------#------
let dispatchCallback(assemblyLocation: String, argv: Object array) =
if File.Exists(assemblyLocation) then
let callingMethod =
try
// retrieve the calling method from the stack trace
let stackTrace = new StackTrace()
let frames = stackTrace.GetFrames()
frames.[2].GetMethod()
with _ -> null

// invoke all the monitors, we use "convention over configuration"
let bytes = File.ReadAllBytes(assemblyLocation)
for t in Assembly.Load(bytes).GetTypes() do
try
if t.Name.EndsWith("Monitor") && not t.IsAbstract then
let monitorConstructor =
t.GetConstructor([|
typeof<MethodBase>;
typeof<Object array>|])
if monitorConstructor <> null then
monitorConstructor.Invoke([|callingMethod; argv|]) |> ignore
with _ -> ()
------#------#------#------<END CODE>------#------#------#------


---[ 4.6 - Fixing the SEH table

We are near the end, we have modified the MSIL bytecode, we have created a
dynamic method and a trampoline. The final step is to write back the
CORINFO_METHOD_INFO structure and call the real compileMethod.
Unfortunately by doing so you will soon receive a runtime error when you
try to instrument a method that uses a try/catch clause.

This is due to the fact that the creation of the trampoline has made the
SEH table invalid. This table contains information on the portions of code
that are inside try/catch clauses. From [11] we can see that by adding
additional MSIL code, the properties TryOffset and HandlerOffset will
assume an invalid value.

This table is located after the IL Code, as shown in the following
diagram:

+--------------------+
| |
| Fat Header |
| |
+--------------------+
| |
| |
| IL Code |
| |
| |
+--------------------+
| |
| SEH Table |
| |
+--------------------+

We also have a confirmation from the source code, in fact in corhlpr.cpp
([12]) we can see that the SEH table is added to the outBuff variable after
that was already filled with the IL code.

So, to get the address of the SEH table it is enough to add to the IlCode
pointer, located in the CorMethodInfo structure, the length of the MSIL
code.

Before showing the code that does that we have to take into account that
the SEH Table can be of two different types: FAT or SMALL. What changes is
only the dimensions of its fields. So fixing this table it is just a matter
of locating it and enumerating each clause to fix their values.

The following F# pseudo-code does exactly this:

------#------#------#------<START CODE>------#------#------#------
let fixEHClausesIfNecessary(
methodInfo: CorMethodInfo,
methodBase: MethodBase,
additionalCodeLength: Int32) =
let clauses = methodBase.GetMethodBody().ExceptionHandlingClauses
if clauses.Count > 0 then
// locate SEH table
let codeSizeAligned =
if (int32 methodInfo.IlCodeSize) % 4 = 0 then 0
else 4 - (int32 methodInfo.IlCodeSize) % 4
let mutable startEHClauses =
methodInfo.IlCode +
new IntPtr(int32 methodInfo.IlCodeSize + codeSizeAligned)

let kind = Marshal.ReadByte(startEHClauses)
// try to identify FAT header
let isFat = (int32 kind &&& 0x40) <> 0

// it is always plus 3 because even if it is small it is
// padded with two bytes. See: Expert .NET 2.0 IL Assembler p. 296
startEHClauses <- startEHClauses + new IntPtr(4)

for i=0 to clauses.Count-1 do
if isFat then
let ehFatClausePointer =
box(startEHClauses.ToPointer())
 :?> nativeptr<CorILMethodSectEhFat>
let mutable ehFatClause = NativePtr.read(ehFatClausePointer)

// modify the offset value
ehFatClause.HandlerOffset <-
ehFatClause.HandlerOffset + uint32 additionalCodeLength
ehFatClause.TryOffset <-
ehFatClause.TryOffset + uint32 additionalCodeLength

// write back the result
let mutable oldProtection = uint32 0
let memSize = Marshal.SizeOf(typeof<CorILMethodSectEhFat>)
if not <| VirtualProtect(
startEHClauses,
uint32 memSize,
Protection.PAGE_READWRITE,
&oldProtection) then
Environment.Exit(-1)

let protection = Enum.Parse(
typeof<Protection>,
oldProtection.ToString()) :?> Protection
NativePtr.write ehFatClausePointer ehFatClause

// repristinate memory protection flags
VirtualProtect(
startEHClauses,
uint32 memSize,
protection,
&oldProtection) |> ignore

// go to next clause
startEHClauses <- startEHClauses + new IntPtr(memSize)
else
//... do same as above but for small size table
------#------#------#------<END CODE>------#------#------#------

Once we have fixed this table we can finally invoke the real compileMethod.


--[ 5 - Real world examples

The code presented is part of a project called Anathema that will allow you
to easily instrument .NET programs. Let's try to use the framework by
instrumenting a web application in order to steal the user passwords and to
instrument a real world malware in order to log all method calls.


---[ 5.1 - Web application password stealer

Let's see how we can use this instrumentation method in order to implement
a password stealer for a web application. For our demo we will use a very
popular .NET web server called Suave ([13]). We will write the web
application in F# and the password stealer as a C# console application, in
this way we can instrument the interesting method before it is compiled. In
the other case we have to force the .NET runtime to recompile the method in
order to apply the instrumentation (see [14] for a possible approach).

The web application is very simple and contains only a form; its HTML code
is shown below:

------#------#------#------<START CODE>------#------#------#------
<h1>-= Secure Web Shop Login =-</h1>
<form method="POST" action="/login">
<table>
<tr>
<td>Username:</td>
<td><input type="text" name="username"></td>
</tr>
<tr>
<td>Password:</td>
<td><input type="password" name="password"></td>
</tr>
<tr>
<td></td>
<td><input type="submit" name="Login"></td>
</tr>
</table>
</form>
------#------#------#------<END CODE>------#------#------#------

The F# code in charge for the authentication is the following:

------#------#------#------<START CODE>------#------#------#------
let private _accounts = [
("admin", BCrypt.HashPassword("admin"))
("guest", BCrypt.HashPassword("guest"))
]

let private authenticate(username: String, password: String) =
_accounts
|> List.exists(fun (user, hash) ->
let usernameMatch = user.Equals(username, StringComparison.Ordinal)
let passwordMatch = BCrypt.Verify(password, hash)
usernameMatch && passwordMatch
)

let private doLogin(ctx: HttpContext) =
match (tryGetParameter(ctx, "username"), tryGetParameter(ctx, "password")) with
| (Some username, Some password) when authenticate(username, password) ->
OK "Authentication successfully executed!" ctx
| _ -> OK "Wrong username/password combination" ctx
------#------#------#------<END CODE>------#------#------#------

So, the best way to intercept passwords is the 'authenticate' method. We
will start by creating a class in charge of printing the received password,
this is done by creating the following simple class:

------#------#------#------<START CODE>------#------#------#------
class PasswordStealerMonitor
{
public PasswordStealerMonitor(MethodBase m, object[] args)
{
Console.WriteLine(
"[!] Username: '{0}', Password: '{1}'",
args[0],
args[1]);
}
}
------#------#------#------<END CODE>------#------#------#------

Now, the final step is to instrument the application, this is done using
the following code:

------#------#------#------<START CODE>------#------#------#------
// create runtime
var runtime = new RuntimeDispatcher();
var hook = new Hook(runtime.CompileMethod);
var authenticateMethod = GetAuthenticateMethod();
runtime.AddFilter(
typeof(PasswordStealerMonitor),
"SecureWebShop.Program.authenticate");

// apply hook
var jitHook = new JitHook();
jitHook.InstallHook(hook);
jitHook.Start();

// start the real web application
SecureWebShop.Program.main(new String[] { });
------#------#------#------<END CODE>------#------#------#------

Once the web application is run and we try to login, we will see the
following output in the console:

-= Secure Web Shop =-
Start web server on 127.0.0.1:8080
[14:45:49 INF] Smooth! Suave listener started in 631.728 with binding 127.0.0.1:8080
[!] Username: 's4tan', Password: 'wrong_password'
[!] Username: 'admin', Password: 'admin'


---[ 5.2 - Malware inspection

Let's consider a sample of the Hawkeye malware, written in .NET, with the
following MD5 hash: 130efba199b389ab71a374bf95be2304.

The sample contains two levels of packing. We could trace the packers but
let's focus on the main payload (MD5: 97d74c20f5d148ed68e45dad0122d3b5).
When the main payload is launched the following method calls are logged:

c:\>MLogger.exe malware.exe
[+] Debugger.My.MyApplication.Main(Args: System.String[]) : System.Void
[+] Debugger.My.MyProject..cctor()
[...]
[+] Debugger.My.MyProject.get_Application() : Debugger.My.MyApplication
[+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T
[+] Debugger.My.MyApplication..ctor()
[+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T
[+] Debugger.My.MyProject+MyForms..ctor()
[+] Debugger.Debugger..ctor()
[+] Debugger.Clipboard..ctor()
[+] Debugger.Clipboard.add_Changed(obj: Debugger.Clipboard+ChangedEventHandler)
 : System.Void
[+] Debugger.My.Resources.Resources.get_CMemoryExecute() : System.Byte[]
[+] Debugger.My.Resources.Resources.get_ResourceManager() :
System.Resources.ResourceManager
[+] Debugger.Debugger.InitializeComponent() : System.Void
[+] Debugger.Debugger.Decrypt(
encryptedBytes: System.String, secretKey: System.String) : System.String
[+] Debugger.Debugger.getAlgorithm(secretKey: System.String) :
System.Security.Cryptography.RijndaelManaged
[+] Debugger.Debugger.Decrypt(
encryptedBytes: System.String, secretKey: System.String) : System.String
[+] Debugger.Debugger.getAlgorithm(secretKey: System.String) :
System.Security.Cryptography.RijndaelManaged
[+] Debugger.Debugger.Decrypt(
encryptedBytes: System.String, secretKey: System.String) : System.String
[+] Debugger.Debugger.getAlgorithm(secretKey: System.String) :
System.Security.Cryptography.RijndaelManaged
[...]
[+] Debugger.Debugger.IsConnectedToInternet() : System.Boolean
[+] Debugger.Debugger.GetInternalIP() : System.String
[+] Debugger.Debugger.GetExternalIP() : System.String
[+] Debugger.Debugger.GetBetween(
Source: System.String, Before: System.String, After: System.String) : System.String
[+] Debugger.Debugger.GetAntiVirus() : System.String
[+] Debugger.Debugger.GetFirewall() : System.String
[+] Debugger.Debugger.unHide() : System.Void
[+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T
[+] Debugger.My.MyComputer..ctor()
[+] Debugger.Debugger.unhidden(path: System.String) : System.Void
[...]
[+] Debugger.My.Resources.Resources.get_mailpv() : System.Byte[]
[+] Debugger.My.Resources.Resources.get_ResourceManager() :
System.Resources.ResourceManager
[+] Debugger.Debugger.HookKeyboard() : System.Void
[+] Debugger.Clipboard.Install() : System.Void
[+] Debugger.My.MyProject+ThreadSafeObjectProvider`1.get_GetInstance() : T
[+] Debugger.My.MyComputer..ctor()
[+] Debugger.Debugger.IsConnectedToInternet() : System.Boolean
[+] Debugger.Debugger.IsConnectedToInternet() : System.Boolean
[+] Debugger.My.MyProject.get_Computer() : Debugger.My.MyComputer
[...]


--[ 6 - Conclusion

Instrumenting a .NET program via MSIL bytecode injection is a pretty useful
technique that allows you to have full control of method invocation by
using a high level .NET language.

As we have seen, doing so requires a lot of attention and knowledge of the
internal workings of the CLR, but in the end the outcome is worth the
trouble.


--[ 7 - References

[01] Metadata and Self-Describing Components - https://goo.gl/bbSG7p
[02] The .NET File Format - http://www.ntcore.com/files/dotnetformat.htm
[03] Standard ECMA-335 - https://goo.gl/J9kko6
[04] corjit.h - https://goo.gl/J68Poi
[05] corinfo.h - https://goo.gl/G31KHP
[06] OpCodes.Calli Field - https://goo.gl/D7ug93
[07] OpCodes.Ldftn Field - https://goo.gl/sHzz1S
[08] Expert .NET 2.0 IL Assembler - https://goo.gl/3LKLSW
[09] OpCodes.Ldc_I4 Field - https://goo.gl/qEW2Lx
[10] OpCodes.Call Field - https://goo.gl/29rqZk
[11] ExceptionHandlingClause Class - https://goo.gl/bjLqSv
[12] corhlpr.cpp - https://goo.gl/DDVKgH
[13] Suave web server - https://suave.io/
[14] .NET CLR Injection - https://goo.gl/nryxYB
Also listed in: .NET Code Injection Tools, .NET Tracers, Reverse Engineering Frameworks
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Anti Olly Tester
Rating: 0.0 (0 votes)
Author: Shub-nigurrath                        
Website: http://arteam.accessroot.com/releases/
Current version: 1.0
Last updated: August 25, 2006
Direct D/L link: Locally archived copy
License type: Free
Description: This little program is more a POC than a friendly program. It's based on an idea Gabri3l discussed once, to test the environment in which the program is going to run and adapt itself to the conditions it finds.
Well this program is a set of tests performed on the processes running on the system. They are performed on several tools using blacklists but there's a special attention paid to OllyDbg.

Detects Debugging programs through different methods all connected to the execution environment.

* Method 1: see if one of the currently running processes' Windows name is blacklisted or not
* Method 2: Collects the ClassName of each of the active windows and check if it is blacklisted
* Method 3: tests the processes paths and see if it is blacklisted
* Method 4: tests modules (dll) loaded by any active process to see if any is a known plugin or matches a blacklistof process and words
* Method 5: Opens the install folder where the program is running from and see if any of the files inside that folder has oneblacklisted word
* Method 6: test export directory of the running processes, if there's something connected with Olly.
* Method 7: test VERSION_INFO resource of the running processes to check if any matches a blacklist
* Method 8: test all the other resources (dialog, menus, bitmaps and so on) of the running processes to check if any contains blacklisted words (either UNICODE or ASCII)

The blacklists are taken from SDProtector and are generic enough to include almost all known RCE tool around.

The result is really interesting and the resulting check is very difficult to overcome: It's very difficult to hide Olly to this type of tests.

The final code is very small, even if written using C. Moreover consider that each test might be performed by parallel recurrent threads and decrypted/encrypted just before and after execution. An exe protected like this might easily become a nightmare, without having a to write a single ASM trick.

Note that this same test is inside the distribution 1.2 of xADT into the test "Find Complex".
Also listed in: Anti Debug Test Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Boomerang
Rating: 3.0 (1 vote)
Author: The Boomerang Decompiler Project                        
Website: http://boomerang.sourceforge.net/
Current version: 0.3.1
Last updated: 2006
Direct D/L link: N/A
License type: Free / Open Source
Description: A general, open source, retargetable decompiler of machine code programs.

This project is an attempt to develop a real decompiler for machine code programs through the open source community. A decompiler takes as input an executable file, and attempts to create a high level, compilable, possibly even maintainable source file that does the same thing. It is therefore the opposite of a compiler, which takes a source file and makes an executable. However, a general decompiler does not attempt to reverse every action of the decompiler, rather it transforms the input program repeatedly until the result is high level source code. It therefore won't recreate the original source file, probably nothing like it. It does not matter if the executable file has symbols or not, or was compiled from any particular language. (However, declarative languages like ML are not considered.)

The intent is to create a retargetable decompiler (i.e. one that can decompile different types of machine code files with modest effort, e.g. X86-windows, sparc-solaris, etc). It was also intended to be highly modular, so that different parts of the decompiler can be replaced with experimental modules. It was intended to eventually become interactive, a la IDA Pro, because some things (not just variable names and comments, though these are obviously very important) require expert intervention. Whether the interactivity belongs in the decompiler or in a separate tool remains unclear.

By transforming the semantics of individual instructions, and using powerful techniques such as Static Single Assignment dataflow analysis, Boomerang should be (largely) independent of the exact behaviour of the compiler that happened to be used. Optimisation should not affect the results. Hence, the goal is a general decompiler.
Also listed in: Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: CFSearch
Rating: 0.0 (0 votes)
Author: Sirmabus                        
Website: http://www.woodmann.com/forum/showthread.php?t=11306&page=2
Current version: 1.0A
Last updated: February 15, 2008
Direct D/L link: N/A
License type: Free
Description: Extremely cool tracer tool that makes use of the "single step on branch", LBR ("last branch recording") features of current processors.

Not released yet, but we're awaiting it with great anticipation!
Also listed in: Tracers, Code Coverage Tools, Profiler Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: CHook
Rating: 0.0 (0 votes)
Author: Darawk                        
Website: N/A
Current version:
Last updated: October 16, 2005
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: This is my hooking library that performs a variety of different types of hooks:

- IAT hooking
- EAT hooking
- Debug register hooking
- Thread-safe jmp patch hooking using a length-disassembler engine and a code thunk that masks the problem of jumping back to the original function.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Coddec
Rating: 0.0 (0 votes)
Author: Dr Bolsen                        
Website: http://drbolsen.wordpress.com/2008/07/14/coddec-released
Current version:
Last updated: April 7, 2009
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: Decompiler for Blackberry executables (COD files), includes source.
Also listed in: BlackBerry Tools, Mobile Platform Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Code Snippet Creator (Iczelion)
Rating: 0.0 (0 votes)
Author: Iczelion                        
Website: N/A
Current version: 1.05 (build 2)
Last updated: January 13, 2001
Direct D/L link: Locally archived copy
License type: Free
Description: Code Snippet Creator is designed specifically for advanced crackers/assembly programmers who want to create custom code snippets in assembly language.

The features of this utility:
· Can generate code snippets and save them as binary files
· Support both TASM and MASM
· Provide simple integrated PE editor to edit the target file you want to patch
· Can patch the code snippet into a target PE file both as a new section and as an addition to an existing section (or PE header)
· You can use ANY functions that the target imports in your snippet! This utility will fix the calls for you.
Also listed in: Code Injection Tools, Code Snippet Creators
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Codename ASLAN (4514N)
Rating: 0.0 (0 votes)
Author: Piotr Bania                        
Website: http://www.piotrbania.com/all/4514N/
Current version: (not yet released)
Last updated:
Direct D/L link: N/A
License type: Free
Description: I'm currently working on my masterpiece project (school project), a first gui oriented and the most advanced integrating-metamorphic engine so far. Integration engine allows user to integrate any code to any PE binary file (x86 processors), including device drivers etc. etc. 4514N engine can rebuild all the PE
structure, internal offsets (jumps,refferences), any type of PE sections relocs, imports, exports, resources...), moreover it even can keep the align of variables.

Integration means that firstly target file is disassembled to pieces (it creates a chain which connects the body of target file), then we move that chain, we do everything we want (i call this step InverseKinematics, just because i'm an 3d graphics hobbyst) and then we compile the chain again. Such horrible modified application runs perfectly, moreover it is almost impossible to disinfect the modified target. So tell me, do you want to compile a rootkit inside of yours ndis.sys? :)

I don't want to speak much about the metamorphic engine since it is not 100% ready yet. But the main thing you should know it is mostly based on the emulation process (and as far as i know it is the first metamorphic engine which does so), and many of the muation states are based on the Automaton Theory (which inspired me a lot). Lets consider the rest of the features as an future surprise :)
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Comrade's PE Tools
Rating: 0.0 (0 votes)
Author: Comrade                        
Website: http://comrade.ownz.com/projects/petools.html
Current version:
Last updated: July 31, 2008
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: * Inject Tool

Inject is a tool that injects a DLL into a running process. Its command-line usage is as follows:

1. Inject C:\hook.dll into pid 1234: inject.exe 1234 C:\hook.dll
2. Inject C:\hook.dll into process notepad.exe (if multiple notepads are running, then whichever one is picked is undefined): inject.exe -p *notepad.exe C:\hook.dll
3. Inject C:\hook.dll into running process C:\myprogram.exe: inject.exe -p C:\myprogram.exe C:\hook.dll
4. Inject C:\hook.dll into process with a window named "Untitled - Notepad": inject.exe -w "Untitled - Notepad" C:\hook.dll
5. Inject C:\hook.dll into process with a window class Notepad: inject.exe -c Notepad C:\hook.dll

Note that in all uses, you should specify the full path to the injected DLL.


* Loader Tool

Loader is a tool that injects a DLL before launching a process. Its command-line usage is as follows:

1. Load notepad.exe and inject C:\hook.dll into it: loader.exe notepad.exe C:\hook.dll

Note that you should specify the full path to the injected DLL.


* Patch Tool

Patch is a tool that adds a new section to the executable. The new section becomes the new entrypoint, and contains code to load a particular DLL, and then jump back to the original entrypoint. This can be used to create static patches that behave similar to the Loader tool.
The tool's command-line usage is as follows:

1. Patch original.exe to load C:\hook.dll before execution; save the patched executable to patched.exe: patch.exe original.exe patched.exe C:\hook.dll


* Reimport Tool

Reimport is a tool that redirects certain entries of an executable's import table to another DLL. For example, running reimport.exe game.exe newgame.exe nocd.dll kernel32.dll::GetDriveTypeA kernel32.dll::CreateFileA kernel32.dll::GetVolumeInformation will create a copy of game.exe into newgame.exe, with the above 3 API functions rerouted to nocd.dll, instead of kernel32.dll. That means newgame.exe would import GetDriveTypeA, CreateFileA, and GetVolumeInformation from nocd.dll instead of kernel32.dll.
Also listed in: Code Injection Tools, Import Editors, PE Executable Editors
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Conditional Branch Logger
Rating: 0.0 (0 votes)
Author: Blabberer / dELTA / Kayaker                        
Website: N/A
Current version: 1.0
Last updated: June 13, 2007
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: Conditional Branch Logger is a plugin which gives control and logging capabilities for conditional branch instructions over the full user address space of a process. Useful for execution path analysis and finding differences in code flow as a result of changing inputs or conditions. It is also possible to log conditional jumps in system dlls before the Entry Point of the target is reached. Numerous options are available for fine tuning the logging ranges and manipulating breakpoints.
Also listed in: Code Coverage Tools, OllyDbg Extensions, Profiler Tools, Tracers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DE Decompiler
Rating: 0.0 (0 votes)
Author: GPcH Soft                        
Website: http://www.de-decompiler.com
Current version: 2.0 (updated)
Last updated: July 18, 2008
Direct D/L link: Locally archived copy
License type: Commercial (with demo)
Description: DE Decompiler is the unique solution for decompiling the Delphi generated programs (EXE, DLL, OCX). As you know the Delphi programs is the native win32 executable files.

DE Decompiler restores most parts of the compiled code and helps you to recover most parts of the lost sources. It contans the powerful disassembler which supports Pentium Pro commands including MMX and SSE extensions. Also it has a useful smart assembler code emulation engine. The build-in disassembler allows you to disassemble a lots of functions and represents it in semi-decompiled mode. DE Decompiler has a wonderful code analyzer which makes your work easy and fast. In addition to all it can search for all the API function's calls and the string references in the disassembled code and comment them out for analyzed strings.

If you lost your source codes - DE Decompiler save your time and helps you to restore it.

In general, DE Decompiler is the ideal tool for analyzing programs and it is perfect if you lose your source code and need to partially restore the project.
Also listed in: Decompilers, Delphi Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DLL Injection Framework
Rating: 5.0 (1 vote)
Author: Admiral                        
Website: http://www.ring3circus.com/downloads/dll-injection-framework
Current version: 1.0
Last updated: December 20, 2007
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: The process of remote function hooking via a DLL is notoriously messy, so I’ve tried to encapsulate as much of the mess as possible into a C++ class. Here’s an example of some client code that injects a DLL into Windows Calculator, then installs two hooks (one by name and another by address):

-----------------------------------------------------------------
// Create the injection object
DLLInjection injection("E:/Temp/HookDLL.dll");

// Find Calc.exe by its window
DWORD process_id = injection.GetProcessIDFromWindow(
"SciCalc",
"Calculator");

// Inject the DLL
HMODULE remote_module = injection.InjectDLL(process_id);

// Hook a DLL function (User32!SetWindowTextW)
HDLLHOOK swtw_hook = injection.InstallDLLHook(
"C:/Windows/System32/User32.dll",
"SetWindowTextW",
"SetWindowTextHookW");

// Hook a function manually (Calc!0100F3CF)
HDLLHOOK manual_hook = injection.InstallCodeHook(
reinterpret_cast (0×0100F3CF),
“SomeOtherHook”);

// Remove the hooks
injection.RemoveHook(swtw_hook);
injection.RemoveHook(manual_hook);
-----------------------------------------------------------------

Testing has been limited so don’t be surprised to find bugs. If you do find any, please report them.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Desquirr - Decompiler Plugin for IDA Pro
Rating: 0.0 (0 votes)
Author: David Eriksson                        
Website: http://desquirr.sourceforge.net/desquirr/
Current version: 20070130 (desquirr-20070130-bin-ida_v5_0.zip)
Last updated: November 13, 2003
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: Desquirr is a decompiler plugin for IDA Pro.

Desquirr currently consists of a little more than 5000 lines of C++ code, not counting empty lines or lines beginning with comments

Read the Master Thesis at http://desquirr.sourceforge.net/desquirr/desquirr_master_thesis.pdf
Also listed in: IDA Extensions, Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DetourXS
Rating: 0.0 (0 votes)
Author: Sinner                        
Website: http://forum.gamedeception.net/showthread.php?t=10649
Current version: 1.0
Last updated: June 16, 2007
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: DetourXS is a library for function detouring.

Example usage code:

---------------------------------------------------------
#include <detourxs.h>

typedef DWORD (WINAPI* tGetTickCount)(void);
tGetTickCount oGetTickCount;

DWORD WINAPI hGetTickCount(void)
{
printf("GetTickCount hooked!");
return oGetTickCount();
}

// To create the detour
oGetTickCount = (tGetTickCount) DetourCreate("kernel32.dll", "GetTickCount", hGetTickCount, DETOUR_TYPE_JMP);

// ...Or an address
oGetTickCount = (tGetTickCount) DetourCreate(0x00000000, hGetTickCount, DETOUR_TYPE_JMP);

// ...You can also specify the detour len
oGetTickCount = (tGetTickCount) DetourCreate(0x00000000, hGetTickCount, DETOUR_TYPE_JMP, 5);

// To remove the detour
DetourRemove(oGetTickCount);
---------------------------------------------------------
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DevPartner Studio
Rating: 2.0 (1 vote)
Author: Compuware                        
Website: http://www.compuware.com/products/devpartner/studio.htm
Current version: 8.2
Last updated:
Direct D/L link: N/A
License type: Commercial (with trial)
Description: This tool does reportedly not work at all without having the source code for the analyzed program, which sadly makes it relatively useless for reversing purposes.

See the following for more info:
http://www.woodmann.com/forum/showthread.php?t=11306

-----------------------------

Performance Analysis:
---------------------

DevPartner Studio performance analysis takes you where few profiling tools can go, to the individual line of source code to identify and analyze slow code and performance bottlenecks line by line. Using DevPartner Studio performance profiling, you can:

* profile Visual C++, Visual Basic, .NET, C#, VBScript and JScript code from top to bottom
* trace running applications and differentiate between application and operating system calls, all through an intuitive user interface
* isolate performance bottlenecks in single and multi-tiered applications at machine, process, component or source line levels
* receive recommendations and corrective actions from one key source—DevPartner Studio.


Code Coverage Analysis:
-----------------------

No more relying on relatively subjective reports to test code. DevPartner Studio Professional Edition code coverage analysis tells you how much code was tested, how well it tested and what was never tested at all. You get the answers you need to focus testing where it's needed most, whether it's code check-in, unit testing, integration testing or final release. To zero-in on untested code for you, DevPartner Studio:

* captures and combines testing sessions for applications, components and web pages
* traces both .NET and native code across users, languages and application tiers
* pinpoints the portions of an application left unexecuted during one or more tests
* merges sessions to present a clear picture of testing progress over time.
Also listed in: Profiler Tools, Code Coverage Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Direct3D Hooking
Rating: 5.0 (1 vote)
Author: Admiral                        
Website: http://www.ring3circus.com/downloads/direct3d-hooking
Current version: 1.1
Last updated: November 27, 2007
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: A sample for hooking a Direct3D 9 program and drawing on its viewport. Translating this to Direct3D 8 should be trivial.

Notes:

* Vista support added with version 1.1
* This is not safe for 64-bit consumption, though that should be obvious.
* While there’s no reason it can’t be made to work with Unicode, I’ve written everything in ASCII, for simplicity.
* By default, the DLL will increase its own reference count to prevent it being unloaded prior to termination of the host process. This is because there is a small risk of the DLL being unloaded by one thread, while a hooked function in another returns to the now dead memory. I figured that it’s best to waste a little bit of everybody’s memory than to crash unnecessarily.
* The d3d9.dll function addresses (and prologues) are hard-coded, or at least their offsets are. While this may look very unprofessional and rather risky, I can assure you that it’s quite safe. The alternative would be to hack up some virtual-function tables and that’s a whole other story for a whole other post.
* You may notice that the compiled DLL is dependent upon D3DX. This isn’t necessary for the hook itself, but I used ID3DXFont in my example for demonstrative purposes. The only reason I mention this is that there is no way to guarantee the existence of any D3DX DLLs on a DirectX 9 machine, and distributing them yourself is in violation of the DirectX Runtime EULA. So if you happen to need to distribute this code, you’ll either need to carry the huge runtime installer around, or avoid using D3DX altogether.
* The soft-hooks used here will cause problems with PunkBuster if applied to any of its monitored functions. If you need to do this then you’ll have to be a bit cleverer.
* The source assumes that the graphics device will never become invalid. If you suspect that this isn’t the case (which will be true for any full-screen game at a minimum) then you’ll need to add the appropriate sanity checks (see IDirect3DDevice9::TestCooperativeLevel) before attempting to render anything, lest you want to crash and burn.
Also listed in: DirectX Tools, Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DoDi's Visual Basic 3/4 Decompiler
Rating: 0.0 (0 votes)
Author: Dr. H.-P. Diettrich                        
Website: http://vbdis4.angelfire.com/
Current version: 3.67e *reloaded*
Last updated: December 1, 2008
Direct D/L link: http://vbdis4.angelfire.com/VBDIS3.67e_Reloaded_Rev3_DoDi_s_VB3Decompiler.7z
License type: Abandonware
Description: Attention the original program is anno 1997.
However it's the best VB3 decompiler out there.

Decompiled & recompile with VB6.
^- So it will also run on systems new than windows XP that don't have any win3.11 16-bit support(or emulator) on board

Features:
* beside the sourcecode
* some bugfixed and decompiling improvement
* support for decompiling 'VBGuard-protected' VB3-Apps
Also listed in: Visual Basic Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DotNetasploit
Rating: 0.0 (0 votes)
Author: Jon McCoy                        
Website: http://digitalbodyguard.com/DotNetasploit.html
Current version: 2.5
Last updated: August 2010
Direct D/L link: Locally archived copy
License type: Free
Description: DotNetasploit is a very capable code injector, making it possible to inject and edit code and GUI controls into .NET applications in an interactive fashion.
Also listed in: .NET Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: dotPeek
Rating: 0.0 (0 votes)
Author: Jetbrains                        
Website: http://www.jetbrains.com/decompiler/
Current version: 1.4
Last updated: April 8, 2015
Direct D/L link: http://download.jetbrains.com/resharper/dotPeek32_1.4.exe
License type: Free
Description: A free replacement of Reflector

- Decompiling .NET 1.0-4.5 assemblies to C#
- Support for .dll, .exe, .zip, .vsix, .nupkg, and .winmd files
- Quick jump to a type, assembly, symbol, or type member
- Effortless navigation to symbol declarations, implementations, derived and base symbols, and more
- Accurate search for symbol usages with advanced presentation of search results
- Overview of inheritance chains
- Support for downloading code from source servers
- Syntax highlighting
- Complete keyboard support
Also listed in: .NET Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: DynamoRIO
Rating: 0.0 (0 votes)
Author: Hewlett-Packard Laboratories & MIT & Derek Bruening                        
Website: http://dynamorio.org
Current version: 6.0.0.6
Last updated: October 6, 2015
Direct D/L link: https://github.com/DynamoRIO/dynamorio/releases/download/release_6_0_0/DynamoRIO-Windows-6.0.0-6.zip
License type: Free and open source (BSD-type license)
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.
DynamoRIO's powerful API abstracts away the details of the underlying infrastructure and allows the tool builder to concentrate on analyzing or modifying the application's runtime code stream. API documentation is included in the release package and can also be browsed online.

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, Debugger Libraries, 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: ERESI Framework
Rating: 0.0 (0 votes)
Author: The ERESI Project                        
Website: http://www.eresi-project.org
Current version: 0.82b2
Last updated: September 13, 2009
Direct D/L link: N/A
License type: Free / Open Source
Description: The ERESI Reverse Engineering Software Interface is a unified multi-architecture binary analysis framework targeting operating systems based on the Executable & Linking Format (ELF) such as Linux, *BSD, Solaris, HP-UX, IRIX and BeOS.

ERESI is a general purpose hybrid framework : it includes both static analysis and runtime analysis capabilities. These features are accessed by primitives of the ERESI reverse engineering language which makes the framework more adaptable to the precise needs of her users. It brings an environment of choice for program analysis throught instrumentation, debugging, and tracing as it also provides more than ten exclusive major built-in features . ERESI can also be used for security auditing, hooking, integrity checking or logging binary programs. The project prones modularity and reusability of code and allows users to create their own project on top of the ERESI language interpreter in just a few lines. Among other features, the base code can display program graphs on demand using its automated flow analysis primitives. Our tools are enhanced for hardened or raw systems which have no executable data segments and no native debug API or even explicit program information.

The ERESI framework includes:

* The ELF shell (elfsh), an interactive and scriptable ERESI interpreter dedicated to instrumentation of ELF binary files.
* The Embedded ELF debugger (e2dbg), an interactive and scriptable high-performance userland debugger that works without standard debug API (namely without ptrace).
* The Embedded ELF tracer (etrace), an interactive and scriptable userland tracer that works at full frequency of execution without generating traps.
* The Kernel shell (kernsh), an interactive and scriptable userland ERESI interpreter to inject code and data in the OS kernel, but also infer, inspect and modify kernel structures directly in the ERESI language.
* The Evarista static analyzer, a work in progress ERESI interpreter for program transformation and data-flow analysis of binary programs directly implemented in the ERESI language (no web page yet).

Beside those top-level components, the ERESI framework contains various libraries that can be used from one of the previously mentioned tools, or in a standalone third-party program:

* libelfsh : the binary manipulation library on which ELFsh, E2dbg, and Etrace are based.
* libe2dbg : the embedded debugger library which operates from inside the debuggee program.
* libasm : the disassembly engine (x86 and sparc) that gives semantic attributes to instructions and operands.
* libmjollnir : the code fingerprinting and graph manipulation library.
* librevm : the Reverse Engineering Vector Machine, that contains the meta-language interpretor and the standard ERESI library.
* libaspect : the type system and aspect library. It can define complex data-types to be manipulated ad-hoc by ERESI programs.
* libedfmt : the ERESI debug format library which can convert dwarf and stabs debug formats to the ERESI debug format by automatically generating new ERESI types.
Also listed in: Code Injection Tools, Linux Debuggers, Linux Disassemblers, Reverse Engineering Frameworks, Tracers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: ExeToC Decompiler
Rating: 0.0 (0 votes)
Author: bookaa                        
Website: http://sourceforge.net/projects/exetoc/
Current version:
Last updated: May 23, 2005
Direct D/L link: N/A
License type: Free / Open Source
Description: Decompile win32 programs and DLLs to C++ step by step. Allows some interactivity. Main functions already work:

* Supports if/else/for/do/while/break/switch case/continue
* Supports API
* Supports C++ head file load
* Supports standard library function recognize.
Also listed in: Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: FastSystemCallHook
Rating: 0.0 (0 votes)
Author: Darawk                        
Website: N/A
Current version:
Last updated: April 5, 2008
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: A snippet of code which is a KiFastSystemCall hook I wrote that hooks all user-mode APIs by replacing the SYSENTER MSR. It works also on multi-processor systems and should be easy to extend into a fully functional library if you want to.
Also listed in: API Monitoring Tools, Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Frida
Rating: 0.0 (0 votes)
Author: Ole André Vadla Ravnås (@fridadotre)                        
Website: https://www.frida.re/
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.

Scriptable

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!


Stalking

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


Portable

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, Non-Intrusive Debuggers, 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: Hex-Rays
Rating: 5.0 (3 votes)
Author: Hex-Rays sprl (Ilfak Guilfanov)                        
Website: http://www.hex-rays.com
Current version: 1.0
Last updated: September 17, 2007
Direct D/L link: N/A
License type: Commercial (IDA Pro plugin)
Description: Hex-Rays is created by Ilfak Guilfanov, famous author of IDA Pro. It is a commercial IDA Pro plugin, and aims to be the best decompiler ever created.
Also listed in: Decompilers, IDA Extensions
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: HookLib
Rating: 0.0 (0 votes)
Author: Nektra                        
Website: http://www.nektra.com/products/deviare/hooklib/
Current version: 1.0
Last updated:
Direct D/L link: http://www.nektra.com/products/deviare/hooklib/hooklib.exe
License type: LGPL
Description: Nektra's hook engine used in Deviare.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Hotch
Rating: 0.0 (0 votes)
Author: sp                        
Website: http://www.the-interweb.com/serendipity/index.php?/archives/108-Hotch-1.0.0.html
Current version: 1.0.0
Last updated: July 10, 2008
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: Hotch - named after everyone's favourite TV profiler - is an IDA plugin that can be used to profile binary files. It sets breakpoints on all basic blocks of a program, records breakpoints hits and tries to figure out statistics from these hits. Click here to seen an example of a simple profiling session (starting Notepad and exiting Notepad again). Click here to see a huge 6.5 MB results file that shows a larger profiling session (loading a file in Notepad and playing around in it).

Random Notes:

* "This is really slow for larger files". Yeah, it is really slow in IDA up to 5.2 but Ilfak fixed some things in IDA 5.3 and it works acceptably fast now. So patience, young padawan.
* "The timing results don't really make sense". Yeah, I know. Since I execute a callback function after each breakpoint hit tight loops take disproportionally much time. For anything but tight loops the timing results should kinda work, at least relative to each other of course.
* Ignore the source file libida.hpp, it's an early version of my experimental-at-best C++ wrapper library for the IDA SDK.
* I take feature requests for Hotch.
Also listed in: Code Coverage Tools, IDA Extensions, Profiler Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: IDA Inject
Rating: 0.0 (0 votes)
Author: Jan Newger                        
Website: http://newgre.net/idainject
Current version: 1.0.3
Last updated: July 18, 2008
Direct D/L link: http://newgre.net/system/files/IDAInject.rar
License type: Free / Open Source
Description: This plugin allows you to inject dlls into a debugged process, either prior to process creation or when the debugger is attached. The injected dll can then do some fancy stuff inside the debugged process.
To realize dll injection before process creation, new import descriptors are added to the image import directory of the debuggee, whereas injection into an already running process is realized via shellcode injection, which in turn loads the dll in question.
In either case, a full path to the dll can be supplied, so it is not necessary for the dll to be in the search path.
Also listed in: Code Injection Tools, IDA Extensions
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: ILSpy
Rating: 0.0 (0 votes)
Author: David Srbecky                        
Website: http://wiki.sharpdevelop.net/ILSpy.ashx
Current version: 1.0.0.729
Last updated: April 12, 2011
Direct D/L link: http://build.sharpdevelop.net/BuildArtefacts/#ILSpy
License type: Open-source
Description: ILSpy is the open-source .NET assembly browser and decompiler.

Development started after Red Gate announced that the free version of .NET Reflector would cease to exist by end of February 2011.

ILSpy Features:

Assembly browsing
IL Disassembly
Decompilation to C#
Supports lambdas and 'yield return'
Saving of resources
Search for types/methods/properties (substring)
Hyperlink-based type/method/property navigation
Base/Derived types navigation
Navigation history
BAML to XAML decompiler
Save Assembly as C# Project
Find usage of field/method
Extensibile via plugins (MEF)
Also listed in: .NET Decompilers, .NET Disassemblers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: InstallShield Decompiler 6.xx
Rating: 0.0 (0 votes)
Author: NEKOSUKI                        
Website: http://deioncube.in/files/cw2k/isd6
Current version: 1.00 beta 16 (cw2k's *retro-build*)
Last updated: August 1, 2011
Direct D/L link: http://deioncube.in/files/cw2k/isd6/isd_beta16.7z
License type: Free RE-Tool
Description: Updates from Beta 15 (2001/05/06) to Beta 16 (2011/08/01)
* added support for encrypted IS61(IS2011) setups (ISDGoBack.exe)

* Support for new unicode Types(WSTRING, WPOINTER)

* translated Japanese error messages into english (via google).

[ To bad that this box don't support any formating options :(
Click on website above for a nicer view. ]

Target Examples

Setup.inx
00000000 61 4C 75 5A 00 00 43 6F 70 79 72 69 67 68 74 20 aLuZ Copyright
00000010 28 63 29 20 31 39 39 30 2D 32 30 30 32 20 49 6E (c) 1990-2002 In
00000020 73 74 61 6C 6C 53 68 69 65 6C 64 20 53 6F 66 74 stallShield Soft
00000030 77 61 72 65 20 43 6F 72 70 2E 20 41 6C 6C 20 52 ware Corp. All R
00000040 69 67 68 74 73 20 52 65 73 65 72 76 65 64 2E 00 ights Reserved.
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Setup.dbg
00000000 6B 55 74 5A 00 6F 70 79 72 69 67 68 74 20 28 63 kUtZ opyright (c
00000010 29 20 31 39 39 30 2D 31 39 39 39 20 53 74 69 72 ) 1990-1999 Stir
00000020 6C 69 6E 67 20 54 65 63 68 6E 6F 6C 6F 67 69 65 ling Technologie
00000030 73 2C 20 4C 74 64 2E 20 41 6C 6C 20 52 69 67 68 s, Ltd. All Righ
00000040 74 73 20 52 65 73 65 72 76 65 64 2E 00 00 00 00 ts Reserved.
00000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Isrt.obl
00000000 70 4F 64 41 01 00 00 00 2F 00 00 00 10 00 44 65 pOdA / De
00000010 62 75 67 53 79 6D 62 6F 6C 73 2E 6F 62 73 EB 03 bugSymbols.obsë
00000020 00 00 B3 08 00 00 0E 00 41 63 74 69 76 61 74 69 ³ Activati
00000030 6F 6E 2E 6F 62 73 9E 0C 00 00 9E 4C 00 00 0A 00 on.obsž žL
00000040 41 73 73 65 72 74 2E 6F 62 73 3C 59 00 00 8D 49 Assert.obs<Y I
00000050 00 00 09 00 42 61 74 63 68 2E 6F 62 73 C9 A2 00 Batch.obsɢ

ISRTScriptDialogs.obs
00000000 48 4F F3 C9 76 33 2E 39 39 2E 30 30 32 00 00 00 HOóÉv3.99.002
00000010 43 6F 70 79 72 69 67 68 74 20 28 63 29 20 31 39 Copyright (c) 19
00000020 39 30 2D 32 30 30 32 20 49 6E 73 74 61 6C 6C 53 90-2002 InstallS
00000030 68 69 65 6C 64 20 53 6F 66 74 77 61 72 65 20 43 hield Software C
00000040 6F 72 70 2E 20 41 6C 6C 20 52 69 67 68 74 73 20 orp. All Rights
00000050 52 65 73 65 72 76 65 64 2E 00 00 00 00 00 00 00 Reserved.

NewSetup61.inx (Encrypted)
00000000 74 C4 2C 84 E1 E5 D4 28 10 FB 00 20 3C 24 FB 4D tÄ,„áåÔ( û <$ûM
Also listed in: Installer Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: JavaSnoop
Rating: 0.0 (0 votes)
Author: Aspect Security                        
Website: https://www.aspectsecurity.com/research/appsec_tools/javasnoop/
Current version: 1.1 RC2
Last updated: January 15, 2012
Direct D/L link: Locally archived copy
License type: Free
Description: A tool that lets you intercept methods, alter data and otherwise test the security of Java applications on your computer

Normally, without access to the original source code, testing the security of a Java client is unpredictable at best and unrealistic at worst. With access the original source, you can run a simple Java program and attach a debugger to it remotely, stepping through code and changing variables where needed. Doing the same with an applet is a little bit more difficult.

Unfortunately, real-life scenarios don’t offer you this option, anyway. Compilation and decompilation of Java are not really as deterministic as you might imagine. Therefore, you can’t just decompile a Java application, run it locally and attach a debugger to it.

Next, you may try to just alter the communication channel between the client and the server, which is where most of the interesting things happen anyway. This works if the client uses HTTP with a configurable proxy. Otherwise, you’re stuck with generic network traffic altering mechanisms. These are not so great for almost all cases, because the data is usually not plaintext. It’s usually a custom protocol, serialized objects, encrypted, or some combination of those.

JavaSnoop attempts to solve this problem by allowing you attach to an existing process (like a debugger) and instantly begin tampering with method calls, run custom code, or just watch what’s happening on the system.
Also listed in: Java Code Injection Tools, Network Monitoring Tools, Network Sniffers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: ManualMap
Rating: 0.0 (0 votes)
Author: Darawk                        
Website: N/A
Current version:
Last updated: September 9, 2005
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: ManualMap is a library I wrote for dll injection by 'manually mapping' a PE file into the remote address space of a process. Instead of calling LoadLibrary or using SetWindowsHookEx (which also essentially calls LoadLibrary internally), this code parses the PE file itself, fixes up the relocs, maps the sections, and builds the import table. It also redirects APIs like GetModuleHandle and GetProcAddress so that manualmap'd modules are visible to each other, but are not visible to any other modules in the process.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Mhook
Rating: 0.0 (0 votes)
Author: Marton Anka                        
Website: http://codefromthe70s.org/mhook2.asp
Current version: 2.1
Last updated: October 15, 2007
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: Mhook is a library for installing API hooks. If you dabble in this area then you’ll already know that Microsoft Research's Detours pretty much sets the benchmark when it comes to API hooking. Why don't we get a comparison out of the way quickly then?


Detours vs. Mhook

Detours is available for free with a noncommercial license but it only supports the x86 platform. Detours can also be licensed for commercial use which also gives you full x64 support, but you only get to see the licensing conditions after signing an NDA.

Mhook is freely distributed under an MIT license with support for x86 and x64.

Detours shies away from officially supporting the attachment of hooks to a running application. Of course, you are free to do it - but if you end up causing a random crash here or there, you can only blame yourself.

Mhook was meant to be able to set and remove hooks in running applications – after all, that’s what you need it for in the real world. It does its best to avoid overwriting code that might be under execution by another thread.

Detours supports transactional hooking and unhooking; that is, setting a bunch of hooks at the same time with an all-or-nothing approach. Hooks will only be set if all of them can be set, otherwise the library will roll back any changes made. Mhook does not do this.

Finally, Mhook is pretty lazy when it comes to managing memory for the trampolines it uses. Detours allocates blocks of memory as needed, and uses the resulting data area to store as many trampolines within as will fit. Mhook, on the other hand, uses one call to VirtualAlloc per hook being set. Every hook needs less than 100 bytes of storage so this is very wasteful, since VirtualAlloc ends up grabbing 64K from the process' virtual address space every time Mhook calls it. (Actual allocated memory will be a single page which is also quite wasteful.) In the end though, this probably does not really matter, unless you are setting a very large number of hooks in an application. Also, this is very easy to fix.

With that out of the way, if you’re still here, let’s delve into it.


Future Improvements

Mhook is far from perfect. The following things should be addressed in the future:

* Implement a memory allocator so one call to VirtualAlloc can service multiple hooks
* Improve the thread-suspension code so it can deal with threads that are spawned during the execution of the thread-suspension process itself
* Improve error handling so meaningful failure codes can be retrieved by GetLastError
* For the truly paranoid: deal with possible conflicts with other hooking libraries (what if Mhook_SetHook is called on a function that is currently hooked with Detours, etc)
* Add support for IA64 (Itanium)
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: mmBBQ
Rating: 0.0 (0 votes)
Author: Michael Willigens, Rene Laemmert                        
Website: http://web.archive.org/web/20150507114635/http://duschkumpane.org/index.php/mmbbq
Current version: 3.1.0RC1
Last updated: October 16, 2014
Direct D/L link: http://hellgateaus.info/files/mmbbq_3.1.0_RC1.zip
License type: public domain, closed source
Description: mmBBQ injects an interactive codecaving Lua API into a win32 process. It is easy to use, there are no dependencies and only little knowledge is required. It was initially built to create APIs for MMORPGs. However it is fully generic and can attach to any kind of program. It can also inject into many protected processes, as it's meant to bypass some protective mechanisms. It offers debugging functionality, but not being a debugger itself makes it harder to detect.

It's easy to place any form of generic codecaves by using plain Lua code (LuaJIT C-Types). For Example:
codecave.inject(nil, getProcAddress("user32", "GetMessageA"), function(context) print("Hellow World Codecave") end)

It can also call arbitrary functions of the host process:
asmcall.cdecl(getProcAddress("user32", "MessageBoxA"), 0, "Hello World!", "Title", 0)

Aside that it includes a debugging and disassembly module, that can be used to script breakpoints. This can be useful when making packed .exe extractors etc.


64 bit support is underway. And further future maybe also a Linux and Mac version.
Also listed in: Code Injection Tools, Debuggers, Disassemblers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: myAut2Exe
Rating: 0.0 (0 votes)
Author: cw2k                        
Website: http://myaut2exe.tk/
Current version: 2.10
Last updated: February 2011
Direct D/L link: http://deioncube.in/files/MyAutToExe/myAutToExe2_10_src.7z
License type: Open Source
Description: AutoIT Script Decompiler

Decompiles:
compiled AutoIT scripts(*.a3x and *.exe) to *.au3 and
compiled AutoHotKey scripts (*.exe) to *.ahk.
... and extracts attached files.

DeObfuscates:
'Jos van der Zande AutoIt3 Source Obfuscator'
'EncodeIt 2.0' and
'Chr() string encode.

Last tested Versions:
AutoIT  : v3. 3. 5.6
AutoIT  : v3. 3. 0.0 and
AutoIT  : v2.64. 0.0 and
AutoHotKey: v1. 0.48.5
Also listed in: Decompilers, Installer Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: N-CodeHook
Rating: 0.0 (0 votes)
Author: Jan Newger                        
Website: http://newgre.net/ncodehook
Current version: 1.0.1
Last updated: July 07, 2008
Direct D/L link: http://newgre.net/system/files/NCodeHook.rar
License type: Free / Open Source
Description: N-CodeHook is a small template based C++ library which allows you to hook into functions via inline patching.
For some background info see the blog post or read the paper from the detours website on how inline patching works. Detours uses the same mechanism as N-CodeHook, but requires you to buy a license for the X64 version. Besides the IA32 version must not be used for commercial purposes.
N-CodeHook however is completely free and you can use it for whatever you like.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: N-InjectLib
Rating: 0.0 (0 votes)
Author: Jan Newger                        
Website: http://newgre.net/ninjectlib
Current version: 1.0.2
Last updated: July 14, 2008
Direct D/L link: http://newgre.net/system/files/NInjectLib.rar
License type: Free / Open Source
Description: N-InjectLib is a library written in C++ which allows of injecting dynamic link libraries into a remote (i.e. foreign) process.
Two techniques are available to inject a dll: the target process can be started by using the library so the first dll loaded actually is the dll to be injected, or dlls can be injected anytime while the target process is running.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: NetAsm
Rating: 0.0 (0 votes)
Author: Alexandre Mutel                        
Website: http://www.codeplex.com/netasm
Current version: 1.0
Last updated: July 25, 2008
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: NetAsm provides a hook to the .NET JIT compiler and enables to inject your own native code in replacement of the default CLR JIT compilation. With this library, it is possible, at runtime, to inject x86 assembler code in CLR methods with the speed of a pure CLR method call and without the cost of Interop/PInvoke calls.

NetAsm can be used to integrate optimized native code using CPU extended instructions (SSE,MMX) into your managed code. The NetAsmDemo sample provides two benchmarks that unveil the power of using native code injection with NetAsm.

For more information about NetAsm, code injection techniques and recommendations, please consult the NetAsm-UserGuide.
Also listed in: .NET Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: NtHookEngine
Rating: 0.0 (0 votes)
Author: Daniel Pistelli                        
Website: http://www.ntcore.com/Files/nthookengine.htm
Current version: 1.1
Last updated: April 1, 2008
Direct D/L link: http://www.ntcore.com/Files/nthookengine/nthookengine.zip
License type: Free / Open Source
Description: NtHookEngine is a powerful x86/x64 mini hook-engine

I wrote this little hook-engine for a much bigger article. Sometimes it seems such a waste to write valuable code for large articles whose topic isn't directly related to the code. This often leads to the problem that the code won't be found by the people who are looking for it.

Personally, I would've used Microsoft's Detour hook engine, but the free license only applies to x86 applications, and that seemed a little bit too restrictive to me. So, I decided to write my own engine in order to support x64 as well. I've never downloaded Detour nor have I ever seen its APIs, but from the general overview given by Microsoft it's easy to guess how it works.

As I said, this is only a part of something bigger. It's not perfect, but it can easily become such. Since this is not a beginner's guide about hooking, I assume that the reader already possesses the necessary knowledge to understand the material. If you never heard about this subject, you'd better start with another article. There's plenty of guides out there, no need to repeat the same things here.

As everybody knows there's only one easy and secure way to hook a Win32 API: to put an inconditional jump at the beginning of the code to redirect it to the hooked function. And by secure I just mean that our hook can't be bypassed. Of course, there are some other ways, but they're either complicated or insane or both. A proxy dll, for instance, might work in some cases, but it's rather insane for system dlls. Overwriting the IAT is unsecure for two reasons:

a) The program might use GetProcAddress to retrieve the address of an API (and in that case we should handle this API as well).
b) It's not always possible, there are many cases as for packed programs where the IAT gets built by the protection code and not by the Windows loader.

Ok, I guess you're convinced. Let's just say that there's a reason why Microsoft also uses this method.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Nucleus Framework
Rating: 0.0 (0 votes)
Author: PAPiLLiON                        
Website: http://www.woodmann.com/forum/showthread.php?t=12009
Current version: 1.0.0028.1059
Last updated: August 18, 2008
Direct D/L link: Locally archived copy
License type: Free
Description: Today i decided that it's a good day for the initial release of my nucleus framework.

What you can do with it:

- Inject a specified DLL to a targets' address space

That's it. Extremely minimal usage for the first release but who cares
Would be nice if some would test it and tell me if it works.


USAGE: nucleus <switches> target.exe

--help, --h, -help, -h

display usage help. also displayed if no parameter is selected


--log, --l, -log, -l <logging mode>

select logging mode. 1 = LOG_MODE_STDOUT - log to stdout
2 = LOG_MODE_FILE - log to file
4 = LOG_MODE_NOLOG - log disabled
mode 1 and 2 can be used in combination(expl. 3 for stdout and file
together). if no logging mode selected 1 is default
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Orca
Rating: 0.0 (0 votes)
Author: Microsoft                        
Website: http://msdn2.microsoft.com/en-us/library/aa370557(VS.85).aspx
Current version:
Last updated:
Direct D/L link: http://www.microsoft.com/downloads/details.aspx?FamilyId=C2B1E300-F358-4523-B479-F53D234CDCCF&displaylang=en
License type: Proprietary
Description: Orca is a database table editor for creating and editing Windows Installer packages and merge modules. The tool provides a graphical interface for validation, highlighting the particular entries where validation errors or warnings occur.

This tool is only available in the Windows SDK Components for Windows Installer Developers. It is provided as an Orca.msi file. After installing the Windows SDK Components for Windows Installer Developers, double click Orca.msi to install the Orca.exe file.
Also listed in: Installer Decompilers, Installer Extraction Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: PIN
Rating: 0.0 (0 votes)
Author: Intel                        
Website: http://rogue.colorado.edu/pin
Current version: 2.3 (rev 18525)
Last updated: April 10, 2008
Direct D/L link: N/A
License type: Free / Open source
Description: Pin is a tool for the dynamic instrumentation of programs. It supports Linux binary executables for Intel (R) Xscale (R), IA-32, IA-32E (64 bit x86), and Itanium (R) processors. It also allow instrumentation of Windows programs on IA-32 and Intel (R) 64 processors

Pin was designed to provide functionality similar to the popular ATOM toolkit for Compaq's Tru64 Unix on Alpha, i.e. arbitrary code (written in C or C++) can be injected at arbitrary places in the executable. Unlike Atom, Pin does not instrument an executable statically by rewriting it, but rather adds the code dynamically while the executable is running. This also makes it possible to attach Pin to an already running process.

Pin provides a rich API that abstracts away the underlying instruction set idiosyncrasies and allows context information such as register contents to be passed to the injected code as parameters. Pin automatically saves and restores the registers that are overwritten by the injected code so the application continues to work. Limited access to symbol and debug information is available as well.

Pin includes the source code for a large number of example instrumentation tools like basic block profilers, cache simulators, instruction trace generators, etc. It is easy to derive new tools using the examples as a template.
Also listed in: Code Injection Tools, Profiler Tools, Tracers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Pin
Rating: 0.0 (0 votes)
Author: Intel                        
Website: https://software.intel.com/en-us/articles/pintool/
Current version: 97554
Last updated: February 11, 2018
Direct D/L link: Locally archived copy
License type: Free
Description: Pin is a dynamic binary instrumentation framework for the IA-32, x86-64 and MIC instruction-set architectures that enables the creation of dynamic program analysis tools. Some tools built with Pin are VTune Amplifier XE, Inspector XE, Advisor XE and SDE. The tools created using Pin, called Pintools, can be used to perform program analysis on user space applications on Linux, Windows and OS X*. As a dynamic binary instrumentation tool, instrumentation is performed at run time on the compiled binary files. Thus, it requires no recompiling of source code and can support instrumenting programs that dynamically generate code.


Pin provides a rich API that abstracts away the underlying instruction-set idiosyncrasies and allows context information such as register contents to be passed to the injected code as parameters. Pin automatically saves and restores the registers that are overwritten by the injected code so the application continues to work. Limited access to symbol and debug information is available as well.

Pin was originally created as a tool for computer architecture analysis, but its flexible API and an active community (called "Pinheads") have created a diverse set of tools for security, emulation and parallel program analysis.
Also listed in: API Monitoring Tools, Code Injection Tools, Programming Libraries, Reverse Engineering Frameworks
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Process Inject
Rating: 0.0 (0 votes)
Author: ap0x                        
Website: http://ap0x.jezgra.net/patchers.html
Current version: 0.1
Last updated:
Direct D/L link: Locally archived copy
License type: Free
Description: Process.Inject 0.1
--------------------

WARNING: Do not rename inject.exe!

How to use:
inject.exe -p<PID> -a<ADDRESS> -b<BYTES> -l<LENGTH>
inject.exe -p<PID> -a<ADDRESS> -f<FILE>
inject.exe -p<PID> -n<ALLOCSIZE>
inject.exe -p<PID> -r<THREADSTART>

<PID> = ProcessID [hex]
<ADDRESS> = Address where to insert bytes [hex]
<BYTES> = Patch bytes [hex]
<LENGTH> = Number of bytes to write (1..4)
<FILE> = Path to file to inject in memory (.bin)
<ALLOCSIZE> = Size of memory to allocate in target process [hex]
<THREADSTART> = New thread`s start address [hex]

Example:
inject.exe -p101 -a00401000 -bEBFE -l2
inject.exe -p101 -a00401000 -fC:\inject_me.bin
inject.exe -p101 -n1000
inject.exe -p101 -r00830000
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Profile Coverage Tool
Rating: 0.0 (0 votes)
Author: Rolf Rolles                        
Website: http://www.woodmann.com/forum/showthread.php?t=11325
Current version: 1.0
Last updated: February 17, 2008
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: A DynamoRIO extension for binary code coverage and profiling. It works on a function-level (although block-level support could be added easily -- the source weighs in at a measly 70 lines in 2kb, so if you want some other feature, just code it), and it can either be a profiler or a code coverage analyzer. All it does is instrument the code such that each call instruction, direct or indirect, will write its source and target addresses into a file. This data can then be used for either profiling or code coverage purposes: simply discard all of the duplicates for the latter, and use the data as-is for the former. This is just the back-end, but I imagine that this could be easily integrated into PaiMei's front end to provide an industrial-grade coverage and profiling tool.

Strengths of DynamoRIO:
* speed (you might not even notice the slowdown);
* stability (there used to be a commercial security product based on this technology -- it is literally industrial grade);
* trivial to code extensions for (70 lines, 2kb for this simple yet powerful extension).

Weaknesses:
* definitely won't work with self-modifying code
* probably won't work with obfuscated or "self-protecting" code (there's particularly a problem with so-called "pc-relative" addressing, such as call $ / pop ebp).

Studious readers may note that automatic indirect call resolution is exceptionally useful for C++ reverse engineering; comment out the direct call resolution, recompile, write a quick IDC script to add the x-refs to the disassembly listing, and you've got a killer C++ RE tool. Credit goes to spoonm for having and implementing this idea initially.
Also listed in: Code Coverage Tools, Profiler Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: PunchIt
Rating: 0.0 (0 votes)
Author: CondZero / ARTeam                        
Website: http://arteam.accessroot.com
Current version: 1.2
Last updated: January 18, 2011
Direct D/L link: http://www.accessroot.com/arteam/site/download.php?view.252
License type: Free
Description: It is a program useful to automatically inject into ANY application your sound and music. The music will be played in background when the program runs as before.

The tool comes with a comprehensive help file

Current Release: v1.2 January 2011

+ fix problem when extracting to temp
+ fix dialog repainting issue
+ all PECompact2 c2t*.tmp files (located in your temporary folder) are deleted if the compress option is chosen upon exiting the application
+ extract to temp and overwrite existing options now default
+ add ability to select a custom Icon (*.ico) file
+ latest build of Bass Audio module v2.4.6

Key features

Works with most windows 32 bit executable files (including packed / protected files) via a wrapper program, alternately called a Loader, a small piece of code and data attached to processed modules / music (files) that is responsible for extracting the application / music files and launching the application whilst playing the sound file.
Bass Audio module v2.4.6 (win32 version) capable of playing:
Streamable files:
*.wav;*.aif;*.mp3;*.mp2;*.mp1;*.ogg
MOD music files:
*.mo3;*.xm;*.mod;*.s3m;*.it;*.mtm;*.umx

PECompact2 v2.94.1 (Student build) compresses modules substantially better than that of the common compression software such as RAR and ZIP, and is more reliable in compressing certain types of packed / encrypted executable files than UPX. This is accomplished through advanced techniques of pre-processing a module to make it more compressible when passed to the compression algorithm.
Replaces the icon from either a custom Icon (*.ico) file or the source input executable file (if found) into the new output executable file.
Requires no programming knowledge to use.

Please test and report any probs. As can sometimes happen, if you choose a packed / protected
source executable, you may run into problems compressing and should choose the non compress
option. This is not a fault of the application, but a limitation imposed by compressor programs
such as PECompact2 (Student build) v1.94.1 (latest).
Also listed in: Code Injection Tools, GUI Manipulation Tools, Resource Editors
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: PurifyPlus
Rating: 3.0 (1 vote)
Author: IBM / Rational                        
Website: http://www-306.ibm.com/software/awdtools/purifyplus/win/
Current version: 7.0
Last updated:
Direct D/L link: N/A
License type: Commercial (with demo)
Description: This tool does reportedly not work without having debug information (pdb, dbg, or map) or the source code for the analyzed program. A map file can be produced by e.g. IDA Pro though, so it could still be useful for reversing purposes.

See the following for more info:
http://www.woodmann.com/forum/showthread.php?t=11306

-----------------------------

Rational® PurifyPlus for Windows® is an automated runtime analysis tools for Windows-based application performance.
Software Test and Performance 2006 Testers Choice Awards

Automated runtime analysis tools to improve Windows-based application reliability and performance. Designed for Java, Visual C/C++, C#, VB.NET, and Visual Basic applications.

* Provides a complete set of automated runtime analysis tools
* Includes memory corruption detection, memory leak detection, application performance profiling and code coverage analysis
* Is designed for Java, Visual C/C++, C#, VB.NET and Visual Basic applications
Also listed in: Code Coverage Tools, Profiler Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: RACEVB6
Rating: 0.0 (0 votes)
Author: Sarge                        
Website: http://www.racevb6.com
Current version: 4.4
Last updated: June 9, 2008
Direct D/L link: http://www.racevb6.com/RaceEx6_4_4.zip
License type: Free
Description: RACEVB6 is a Visual Basic 6 P-Code analyzer. RACEVB6 can be used to investigate Visual Basic 6 programs compiled to P-Code. RACEVB6 will display not only such typical information as Project data and Form/Control GUI data, but will also make available Procedures names and offsets, their accompanying P-Code opcodes, extract any Pictures or Images contined within the program, and many other pieces of "buried" data.
Also listed in: Decompilers, Visual Basic Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: REDasm
Rating: 0.0 (0 votes)
Author: Dax                        
Website: https://github.com/REDasmOrg/REDasm
Current version: Nightly
Last updated:
Direct D/L link: https://github.com/REDasmOrg/REDasm-Builds
License type: GPL2
Description: REDasm is a crossplatform, interactive, multiarchitecture disassembler written in C++ with Qt5 framework.
its core is light and it can be extended in order to support new instructions and file formats.
In the future, Python scripting will be supported.
Also listed in: Disassemblers, Linux Disassemblers, Visual Basic Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: RecStudio
Rating: 0.0 (0 votes)
Author: Backer Street Software                        
Website: http://www.backerstreet.com/rec/rec.htm
Current version: 4
Last updated: June 2, 2014
Direct D/L link: http://www.backerstreet.com/rec/RecStudioWin.zip
License type: Free
Description: REC Studio is an interactive decompiler.
It reads a Windows, Linux, Mac OS X or raw executable file, and attempts to produce a C-like representation of the code and data used to build the executable file.
It has been designed to read files produced for many different targets, and it has been compiled on several host systems.
REC Studio 4 is a complete rewrite of the original REC decompiler. It uses more powerful analysis techniques such as partial Single Static Assignment (SSA), allows loading Mac OS X files and supports 32 and 64 bit binaries.
Also listed in: Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Scripts for Perl Decompiling
Rating: 0.0 (0 votes)
Author: Swine                        
Website: N/A
Current version: 1.0
Last updated: April 1, 2011
Direct D/L link: Locally archived copy
License type: Free/GPL
Description: Bash & IDA Scripts for automated decompiling of Perl program compiled by perlcc

REVISION HISTORY
Version Author Date
1.0 Swine ????????

perlcc parses Perl script and makes C code (which is in turn compiled to executable through CC) that initializes execution tree, which is later interpreted through perl_run documented function. The execution tree can be decompiled by documented Perl B::Decomp module (in latest Perl releases this module has gone along with perlcc). The trick is to inject the call to decompiler into the target program.

See README inside the archive for further details
Also listed in: Decompilers, IDA IDC Scripts
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: SourPill VM Detector
Rating: 0.0 (0 votes)
Author: TiGa                        
Website: N/A
Current version: 1.0
Last updated: August 17, 2007
Direct D/L link: Locally archived copy
License type: Free
Description: Here is a little program I made to help with VM detection.

It reads the cpu name and checks the average RDTSC timing of the CPUID instruction over 100000 executions.

CPUID takes around 350 cycles to execute on a Native OS but around 2500-3500 cycles in a VM. It should also notice a timing difference if VMX is enabled and used for intel cpus due to the TLB having to be rewritten in part.

The only thing i think that could fool it is Blue Chicken in the New Blue Pill.

I hope it can be of use to somebody.
Also listed in: VM Detection Test Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: SpyStudio
Rating: 0.0 (0 votes)
Author: Nektra                        
Website: http://www.nektra.com/products/spystudio
Current version: 2.9.2
Last updated: November 17, 2015
Direct D/L link: Locally archived copy
License type: Free
Description: SpyStudio is a powerful application that simplifies the code execution interception operations, also called "hooking". Users can now easily monitor and gain control over processes in their systems, to really know what is happening in the Operating System and it's applications.

With SpyStudio you can monitor and intercept API calls at any time, change its parameters, and resume execution.

SpyStudio uses the Deviare API technology to intercept functions' calls, this allows the user to monitor and hook applications in real time.
Deviare is a very complex technology, that can be used through the most simple interfaces.

This useful application provides the ability to break process execution and inspect the function's parameters at any level, and even change its values.

* Hooks any module of any application.

* Understands almost any function's parameters. Every defined data structures and types in windows.h are supported.

* Break on monitor: Break application's code execution, watch and modify function's parameters.

* Integrated Python shell: Now allows to execute Python scripts and handle hooks!

* Some of the modules included on the database are:

Advapi32.dll
Gdi32.dll
Kernel32.dll
Ntdll.dll
User32.dll
Shell32.dll
Wininet.dll
Also listed in: API Monitoring Tools, Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Telerik JustDecompile
Rating: 0.0 (0 votes)
Author: Telerik                        
Website: http://www.telerik.com/
Current version: 2014.1.225.0
Last updated:
Direct D/L link: http://www.telerik.com/downloads/productfiles/bgkht/JustDecompile_2014.1.225.0.msi
License type: Developer Licence is Free
Description: An alternative to Reflector and IlSpy.
JustDecompile is .NET assembly browser and decompiler.

- Fast code navigation
- Create Visual Studio projects
- Extract resources from assemblies
- Easy assembly management
- Zip file distribution
- Visual Studio Extension - decompile referenced assemblies
- Visual Studio inline decompilation (through JustCode)
- Command line support
- Integrate with Windows Explorer Context Menu
- SL XAP decompilation from URL
- Open API (extensible)
- Edit assemblies with Reflexil
- Deobfuscate with de4dot
- C#5 (WinRT) support
- APPX and WinMD support
Also listed in: .NET Decompilers, .NET Disassemblers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: uncc
Rating: 0.0 (0 votes)
Author: littlejohn / megabug                        
Website: http://www.reteam.org/tools.html
Current version: 0.1.0
Last updated:
Direct D/L link: http://www.reteam.org/tools/tf14.zip
License type: Free
Description: C decompiler
Also listed in: Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: VB Decompiler
Rating: 0.0 (0 votes)
Author: GPcH Soft                        
Website: http://www.vb-decompiler.org
Current version: 8.2
Last updated: April 20, 2011
Direct D/L link: http://www.vb-decompiler.org/files/vb_decompiler_lite.zip
License type: Shareware
Description: VB Decompiler is decompiler for programs (EXE, DLL or OCX) written in Visual Basic 5.0/6.0. As you know, programs in Visual Basic can be compiled into interpreted p-code or into native code.

Since p-code consists of high-level commands, there is a real possibility to decompile it into the source code (of course, the names of variables, functions, etc. will not be decompiled). VB Decompiler restores many p-code instructions and although there is a long way to the generation of the source code that can be compiled, the decompiler will make analyzing the program algorithm much easier and partially restore its source code.

If a program was compiled into the native code, restoring the source code from machine instructions is not possible. But VB decompiler can help to analyze the program even in this situation as well. It contains a powerful disassembler that supports Pentium Pro commands including MMX and SSE. It allows you to disassemble all functions. There is also a code analyzer that searches for all API function calls and string references in the disassembled code and changes them into comments for analyzed strings. In general, VB Decompiler is an ideal tool for analyzing programs and it is perfect if you lose the source code and need to partially restore the project.
Also listed in: Decompilers, Visual Basic Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: VBReFormer
Rating: 0.0 (0 votes)
Author: Sylvain Bruyere                        
Website: http://www.decompiler-vb.net/
Current version: v6.2 Free Edition
Last updated: November 3, 2014
Direct D/L link: http://download.decompiler-vb.net/setup_free.exe
License type: Shareware
Description: VBReFormer Free Edition is a limited edition of VBReFormer Professional Edition, a powerful set of recovery tools for Visual Basic 5 & 6 application.

Decompiler, disassembler, and design editor at the same time, VBReFormer is a must-have tool for companies and professionals who work with version 5 & 6 of Visual Basic.

VBReFormer disassemble all functions and methods in forms, controls, classes, and modules of Visual Basic application and try to recover the most complete Visual Basic source code than possible (if compiled with the native code option).

Furthermore, thanks to its integrated decompilation engine, VBReFormer perfoms a native decompilation from Native code to Visual Basic code, in the fullest extent possible.

Note: VBReFormer is not able to disassemble P-Code applications at the moment.

VBReFormer recovers UI meta information and resources of Visual Basic 5 & 6 application (forms, usercontrols, designers, pictures, etc.) and extracts these information into a Visual Basic project.

Even better, the integrated design editor of VBReFormer succeeds where others resources editors fail with Visual Basic applications with its ability to edit UI design of Visual Basic applications in a simple and easy way with no limitation of size, and with no need to recompile the application, working directly on its binary.
Also listed in: Decompilers, Disassemblers, PE Executable Editors, Resource Editors, Visual Basic Decompilers, Visual Basic Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: VTune Performance Analyzer
Rating: 3.0 (1 vote)
Author: Intel                        
Website: http://www.intel.com/cd/software/products/asmo-na/eng/vtune/219898.htm
Current version: 9.0
Last updated:
Direct D/L link: N/A
License type: Commercial (with trial)
Description: This tool does reportedly not work ANYMORE without having the source code for the analyzed program, which sadly makes it relatively useless for reversing purposes.

Up until version 5 it used to have pure assembler profiling though, so if you can find an old <= 5 version it might still be a good tool though.

See the following for more info:
http://www.woodmann.com/forum/showthread.php?t=11306

-----------------------------
Nice analysis tool, which can among other things log API calls, create call graphs, analyse and trace thread usage and synchronization object use.

Includes Intel Thread Profiler too.

Intel's own sale spin description:
Deliver fast software on the latest 64-bit multi-core systems running Microsoft Windows Vista*, Windows* XP or Windows Server*. Locate performance bottlenecks without recompilation and with very low overhead (under 5%). Analyze the results using a graphical interface with strong Visual Studio* and .NET integration. Quickly drill down to the source to identify problematic lines of code.
Also listed in: Thread Monitoring Tools, Profiler Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Valgrind
Rating: 0.0 (0 votes)
Author:                         
Website: http://valgrind.org
Current version: 3.2.3
Last updated: January 29, 2007
Direct D/L link: N/A
License type: Free / Open Source
Description: Valgrind is an award-winning suite of tools for debugging and profiling Linux programs. With the tools that come with Valgrind, you can automatically detect many memory management and threading bugs, avoiding hours of frustrating bug-hunting, making your programs more stable. You can also perform detailed profiling, to speed up and reduce memory use of your programs.

The Valgrind distribution currently includes four tools: a memory error detector, a cache (time) profiler, a call-graph profiler, and a heap (space) profiler. It runs on the following platforms: X86/Linux, AMD64/Linux, PPC32/Linux, PPC64/Linux.
Also listed in: Code Injection Tools, Linux Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Whiskey Kon Tequilla VB P-Code Debugger
Rating: 0.0 (0 votes)
Author: WKT Team                        
Website: N/A
Current version: 1.3e
Last updated: Around 2001
Direct D/L link: Locally archived copy
License type: Free
Description: Also known as "WKT Debugger".

At the time it showed up, the one and only P-Code disassembler / debugger mankind was able to use.

Before it, debugging of the P-Code (Runtime interpreted Pseudo-VB code) with ordinary disassemblers / debuggers was really pain in your neck. This one saved me a lot of time, and probably helped postpone my deportation to the psychiatric research facility.
Also listed in: Disassemblers, Visual Basic Debuggers, Visual Basic Decompilers
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Win32 CodeHook
Rating: 0.0 (0 votes)
Author: Wang Qi                        
Website: http://www.kbasm.com/codehook.html
Current version: 1.0.0
Last updated:
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: Win32 CodeHook is an open source library for binary code hook and redirect for Win32 Delphi and C++.

Features and advantages
1. Can hook function that starts with jump instructions.
Most other simple API/code hook technic can not hook functions that first several instructions include jump instructions such like jmp, jcc (jump if condition is met), call, jecxz, etc.
CodeHook can rewrite those instructions in a safe way and continue hooking.
The only instructions that can prevent CodeHook from hooking are ret and iret, which indicate the function end is met and the function is too short to hook.

2. Very easy to use.
CodeHook not only supports raw mode code hooking, it also supports advanced hooking.
CodeHook can generate "bridge code" that connects your hook code to the target code.
Thus you only need to writer hook code in a unique form (unique prototype functions) rather than writting different hook code for different target.
The typical hook prototype is,
Delphi syntax: function HookCallback(AHandle: TCodeHookHandle; AParams: PCodeHookParamAccessor): Cardinal; CallingConvertion;
C++ syntax: DWORD CallingConvertion HookCallback(TCodeHookHandle AHandle, PDWORD AParams);
This feature makes it possible to use one hook function to hook multiple functions. See the Delphi sample code. And this is how I do in the new Denomo package.
And even better, both of the hook and target functions can have various calling conventions. The calling conventions now supported are stdcall (used by Windows APIs), cdecl (used by C), and register call (used by Delphi).

3. Very flexible.
CodeHook separates your hook function from the target function. Your hook function can fully replace the target function, or call old target function in the hook function in any time you want.
And even more flexible, you can easily modify the parameters before passing them to the old target function.

4. Can be used by any program language which can use a DLL.
Though CodeHook is written in Delphi, the CHook.dll can be used by any other languages such like C++. In fact CodeHook has sample code that written in Delphi and C++. The sample C++ code can be compiled by VC6 and Borland C++ 5.5 or C++ Builder (BCB).

5. Free and open source.
The license is MPL.

6. More feature will come soon.
CodeHook was made to use in Denomo (a memory leak detection tool), so it now only supports in-process hooking. But inter-process hooking and DLL injection will be added in the near future versions.

CodeHook itself has been verified that it can be compiled by Delphi 7 and Delphi 2007. It should but not must be able to be compiled by Delphi 6, Delphi 2005, and Delphi 2006.
CHook.dll can be used by any language that supports DLL, pointer, and data structure.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)



Tool name: Win32Hook
Rating: 0.0 (0 votes)
Author: Russell Libby                        
Website: http://users.adelphia.net/~rllibby/source.html
Current version:
Last updated: February 14, 2006
Direct D/L link: Locally archived copy
License type: Free / Open Source
Description: Delphi unit that provides IAT updating, code overwriting (uses DISASM32 for this), and library injection. All handling is done using class objects, and should be relatively simple to use.
Also listed in: Code Injection Tools
More details: Click here for more details, screenshots, related URLs & comments for this tool! (or to update its entry)


...

There were too many (recursive) child objects of this category to display them all, please use the sub categories below to increase the detail of your search criteria!


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.


Subcategories

There are 46 subcategories to this category.




No items can be added directly to this category, please rather select one of its sub-categories above to submit an item!

Views