Hide Your SSDT HOOK

http://www.rootkit.com/newsread.php?newsid=922



http://hi.baidu.com/only_rainbow/blog/item/4e51af8ebcf82efd513d920b.html
1.目标

A lot of commercial products and rootkits change function pointers in the SSDT kernel to take control over the operating system. But currently no techniques exists to hide these hooks. This short article describes two mechanisms to hide SSDT hooks which anti-rootkit scanner will currently not detect.

许多的商业产品和Rootkit软件通过改变内核中的SSDT表里面的函数指针来到达控制操作系统的目的.但是很 遗憾,当前的技术已经无法隐藏这些HOOK了,那么这边短文描述了两种机制来达到隐藏SSDT HOOK的目的,并且这些都无法被当今的Anti-RootKit工具所检测出来.

2. Hide SSDT hooks by modifying the EAT of loaded drivers
2. 通过修改已加载驱动的导入表来隐藏SSDT HOOK

The first step is to create a complete copy of the unmodified SSDT. Then an image load callback is registered with PsSetLoadImageNotifyRoutine(). The callback is used to parse the IAT (import address table) of new loaded driver. If during parsing an import KeServiceDescriptorTable is found the address is changed to the SSDT copy. Now NtReadFile(), NtCreateFile() and NtMapViewOfSection() are hooked by modifying the real SSDT. The hook handlers of these three functions are used to ensure that it is difficult to get a pointer to the real SSDT.

我们 要做的第一部就是创建一个完全的没有修改的SSDT表的备份.接着利用PsSetLoadImageNotifyRoutine函数建立一个回调函数加 载.这个回调函数用来分析新加载的驱动程序的导入表.如果检测到导入表里面有KeServiceDescriptorTable指针,那么我们修改这个指 针让其指向我们所创建的SSDT备份.此时,我们就可以通过修改真实的SSDT表来达到HOOK NtReadFile(),NtCreateFile()和NtMapViewOfSection()的目的.HOOK这三个函数的就是为了确保驱动程序 很难得到真实的SSDT表的地址.

This technique bypasses about ninety percent of all anti-rootkit tools. Some tools detect the image load callback with is suspicious.Of course there exists mechanism to detect the SSDT modification. One of them is to remove the image load callback or just compare the SSDT address with the bounds of the kernel image.

这个技术可以躲过大概90%的Anti-RootKit工具.一些工具会检测到镜像加载回调函数并表示怀疑(也就是发出警报)..当然,是存在技术可以检测到是否修改了SSDT.其中一个技术就是去掉镜像加载回调函数或者利用内核镜像的地址范围来比较SSDT的地址.

3. Hide SSDT hooks by manipulating the KTHREAD structure
3. 通过修改KTHREAD结构来隐藏SSDT HOOK

The second technique equals to the one described above. Again some copies of kernel structures are made. But now the service table pointer of each thread is changed to one of the copies. If you disassemble KiSystemService you see the resolving of function pointers by using the ServiceTable pointer of the current thread's KTHREAD structure. The ServiceTable pointer is set by KeInitThread() and later by PsConvertToGuiThread(). Depending on the thread type the address of KTHREAD either points to the SSDT or the SSDT-Shadow. The shadow structure contains pointers to functions which are used by GUIs and therefore PsConvertToGuiThread() will change normally the ServiceTable pointer to the SSDT-Shadow. Below you find the KTHREAD structure:

第 二个技术和上面所用到的第一个技术大同小异,同样也是建立一些内核结构的拷贝.但是现在是改变每一个线程里面的SSDT指针,让其指向我们所建立的其中一 个备份.如果你反汇编KiSystemService这个函数的话,那么你会看见它其实是通过每一个线程的线程控制块里面的ServiceTable指针 来得到函数指针的.这个ServiceTable指针是由KeInitThread()函数初始化的,并通过 PsConvertToGuiThread()来构建.通过判断线程的类型知道这个指针是指向SSDT还是Shadow SSDT. Shadow SSDT里面包含了GUIs所要用的到函数指针,所以PsConvertToGuiThread()会改变ServiceTable指针的地址使其指向 Shadow SSDT而不是SSDT.下面你可以看到KTHREAD的结构:

kd> dt !_kthread
nt!_KTHREAD
[...]
+0x0e0 ServiceTable : Ptr32 Void
[...]

To stealth the SSDT hooks by manipulating the KTHREAD structure a copy of the SSDT and the SSDT-Shadow is made. For the next step the SSDT or SSDT-Shadow copy is modified to get control over certain system functions. Now the ServiceTable pointers to the corresponding structures in PsConvertToGuiThread() and KeInitThread() are changed to the copies by modifying the loaded kernel code. Furthermore all threads are enumerated and again the ServiceTable pointers are exchanged.

通 过修改KTHREAD结构来隐藏SSDT HOOk,那么SSDT和Shadow SSDT的备份也应该随之而建立.下一步就是通过修改SSDT或者Shadow SSDT来取得操作系统的控制权限.现在,我们还需要通过修改加载的内核代码使PsConvertToGuiThread()和 KeInitThread()所对应的ServiceTable指针能够正确的指向我们的备份.这样以后所有枚举的线程里面的ServiceTable结 构指针都会被修改.

We have tested the detection of the hidden hooks with anti-rootkit tools like RootkitUnhooker, GMER, SVV and some more tools. None of them detected the kernel code and KTHREAD modification.

我们已经利用一些Anti-RootKit工具来检测这些隐藏的HOOKS,比如RootkitUnhooker, GMER, SVV等等,没有一个能够检测出内核代码以及KTHREAD结构的修改.]