From Collaborative RCE Tool Library

Jump to: navigation, search

xADT eXtensible Anti-Debug Tester

Tool name: xADT eXtensible Anti-Debug Tester
Rating: 5.0 (2 votes)
Author: Shub-Nigurrath / ARTeam                        
Current version: 1.4
Last updated: September 22, 2008
Direct D/L link:
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:


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:


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:


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) -
WARNING (or 2)

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
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

-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 (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
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
+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
+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
+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,

Last revision: 30th August 2008
Related URLs: No related URLs have been submitted for this tool yet

Screenshot of XADT eXtensible Anti-Debug Tester

RSS feed Feed containing all updates for this tool.

You are welcome to add your own useful notes about this tool, for others to see!

If you find that any information for the tool above is missing, outdated or incorrect, please edit it!
(please also edit it if you think it fits well in some additional category, since this can also be controlled)

Category Navigation Tree
   Code Coverage Tools  (13)
   Code Ripping Tools  (2)
   Helper Tools  (3)
   Hex Editors  (13)
   Memory Patchers  (7)
   Packers  (19)
   Profiler Tools  (11)
   String Finders  (10)
   Tool Hiding Tools  (7)
   Tracers  (20)
   Needs New Category  (3)