为了对抗Anti-Rootkit的inline Hook扫描,Rootkit们使用一些方法来进行自己HOOK的隐藏。

　　例如Shadow Walker的方法，HOOK Int 0Eh缺页中断来隐藏内存中被HOOK的代码，或是例如某中文上网，HOOK FSD的IRP_MJ_READ，当读取到ntfs.sys等文件时，修改数据，将错误的结果返回回去，导致Anti-rootkit工具误认为内存中的代码是正确的。多种方式都可以让这种传统的INLINE HOOK检测方法失效。

　　2.Object Hook

　　Object Hook一般更隐藏，更难检测。

　　为大家所熟知的Object hook例如有修改driver object中的MajorFunction dispatch表，或是hook KeyObject(KCB)中的一些call back routine/GetCell Routine(zzzzevazzzz放出过相关代码)，又或者是hook Object中一些其他的通用链中的代码指针来进行自我隐藏/保护功能(例如tombkeeper的一些文章提到的细节)

　　目前的办法一般是扫描这些OBJECT的结构，找到对应指针，利用特征搜索、模块范围对比等方法，检测他们是否被HOOK。类似的工具例如 rootkit unhooker,gmer(rootkit unhooker中检测的object hook较多)

　　但这些工具都只能检测他们已知的object hook，一旦Rootkiter利用未知的object hook进行隐藏，或者是转换平台，数据结构发生变化，就很难检测到object hook, 传统的Object hook检测方式也很容易被rootkiter饶过，

　　这里提出一种新的hook检测方式: 即利用CallStack进行HOOK检测

　　让我们来看一种典型的rootkit的HOOK方式:

　　例如hook \\FileSystem\\Ntfs的 IRP_MJ_DIRECTORY_CONTROL来进行文件隐藏，rootkit.com有上相关的代码

　　它们的代码通常是这样的


　　上面就是一个hook fsd来隐藏文件的ROOTKIT的大概结构。

　　让我们来看看，在MyNtfsDriCtl中call g_OldNtfsDriCtl时，发生了什么?

　　它会跳转到原始的g_OldNtfsDriCtl中，并且保存返回地址，这个返回地址在哪儿?rootkit的代码体内!

　　那么就简单了，我们简单地Hook 原始dispatch中的更深层的地方，例如，Ntfs的DriectoryControl快结束时会call KeLeaveCriticalRegion或IofCompleteRequest

　　我们HOOK这个地方，然后，当这个调用触发时，我们检查esp，并向上回溯堆栈，找到call stack，我们会发现rootkit的返回地址。

　　再简单的使用ZwQuerySystemInformation，就可以知道这个地址位于哪个模块中，ROOTKIT定位成功!(如果抹去了模块，可以定位这块内存为unknow image)。这样，只要HOOK特定的地方，再在ring3调用相关服务，触发hook，检查call stack，就可以轻松得到rootkit或hooker的返回地址。

　　需要注意几个问题:

　　1.call stack中会有其他一些系统的模块或者硬件驱动的模块，要考虑如何把他们区分出来的问题，相信这个很简单了,呵呵

　　2.使用这种方式，只要你HOOK的地方正确恰当

　　可以检测到90%以上的object hook，无论object结构如何变化，或者是未知的object hook，或者使用一些方式进行object hook的隐藏。

　　但并非所有的inline hook方式都可能被检测出来，例如修改被HOOK函数参数后使用jump 指令而不是call指令跳转到原始函数，这样就检测不出来，另外HOOK的位置也十分关键，HOOK的位置不对，一些ROOTKIT可能HOOK的路径就会被放过，HOOK得过深的话，进程context就会丢失，这样判断上就会有一定的困难。

　　3.call stack的分析方法，这个也很简单了，这里就不多说了