SanityCheck utility

Hi, I just wrote SanityCheck XE. Here’s what it does: This software checks
running kernel modules, processes, threads, object types and DPCs, and
checks the modules in which related routines reside. It’s intended to reveal
misbehaving third party drivers.

-Get all driver objects in the system along with their related driver files,
image base addresses, sizes, driver init routines, start I/O, unload and
function routines. Then it checks all those addresses and displays the
drivers in which these addresses reside so if any of your driver objects are
hijacked it will be easy to find out.

-Get a list of DPCs in the system and see of what type and kind they are
(threaded DPCs will be revealed). It will show related device objects,
related driver names and will check in what kernel modules are pointing the
DeferredProcedures. If any DPCs are legally hijacked, this software will let
you find out.

-Get all device objects in the system along with their related drivers along
with a bunch of info.

-Get all object types and check their type intializers and display the names
of the kernel modules in which their open, close, parse, dump, delete and
security routines are pointing. Makes it easy

-Get all processes. It uses six unmentioned ways to detect processes, giving
hidden processes really little chance.
-Get all threads in the system and display them with along with a bunch of
info.

Note: this software is not intended as an anti-rootkit software but as a
utility to find interop issues with misbehaving third-party drivers.
It may take ages to detect these things using standard WinDbg. This software
runs on Windows 2000-2008 and everything in between (x86 and x64 editions).
This software has been thoroughly tested, verified and unverified on a bunch
of OSes and runs without problems. If this software does crash on a certain
service pack, please drop me a line. This is a read-only driver, it loads,
gets information and unloads leaving the kernel in an unaltered state. It
does NOT make use of any undocumented system calls but yes, makes use of
undocumented structures. The software relies on a GlobalFlags registry
setting, the program sets and restores this upon request.

Download it from here:
http://www.resplendence.com/download/sanityxe.zip

Note: no help is provided. Any comments will be appreciated.

//Daniel

> -Get all driver objects in the system along with their related driver files, image

base addresses, sizes, driver init routines, start I/O, unload and function routines

How can it be possibly done??? Look - if a driver removes itself from the list of loaded kernel modules
(it can be done via DRIVER_SECTION structure that one of DRIVER_OBJECT’s undocumented fields points to), you just have no chance to see it anywhere…

-Get a list of DPCs in the system

The same story…

Get all device objects in the system along with their related drivers along with a bunch of info.

The same story…

-Get all object types and check their type intializers and display the names of the kernel
modules in which their open, close, parse, dump, delete and security routines are pointing.

Again, the same story…

-Get all processes. It uses six unmentioned ways to detect processes, giving hidden
processes really little chance.

This, indeed, can be done, because it does not make sense to hide threads from the scheduler - by doing so you are going to put your thread out of play. Therefore, by examining threads you can discover which process they belong to, and, hence, detect all processes in the system. However, please note that malicious thread can easily present itself as the one that belongs to a “good” process that is always known to be around - it will just execute the code of a module that it will remove from the list of modules that you can arrive to via PEB. For the practical purposes, it is exactly the same thing as a hidden process…

Note: this software is not intended as an anti-rootkit software but as a utility to find
interop issues with misbehaving third-party drivers.

Well, some “misbehaving third-party drivers” may, from the technical standpoint, be exactly the same rootkits, which is particularly true for a security software.

The bottom line - the absolute maximum that your detection tool is able to do is just to say that the system is compromised. However, if misbehaving driver takes some extra steps to hide itself, in some cases your tool just has no chance “to name and shame” it - everything depends on how far the culprit goes…

Anton Bassov

wrote in message news:xxxxx@ntdev…
>> -Get all driver objects in the system along with their related driver
>> files, image
>> base addresses, sizes, driver init routines, start I/O, unload and
>> function routines
>
> How can it be possibly done??? Look - if a driver removes itself from the
> list of loaded kernel modules
> (it can be done via DRIVER_SECTION structure that one of DRIVER_OBJECT’s
> undocumented fields points to), you just have no chance to see it
> anywhere…
>
…
> The bottom line - the absolute maximum that your detection tool is able to
> do is just to say that the system is compromised. However, if >misbehaving
> driver takes some extra steps to hide itself, in some cases your tool just
> has no chance “to name and shame” it - everything >depends on how far the
> culprit goes…

DRIVER_OBJECTs and a lots other objects are just about everywhere in the
system. Just unlinking itself from the object type list is not going to be
enough. As there are really many methods of detecting objects, every way an
attempt is made to hide an object at the same time it introduces as well a
chance for being detected.

Theoretically speaking, this software is at a lost position as soon as the
kernel is compromised. But that is just a commonplace and not much more than
theory. It’s much like saying “look, there is no need for a radar which can
detect stealth airplanes because maybe one day an ufo comes around with
superior technology”. Especially considering the rules every legitimate
software has to follow, there is absolutely no chance they can hide objects
from this software just by patching a bit around. What is really needed is
to either target this software directly (I admit it can easily be done but
that is not going to work for already existing software) or completely
rebuild the kernel from source.

//Daniel

> DRIVER_OBJECTs and a lots other objects are just about everywhere in the system.

Sure -for example, every DEVICE_OBJECT has a pointer to its controlling driver.However, the same trick
can be played on the device as well…

Just unlinking itself from the object type list is not going to be enough.

It has nothing to do with the object type list, which, IIRC, is maintained only if a special flag is set upon the boot, so that under the normal circumstances you cannot get to the list of all objects of a given type via this list - instead, there are separate additional lists that are specific for a given object type (i.e. module list, thread list,etc), and they have no relation to one another…

Strictly speaking, there is even no guarantee that ia culprit will have its driver object, in the first place - instead, it may just allocate memory in its DriverEntry(), relocate its code and data, and that’s it . As long as it does not either register AddDevice() or create device objects in its DriverEntry() it will get unloaded immediately after DriverEntry() returns control. Certainly, execution prevention bit gives its some extra challenges, but if it decides to update PTEs no one stands in its way. Please note that it is not necessarily going to be branded as “malware” -instead, it may be exactly the opposite, i.e. security software. More on it below

Theoretically speaking, this software is at a lost position as soon as the kernel is compromised.

Well, it is still able to detect abnormalities, but it cannot name a culprit. However, if a culprit loads itself before the kernel does, you are totally out of luck - no one, including the OS itself, will be able to detect its presence…

But that is just a commonplace and not much more than theory.

Well, disassemble code on any machine with, say, Kaspersky AV , and you will see that this is not a theory but practice…

Especially considering the rules every legitimate software has to follow, there is absolutely
no chance they can hide objects from this software just by patching a bit around.

Well, these days the very fact of patching the kernel automatically places it on the list of “not-so-legitimate” software, so that it can go all the way. Please note that they may find a perfectly legitimate explanation for this, especially if we are speaking about the security software - they may claim that it it just protects itself from the malware. I am not making it up - for example, if you disassemble, say, NdisSend() on the machine where Kasperky AV is installed, you will see that execution jumps to the area that is not associated with any module, although Kaspersky AV has its “official” driver module as well…

Anton Bassov

Right, a driver can just allocate some memory and execute code in there and
I know it happens a lot but you could hardly call this allocated memory a
separate driver. Note however that nowhere is written that this utility
claims to detect hidden drivers (although it does so to a certain extent).

//Daniel

wrote in message news:xxxxx@ntdev…
> Strictly speaking, there is even no guarantee that ia culprit will have
> its driver object, in the first place - instead, it may just allocate
> memory in its DriverEntry(), relocate its code and data, and that’s it .
> As long as it does not either register AddDevice() or create device
> objects in its DriverEntry() it will get unloaded immediately after
> DriverEntry() returns control. Certainly, execution prevention bit gives
> its some extra challenges, but if it decides to update PTEs no one stands
> in its way. Please note that it is not necessarily going to be branded as
> “malware” -instead, it may be exactly the opposite, i.e. security
> software. More on it below
>