Win2K/XP SDT Restore 0.2 (Proof-Of-Concept)
by Tan Chew Keong
Released : 06 Jul 2004
Updated : 09 Oct 2004 (paper available for download)
Download Paper Presented at HITB 2004
Win32 Kernel Rootkits modify the behaviour of the system by Kernel Native API hooking. This technique is typically implemented by modifying the ServiceTable entries in the Service Descriptor Table (SDT). Such modification ensures that a replacement (hook) function installed by a rootkit is called prior to the original native API. The replacement function usually calls the original native API and modifies the output before returning the results to the user-space program. This technique allows kernel rootkits to hide files, processes, and to prevent process termination.
This proof-of-concept tool demonstrates the possibility of defeating such rootkits by removing Kernel Native APIs hooks and restoring the ServiceTable entries back to their original state.
In Windows, user-space applications request for system services by calling the APIs exported by the various DLLs. For example, to write data to an open file, pipe or device, the WriteFile API that is exported by kernel32.dll is usually used. Within kernel32.dll, the implementation of WriteFile API in turn calls the ZwWriteFile native API that is exported by ntdll.dll. The work done by ZwWriteFile is actually performed in kernel-space. Hence, the implementation of ZwWriteFile in ntdll.dll contains only minimal code to transit into kernel-space using interrupt 0x2E. The disassembly of ZwWriteFile is shown below.
1- MOV EAX, 0ED
2- LEA EDX, DWORD PTR SS:[ESP+4]
3- INT 2E
4- RETN 24
The magic number 0ED in line 1 is the Service Number for ZwWriteFile. It will be used to offset into the ServiceTable (System Service Dispatch Table) in kernel-space to locate the address of the function that implements the writefile service. The address of the ServiceTable can be found within the Service Descriptor Table (SDT). The Service Descriptor Table can be referenced using the exported KeServiceDescriptorTable symbol. This is a structure with the following definition.
typedef struct ServiceDescriptorTable {
SDE ServiceDescriptor[4];
} SDT;
typedef struct ServiceDescriptorEntry {
PDWORD ServiceTable;
PDWORD CounterTableBase;
DWORD ServiceLimit;
PBYTE ArgumentTable;
} SDE;
The first member of the structure, SDT.ServiceDescriptor[0].ServiceTable, is an array of function pointers to the service functions. The DWORD value at ServiceTable[0xED] is a function pointer to NtWriteFile, which contains the actual code to write to files, pipes or devices. Hence, to modify the behaviour of the user-space WriteFile API, one simply needs to write a replacement function, load it into kernel space as a driver, and modify ServiceTable[0xED] to point to the replacement function. The replacement function needs to keep the original function pointer (original value of ServiceTable[0xED]) so that it can be called to perform the original defined function.
Example One - Process Hiding by Hooking ZwQuerySystemInformation
User-space programs can use the ToolHelp APIs to obtain a list of all running processes. The ToolHelp APIs in turn calls the ZwQuerySystemInformation native API exported by ntdll.dll to obtain the list. To hide processes, a kernel-space rootkit, which is loaded as a driver, can modify the function pointer at ServiceTable[0x97] (ZwQuerySystemInformation) to redirect the call to a replacement function. The replacement function first calls the original ZwQuerySystemInformation API to obtain an array containing information of all running process. The returned array is then modified to remove the entry containing the process to be hidden. Finally, the modified result is returned to the user-space program. This effectively prevents the user-space program from "seeing" the hidden process.
Example Two - Driver/Module Hiding by Hooking ZwQuerySystemInformation
User-space programs can obtain a list of all loaded drivers using the ZwQuerySystemInformation native API, specifying SystemModuleInformation as its first parameter. As mentioned earlier, ZwQuerySystemInformation is exported by ntdll.dll and can be called directly by user-space programs. In kernel-space, the ZwQuerySystemInformation native API obtains the list of loaded drivers by traversing the PsLoadedModuleList. A kernel-space rootkit can manipulate the results returned by ZwQuerySystemInformation by modifying ServiceTable[0x97] (ZwQuerySystemInformation) to point to a replacement fnuction. The replacement function will first call the original ZwQuerySystemInformation to get an array of all loaded drivers. The driver to be hidden (i.e. the rootkit) is then removed from the array. This manipulated array is returned to the user-space program.
This POC code restores the values of the ServiceTable entries by writing directly to \device\physicalmemory. Hence, it works entirely in user-space and do not need to load a driver. The following steps describe how the code works.
Use NtOpenSection to get a handle to \device\physicalmemory with SECTION_MAP_READ | SECTION_MAP_WRITE access. If this fails, modify the DACL of \device\physicalmemory by adding SECTION_MAP_WRITE access permission to the current user. Try to open \device\physicalmemory again.
Load ntoskrnl.exe into memory with proper alignment and locate the address of KeServiceDescriptorTable from the export table of ntoskrnl.exe
Use NtMapViewOfSection to map in the physical memory page at the address of KeServiceDescriptorTable.
Get the address of KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable from the page.
Use NtMapViewOfSection to map in the physical memory page containing the running kernel's SerivceTable. This address is available at KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable.
Use the address of KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable to offset into the loaded ntoskrnl.exe
Loop through all entries in KeServiceDescriptorTable.ServiceDescriptor[0].ServiceTable, comparing the copy in the kernel memory with the copy in the loaded ntoskrnl.exe. Restore to kernel memory (i.e. into the mapped page) any discrepancies that are detected. This code works based on the fact that a complete original copy of the ServiceTable exists in ntoskrnl.exe.
C:\>sdtrestore
SDTrestore Version 0.1 Proof-of-Concept by SIG^2 G-TEC (www.security.org.sg)
KeServiceDescriptorTable 8046DFA0
KeServiceDecriptorTable.ServiceTable 804742B8
KeServiceDescriptorTable.ServiceLimit 248
ZwAllocateVirtualMemory 10 --[hooked by unknown at F754CE74]--
ZwCreateFile 20 --[hooked by unknown at F754CA85]--
ZwCreateKey 23 --[hooked by unknown at F754CC5E]--
ZwCreateProcess 29 --[hooked by unknown at F754CDB7]--
ZwDeleteFile 34 --[hooked by unknown at F754C80C]--
ZwGetTickCount 4C --[hooked by unknown at F754CE27]--
ZwLoadDriver 55 --[hooked by unknown at F754CBF2]--
ZwQueryDirectoryFile 7D --[hooked by unknown at F754C6E8]--
ZwQuerySystemInformation 97 --[hooked by unknown at F754C623]--
ZwSetInformationFile C2 --[hooked by unknown at F754C8A8]--
Number of Service Table entries hooked = 10
WARNING: THIS IS EXPERIMENTAL CODE. FIXING THE SDT MAY HAVE GRAVE
CONSEQUENCES, SUCH AS SYSTEM CRASH, DATA LOSS OR SYSTEM CORRUPTION.
PROCEED AT YOUR OWN RISK. YOU HAVE BEEN WARNED.
Fix SDT Entries (Y/N)? : y
[+] Patched SDT entry 10 to 804A257F
[+] Patched SDT entry 20 to 80497EF9
[+] Patched SDT entry 23 to 804B2483
[+] Patched SDT entry 29 to 804A9212
[+] Patched SDT entry 34 to 804D0584
[+] Patched SDT entry 4C to 80463FF2
[+] Patched SDT entry 55 to 8052DC72
[+] Patched SDT entry 7D to 80498541
[+] Patched SDT entry 97 to 80493B5B
[+] Patched SDT entry C2 to 80498C08
This version is tested only on English Win2K SP2 and SP4, WinXP SP0 and SP1.
THIS IS EXPERIMENTAL CODE. FIXING THE SDT MAY HAVE GRAVE CONSEQUENCES, SUCH AS SYSTEM CRASH, DATA LOSS OR SYSTEM CORRUPTION. IT IS RECOMMENDED THAT YOU USE THIS CODE ONLY ON A TEST SYSTEM. PROCEED AT YOUR OWN RISK.
hoglund - original and first public NT ROOTKIT
fuzen_op - FU Rootkit
hf - Hacker Defender
joanna - klister
90210//HI-TECH - phide
90210 - Thanks for the more stable way of finding the address of KiServiceTable.
For further enquries or to submit malicious code for our analysis, email them to the following.
Overall-in-charge: Tan Chew Keong
