IDA Stealth v1.0 final

What's new?

It's been some time since the last update, so here it is.
Finally, a driver to emulate the return value of the RDTSC instruction has been added, errors in the debug register handling were fixed and the stealthiness of the GetTickCount hook has been improved.

RDTSC emulation

Well, RDTSC emulation is actually rather widely used, so I wanted to include this technique, before releasing a final version.
A common anti debugging trick is to use the RDTSC instruction, which returns a 64 bit time stamp value in the EDX:EAX register pair. Under the assumption that tracing or even halting a program introduces a noticeable delay, an attached debugger can be caught easily by evaluating the deltas between consecutive time stamps. So how can we address this issue?
Those who read the Intel manuals carefully, might have noticed, that the CR4 register has the time stamp disable flag, which can (only) be modified from ring0. If this specific bit is set, the CPU will raise a #GP (general protection fault) every time the RDTSC instruction is executed from a privilege level > 0 aka user mode.
#GP is simply an interrupt (actually fault nr. 13), which means that as soon as the interrupt is fired, the CPU switches to privilege level 0 (i.e. kernel mode) and grabs the associated entry from position 13 in the interrupt descriptor table (IDT). This entry describes an address to the respective interrupt handler. This handler is responsible to somehow deal with this kind of exception.
Now you see how we can hide our debugger from the aforementioned detection technique: we can write a simple driver, which replaces the #GP fault handler with it's own handler. All this handler has to do, is to check if the #GP has actually been caused by a RDTSC instruction (a #GP can occur due to many other reasons) and, if that's the case, return a fake value accordingly. IDAStealth currently allows you to force the driver to always return zero or to let it start with a random value and increase it every time by a given delta.
To additionally increase stealthiness, the driver is optionally given a random name each time it is loaded, so it cannot be easily unmasked by scanning all loaded driver modules for suspicious names.
Important note: when using this option, you must be sure to NOT have two or more instances of this driver running at the same time, because there is no way for IDAStealth to check if another instance already started this driver (this is the whole purpose of driver object name randomization!). If those drivers aren't unloaded in the exact opposite order they were started, the system will crash when each driver tries to restore the original handler in the IDT. This is due to the fact that each driver doesn't know (or can't know) that the respective IDT entry has already been hooked by another instance.

If you want to build the driver by yourself, you will need the DDK and the ddkbuild script. The source code is heavily commented and I tried to use as few inline assembler as possible.

Armadillo 4.x

IDAStealth had a bug in the GetThreadContext hook, causing the emulation routine to always return the complete thread context for the given thread, even if the caller only asked for the debug registers. Some versions of Armadillo detect this misbehavior and eventually enter an endless loop if a call to the GetThreadContext API returns "more information as requested".

GetTickCount hook

The implementation of the GetTickCount hook was flawed, because after a few iterations the returned value would drop to zero and never change that value again.
The new GetTickCount hook now always mimics the original algorithm of the API and uses the performance counter to initialize an internal 64 bit value. This internal tick counter is feed into the original algorithm. The delta by which this counter is increased every time the handler is executed can be adjusted from the IDAStealth GUI.

ToDo

The new version passes all tests in xADT besides the "find tool complex" (which I don't consider to have any meaning in practice) and the new NtSystemDebugControl test. This test seems to be very unreliable: sometimes the debugger was detected, sometimes not (tested on XP SP3).
The rootkit based test always made the application crash and I didn't investigate why the crash occurred anyway.
If your favorite packer is still able to detect the IDA debugger or if anything isn't working as expected, please let me know and I will try to fix it.
Everything else as usual on the IDAStealth site.