Anti-Rootkit目前扫描Hook的方法主要有以下几种:
1.对抗inline -hook ,IAT/EAT Hook
Anti-Rootkit使用读取磁盘上系统文件并将之进行map\重定位后，同内存中的代码进行对比的方法来检测inline hook(或EAT/IAT HOOK，后同),类似的工具例如Rootkit Unhooker, gmer, Icesword等等。
为了对抗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有上相关的代码
它们的代码通常是这样的
NTSTATUS HookFsd(LPCWSTR DrvName)
{
//....获得ntfs的driver object
g_OldNtfsDriCtl = drvobj->MajorFunction[IRP_MJ_DIRECTORY_CONTROL];
//保存原始的dispatch 地址
drvobj->MajorFunction[IRP_MJ_DIRECTORY_CONTROL] = MyNtfsDriCtl ;
//用自己的dispatch 地址替换原始地址
//,,,,,
}
NTSTATUS MyNtfsDriCtl(PDEVICE_OBJECT devobj , PIRP pIrp)
{
NTSTATUS stat ;
//一些初始化处理.....
__asm
{
push pIrp
push devobj
call g_OldNtfsDriCtl
mov stat ,eax
}
//首先调用原始函数,以便得到结果
//下面进行处理，hack CompletionRoutine,或者是直接修改 UserBuffer的数据
//...
}
上面就是一个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的分析方法，这个也很简单了，这里就不多说了