This article includes description of simple unhooker that restores original System Service Table hooked by unknown rootkits, which hide some services and processes.
1. Rootkit detection algorithm
Let’s develop a simple driver to detect and delete SST hooks. Therefore, our solution should not use Zw-functions and SST, as it is supposed that System Service Table is corrupted by malware.
In this article, I am not going to pay attention to filter driver and function code splicers. However, I will probably do it in future.
Comparing current SST with the initial one located in ntoskernel.exe is the easiest way for hooks detecting and removing.
We should perform the following steps:
- Find ntoskernel module in memory.
- Find ntoskernel section, where SST is located, and calculate relative SST offset in section.
- Find ntoskernel section in ntoskernel.exe.
- Calculate real SST address in file.
- Read values from file and compare them with SST.
Before implementation, we’ll consider memory-mapped files in kernel mode.
2. Memory-mapped files in kernel mode
According to Wikipedia, memory-mapped file is a virtual memory segment that has been assigned a direct byte-for-byte correlation with some portion of a file or file-like resource.
We are going to use memory-mapped files in kernel mode, as they are quite useful for parsing PE file. In addition, their API is really easy-to-use, as it is rather similar to Win32 API.
MapViewOfSection functions in kernel mode, driver will access the following functions:
Unfortunately, using these functions will break our rule about not using SST. In addition, it is good for antirootikit to use extremely low-level functions in order to be invisible to possible rootkits. Thus, we can use undocumented Memory Manager (Mm) functions (at our own risk, of course):
Example above shows alternative approach of using mapped files in the
Introduced solution is pretty good, as it doesn’t use or even handle
Zw* functions. Unfortunately, there is one restriction. If you start demonstrated example from
DriverEntry, it will work fine, but if you start it from the
IRP_MJ_DEVICE_CONTROL handler, the MmCreateSection function will fail with
Why it happens?
The answer is simple.
Zw* functions set previous mode to
KernelMode, which allows to use kernel mode pointers and handlers as parameters (learn more details at Nt vs. Zw – Clearing Confusion On The Native API article).
DriverEntry or the system thread can call considered function.
3. Implementation of the antirootkit algorithm
The following structure saves all ntoskernel parsing results:
Antirootkit algorithm implementation:
The following function returns real SST value:
Main functionality implementation:
Cycle above completely deletes all SST hooks and brings SST to its virgin state.
4. SST unhooker demonstration
We have considered steps for developing a simple console utility named “unhooker.exe” for testing purposes. We can start it with no parameters; in this case, it will show information about its abilities:
- 1. The “stat” command shows statistics about SST hooking.
- 2. The “unhook” command cleans up SST.
The following example demonstrates how to use utility to detect and delete hooks:
5. Anti-rootkit building
Steps for unhooker building are just as ones, described in the “Hide Driver” article:
- Install Windows Driver Developer Kit 2003 http://www.microsoft.com/whdc/devtools/ddk/default.mspx
- Set global environment variable “BASEDIR” to path of installed DDK. Go here: Computer -> Properties -> Advanced -> Environment variables ->System Variables -> New
And set it like this: BASEDIR -> c:\winddk\3790
(You have to restart your computer after this.)
- If you choose Visual Studio 2003, then you can simply open UnhookerMain.sln and build it all.