Collaborative RCE Tool Library - Anti Anti Test Tools (including sub-categories)

Tool Updated: HookShark

Thu, 02 Sep 2010 17:57:06 GMT

Listed in categories: Usermode Hook Detection Tools

Most recent version:
BETA 0.9

Most recent release date:
September 1, 2010

Description:
HookShark is a detector of installed hooks and patches installed on the system (only usermode for now). It scans through the code-section of every loaded module of each running process and compares it with the file-image. If it detects discrepancies it tries to determine the type of hook or patch and reports it to the user.

Currently implemented hook detection:

* - Inline patches / Hooks (NOP, Exceptionhandler, relative Jumps, Custom patches)
* - Other custom patches [...]
* - VTable Hooks
* - IAT and EAT Hooks
* - Relocation Hooks
* - Hardware Breakpoints
* - PAGE_GAURD Candidates

FAQ

Why is IAT-Scanning / Hook-Scanning so slow? There are faster tools.
=====================================================================

That's because other tools suck. They just walk the IAT Entrys and look for addresses that are out of the module bounds. Thats bollocks. The callback function of the hook, or a redirection (JMP) could be planted well within the module bounds, and there you have a stealth IAT Hook, which HookShark recognizes as "IAT - Local".
And HookShark scans EVERY IAT-Table of EVERY Module. Unlike some other tools, which just examine the main process module.

And HookShark does not only check for hooks in exported/known functions. No, byte by byte of disk/memory image is compared, and even one-byte-patches are revealed. That is only for read-only code-sections though.

What the hell is all that crap? So many patches WTF?
======================================================

HookShark looks for differences between the disk image and the scanned memory. There might be cases where you are just looking at a packed module. To counter these false positives, there is an option to filter patches, which are bigger than n-bytes. (Look in the GlobalOptions Tab)

Sometimes after i scanned a process and want to scan another one and it crashes.
=================================================================================

Yeah, i hate when that happens. I have no idea why. If i get my lazy ass on the debugger i try to check it out. Until then, just restart HookShark.

The mnemonics of patched instructions are wrongly displayed.
============================================================

That's because HookShark just cant do a thorough analysis like IDA does for every module in this short time-span. The alignment of instructions is guessed and heuristically computed.

Tool Updated: Kernel Detective

Mon, 07 Dec 2009 01:58:35 GMT

Listed in categories: Hook Detection Tools, Kernel Hook Detection Tools, Kernel Tools, Malware Analysis Tools

Most recent version:
1.3.1

Most recent release date:
December 06, 2009

Description:
Kernel Detective is a free tool that help you detect, analyze, manually modify and fix some Windows NT kernel modifications. Kernel Detective gives you the access to the kernel directly so it's not oriented for newbies. Changing essential kernel-mode objects without enough knowledge will lead you to only one result ... BSoD !

Supported NT versions :
XP/Vista/SEVEN

Kernel Detective gives you the ability to :
1- Detect Hidden Processes.
3- Detect Hidden Threads.
2- Detect Hidden DLLs.
3- Detect Hidden Handles.
4- Detect Hidden Driver.
5- Detect Hooked SSDT.
6- Detect Hooked Shadow SSDT.
7- Detect Hooked IDT.
8- Detect Kernel-mode code modifications and hooks.
9- Disassemble (Read/Write) Kernel-mode/User-mode memory.
10- Monitor debug output on your system.

Enumerate running processes and print important values like Process Id, Parent Process Id, ImageBase, EntryPoint, VirtualSize, PEB block address and EPROCESS block address. Special undocumented detection algorithms were implemented to detect hidden processes.

Detect hidden and suspicious threads in system and allow user to forcely terminate them .

Enumerate a specific running process Dynamic-Link Libraries and show every Dll ImageBase, EntryPoint, Size and Path. You can also inject or free specific module.

Enumerate a specific running process opened handles, show every handle's object name and address and give you the ability to close the handle.

Enumerate loaded kernel-mode drivers and show every driver ImageBase, EntryPoint, Size, Name and Path. Undocumented detection algorithms were implemented to detect hidden drivers.

Scan the system service table (SSDT) and show every service function address and the real function address, detection algorithm improved to bypass KeServiceDescriptorTable EAT/IAT hooks.You can restore single service function address or restore the whole table.

Scan the shadow system service table (Shadow SSDT) and show every shadow service function address and the real function address. You can restore single shadow service function address or restore the whole table

Scan the interrupts table (IDT) and show every interrupt handler offset, selector, type, Attributes and real handler offset. This is applied to every processor in a multi-processors machines.

Scan the important system kernel modules, detect the modifications in it's body and analyze it. For now it can detect and restore inline code modifications, EAT and IAT hooks. I'm looking for more other types of hooks next releases of Kernel Detective.

A nice disassembler rely on OllyDbg disasm engine, thanks Oleh Yuschuk for publishing your nice disasm engine .With it you can disassemble, assemble and hex edit virtual memory of a specific process or even the kernel space memory. Kernel Detective use it's own Read/Write routines from kernel-mode and doesn't rely on any windows API. That make Kernel Detective able to R/W processes VM even if NtReadProcessMemory/NtWriteProcessMemory is hooked, also bypass the hooks on other kernel-mode important routines like KeStackAttachProcess and KeAttachProcess.

Show the messages sent by drivers to the kernel debugger just like Dbgview by Mark Russinovich. It's doing this by hooking interrupt 0x2d wich is responsible for outputing debug messages. Hooking interrupts may cause problems on some machines so DebugView is turned off by default, to turn it on you must run Kernel Detective with "-debugv" parameter.

Tool Updated: Filter Monitor

Tue, 20 Oct 2009 21:33:29 GMT

Listed in categories: Kernel Filter Monitoring Tools

Most recent version:
1.1.0

Most recent release date:
October 20, 2009

Description:
This utility can list kernel mode filters and also unregister them. Monitored filters are, for instance, registry filters, create process and thread notifications. FilterMon comes both for x64 and x86 and it should work on all Windows systems from Vista RTM to Windows 7 RTM. However, I only tested it on Windows 7 RTM on x64 and I can't guarantee that it will work on future versions of Windows as it relies heavily on system internals.

As you probably all know the Service Descriptor Table has been a playground on x86 for all sorts of things: rootkits, anti-viruses, system monitors etc. On x64 modifying the Service Descriptor Table is no longer possible, at least not without subverting the Patch Guard technology.

Thus, programs have now to rely on the filtering/notification technologies provided by Microsoft. And that's why I wrote this little utility which monitors some key filters.

Since I haven't signed the driver of my utility, you have to press F8 at boot time and then select the "Disable Driver Signature Enforcement" option. If you have a multiple boot screen like myself, then you can take your time. Otherwise you have to press F8 frenetically to not miss right moment.

Tool Updated: GMER

Tue, 15 Sep 2009 21:44:21 GMT

Listed in categories: Kernel Hook Detection Tools

Most recent version:
1.0.15.15087

Most recent release date:
September 15, 2009

Description:
GMER is an application that detects and removes rootkits .

It scans for:
* Hidden processes
* Hidden threads
* Hidden modules
* Hidden services
* Hidden files
* Hidden Alternate Data Streams
* Hidden registry keys
* Drivers hooking SSDT
* Drivers hooking IDT
* Drivers hooking IRP calls
* Inline hooks

GMER also allows to monitor the following system functions:
* Processes creating
* Drivers loading
* Libraries loading
* File functions
* Registry entries
* TCP/IP connections

GMER runs on Windows NT/W2K/XP/VISTA

Tool Added: System Virginity Verifier

Thu, 05 Feb 2009 12:10:02 GMT

Listed in categories: Kernel Hook Detection Tools, Usermode Hook Detection Tools

Most recent version:
2.3

Most recent release date:
February 27, 2005

Description:
Joanna Rutswoka provides on her site (invisiblethings.org) interesting papers and tools about rootkits since a few years and is a well known contributors on the official rootkit web site.

SYSTEM VIRGINITY VERIFIER or SVV is very interesting because it checks the system for malicious hooking and also checks the integrity of code section modules directly in memory.

After the verification, SVV notifies the user with five level of infection or seriousness:

-level 0: 100% Virgin (not expected to ocuur in the wild);
-level 1: Seems ok;
-level 2: Innocent hooking detected;
-level 3: Very suspected but may be a false positive;
-level 4: compromised.

The final verdict uses a color codification from blue to deepred.
Resource: the SVV powerpoint presentation (available at invisiblethings.org).

It's important to note that many softwares can interfere with the verdict: antivirus such as Kaspersky, desktop intrusion systems which operate at a low level like AntiHook, ProcessGuard and so on.

SVV in action:

After rebooting the PC in the diagnose mode, SVV gives its first verdict:

Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:WINDOWSsystem32>svv check /m
module ntoskrnl.exe [0x804d7000 - 0x806ebf80]: 0x804db4f0 [RtlPrefetchMemoryNonTemporal()+0] 1 byte(s): exclusion filter: single byte modification
file :c3
memory :90
verdict = 1

0x804dc032 18 byte(s): exclusion filter: KeFlushCurrentTb()
file :d8 0f 22 d8 c3 0f 20 e0 25 7f ff ff ff 0f 22 e0 0d 80
memory :e0 25 7f ff ff ff 0f 22 e0 0d 80 00 00 00 0f 22 e0 c3
verdict = 1

0x804dc04a 1 byte(s): exclusion filter: single byte modification
file :c3
memory :00
verdict = 1

0x804df16a 1 byte(s): exclusion filter: single byte modification
file :05
memory :06
verdict = 1

module ntoskrnl.exe: end of details

SYSTEM INFECTION LEVEL: 1
0 - BLUE
--> 1 - GREEN
2 - YELLOW
3 - ORANGE
4 - RED
5 - DEEPRED

Nothing suspected was detected.

Level 1/Green: this a good news for a beginning.

Now let's hook some windows APIs and let's see the new verdict:

Microsoft Windows XP [version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:WINDOWSsystem32>svv check /m
ntoskrnl.exe (804d7000 - 806ebf80)... module ntoskrnl.exe [0x804d7000 - 0x806ebf80]:
0x804db4f0 [RtlPrefetchMemoryNonTemporal()+0] 1 byte(s): exclusion filter: single byte modification
file :c3
memory :90
verdict = 1

0x804dc032 18 byte(s): exclusion filter: KeFlushCurrentTb()
file :d8 0f 22 d8 c3 0f 20 e0 25 7f ff ff ff 0f 22 e0 0d 80
memory :e0 25 7f ff ff ff 0f 22 e0 0d 80 00 00 00 0f 22 e0 c3
verdict = 1

0x804dc04a 1 byte(s): exclusion filter: single byte modification
file :c3
memory :00
verdict = 1

0x804df16a 1 byte(s): exclusion filter: single byte modification
file :05
memory :06
verdict = 1

0x804e72c4 [ExAllocatePoolWithQuotaTag()+0] 6 byte(s): JMPing code (jmp to: 0xbab1dbfc)
address 0xbab1dbfc is inside TRACE.SYS module [0xbab1a000-0xbab26000]
target module path: ??C:DOCUMENTS AND SETTINGSMICHELMES DOCUMENTSKAPIMON
2TRACE.SYS
file :8b ff 55 8b ec 51
memory :ff 25 fc db b1 ba
verdict = 2

0x804eb321 [ExAllocatePoolWithTagPriority()+0] 6 byte(s): JMPing code (jmp to: 0xbab1dba4)
address 0xbab1dba4 is inside TRACE.SYS module [0xbab1a000-0xbab26000]
target module path: ??C:DOCUMENTS AND SETTINGSMICHELMES DOCUMENTSKAPIMON
2TRACE.SYS
file :8b ff 55 8b ec 53
memory :ff 25 a4 db b1 ba
verdict = 2

module ntoskrnl.exe: end of details

SYSTEM INFECTION LEVEL: 2
0 - BLUE
1 - GREEN
--> 2 - YELLOW
3 - ORANGE
4 - RED
5 - DEEPRED

Nothing suspected was detected.

Tool Added: Memoryze

Thu, 05 Feb 2009 11:58:01 GMT

Listed in categories: Kernel Hook Detection Tools, Memory Dumpers

Most recent version:

Most recent release date:

Description:
MANDIANT Memoryze is free memory forensic software that helps incident responders find evil in live memory. Memoryze can acquire and/or analyze memory images, and on live systems can include the paging file in its analysis.

MANDIANT Memoryze can:

* image the full range of system memory (not reliant on API calls).
* image a process’ entire address space to disk. This includes a process’ loaded DLLs, EXEs, heaps, and stacks.
* image a specified driver or all drivers loaded in memory to disk.
* enumerate all running processes (including those hidden by rootkits). For each process, Memoryze can:
o report all open handles in a process (for example, all files, registry keys, etc.).
o list the virtual address space of a given process including:
+ displaying all loaded DLLs.
+ displaying all allocated portions of the heap and execution stack.
o list all network sockets that the process has open, including any hidden by rootkits.
o output all strings in memory on a per process basis.
* identify all drivers loaded in memory, including those hidden by rootkits.
* report device and driver layering, which can be used to intercept network packets, keystrokes and file activity.
* identify all loaded kernel modules by walking a linked list.
* identify hooks (often used by rootkits) in the System Call Table, the Interrupt Descriptor Tables (IDTs), and driver function tables (IRP tables).

MANDIANT Memoryze can perform all these functions on live system memory or memory image files – whether they were acquired by Memoryze or other memory acquisition tools.

Tool Updated: Rootkit Unhooker

Tue, 03 Feb 2009 23:13:11 GMT

Listed in categories: Kernel Hook Detection Tools

Most recent version:
3.8.342.554

Most recent release date:
Sep 21, 2008

Description:
Rootkit Unhooker LE (RkU) is an advanced rootkit detection/removal utility, designed specially for advanced users and IT professionals. It runs under 32bit Windows 2000, Windows XP, Windows 2003 Server and Windows Vista.

The project was discontinued when it was bought up by Microsoft in November 2007.

Project continued by DiabloNova.
Last announcement:
http://www.rootkit.com/blog.php?newsid=912
Direct D/L:
http://www.rootkit.com/vault/DiabloNova/RkU3.8.342.554.rar

Tool Updated: XADT eXtensible Anti-Debug Tester

Tue, 23 Sep 2008 11:10:53 GMT

Listed in categories: Anti Debug Test Tools

Most recent version:
1.4

Most recent release date:
September 22, 2008

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

Tool Added: SDT Cleaner

Tue, 29 Jul 2008 08:53:56 GMT

Listed in categories: Kernel Hook Detection Tools

Most recent version:
1.0

Most recent release date:

Description:
SDT Cleaner is a tool that intends to clean the SSDT (system service descriptor table) from hooks.

* The SDT Cleaner allows you to clean hooks installed by Anti-Virus and Firewalls.
* This little tool (in this first release) tries to collect info from your current kernel and then switches to kernel land and if there are any hooks in SSDT, this tool will replace them with the original entries.

Tool Added: SSDT Revealer

Mon, 28 Apr 2008 10:42:20 GMT

Listed in categories: Kernel Hook Detection Tools

Most recent version:
1.0

Most recent release date:
March 20, 2007

Description:
This is little tool I’ve coded some times ago. The name says it all, it reveals System Service Dispatch Table showing possible hooks over one or more functions. It was born as a part of a more complex tool, which is still unfinished.. SSDT revealer is nothing special but could come in handy.

The program has been developed under Win-XP. It should run on other OSs but I really don’t know. Again, it’s a personal program and I didn’t spend nights and nights trying to find one or more bug, when a bug occours I fix it. If you find a bug or something else, please, don’t hesitate to contact me.

Tool Added: RAIDE

Thu, 06 Mar 2008 10:30:40 GMT

Listed in categories: Kernel Hook Detection Tools

Most recent version:
Beta 1

Most recent release date:
August 6, 2006

Description:
RAIDE stands for Rootkit Analysis Identification Elimination. RAIDE is a rootkit detection/removal tool. RAIDE offers unique features like process dumping/firewall identification etc.

Tool Updated: Anti Olly Tester

Sat, 29 Dec 2007 02:59:54 GMT

Listed in categories: Anti Debug Test Tools

Most recent version:
1.0

Most recent release date:
August 25, 2006

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

Tool Added: HookExplorer

Sat, 20 Oct 2007 16:36:11 GMT

Listed in categories: Anti Hook Test Tools

Most recent version:

Most recent release date:
March 16, 2006

Description:
HookExplorer is a small utility designed to scan a target process and identify any user land hooks that may be installed by unknown code.

Detects IAT and detours style hooks, and allows the user to define an 'ignore list' to help cut through results.

Tool Updated: SourPill VM Detector

Fri, 19 Oct 2007 21:01:57 GMT

Listed in categories: VM Detection Test Tools

Most recent version:
1.0

Most recent release date:
August 17, 2007

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.