MJ0011内核研究所——基于CallStack的AntiRootkitHOOK检测思路

1、.基于CallStack的Anti-Rootkit HOOK检测思路：MJ00112007-11-2th_decoderAnti-Rootkit目前扫描Hook的方法主要有以下几种:1.对抗inline -hook ,IAT/EAT HookAnti-Rootkit使用读取磁盘上系统文件并将之进行map重定位后，同内存中的代码进行对比的方法来检测inline hook(或EAT/IAT HOOK，后同）,类似的工具例如Rootkit Unhooker, gmer, Icesword等等为了对抗Anti-Rootkit的inline Hook扫描,Rootkit们使用一些方法来进行自己HOOK的

2、隐藏例如Shadow Walker的方法，HOOK Int 0Eh缺页中断来隐藏内存中被HOOK的代码或者是例如流氓软件CNNIC中文上网，HOOK FSD的IRP_MJ_READ,当读取到ntfs.sys等文件时，修改数据，将错误的结果返回回去，导致Anti-rootkit工具误认为内存中的代码是正确的多种方式都可以让这种传统的INLINE HOOK检测方法失效2.Object HookObject Hook一般更隐藏，更难检测为大家所熟知的Object hook例如有修改driver object中的MajorFunction dispatch表或者是hook KeyObject(KCB)

3、中的一些call back routine/GetCell Routine(zzzzevazzzz放出过相关代码）又或者是hook Object中一些其他的通用链中的代码指针来进行自我隐藏/保护功能(例如tombkeeper的一些文章提到的细节)目前的办法一般是扫描这些OBJECT的结构,找到对应指针，利用特征搜索、模块范围对比等方法，检测他们是否被HOOK类似的工具例如 rootkit unhooker,gmer(rootkit unhooker中检测的object hook较多）但这些工具都只能检测他们已知的object hook一旦Rootkiter利用未知的object hook进行隐

4、藏，或者是转换平台，数据结构发生变化，就很难检测到object hook, 传统的Object hook检测方式也很容易被rootkiter饶过，详见我的<<绕过现代Anti-Rookit工具的内核模块扫描>>一文这里提出一种新的hook检测方式: 即利用CallStack进行HOOK检测让我们来看一种典型的rootkit的HOOK方式:例如hook FileSystemNtfs的 IRP_MJ_DIRECTORY_CONTROL来进行文件隐藏，有上相关的代码它们的代码通常是这样的NTSTATUS HookFsd(LPCWSTR DrvName)/.获得ntf

5、s的driver objectg_OldNtfsDriCtl = drvobj->MajorFunctionIRP_MJ_DIRECTORY_CONTROL;/保存原始的dispatch 地址drvobj->MajorFunctionIRP_MJ_DIRECTORY_CONTROL = MyNtfsDriCtl ;/用自己的dispatch 地址替换原始地址/,NTSTATUS   MyNtfsDriCtl(PDEVICE_OBJECT devobj , PIRP pIrp)NTSTATUS stat ;/一些初始化处理._asmpush pIrppush de

6、vobjcall g_OldNtfsDriCtlmov stat ,eax/首先调用原始函数,以便得到结果/下面进行处理，hack CompletionRoutine,或者是直接修改 UserBuffer的数据/.上面就是一个hook fsd来隐藏文件的ROOTKIT的大概结构让我们来看看，在MyNtfsDriCtl中call g_OldNtfsDriCtl时，发生了什么？它会跳转到原始的g_OldNtfsDriCtl中，并且保存返回地址，这个返回地址在哪儿？rootkit的代码体内！那么就简单了，我们简单地Hook 原始dispatch中的更深层的地方，例如，Ntfs的DriectoryCo

7、ntrol快结束时会call KeLeaveCriticalRegion或者IofCompleteRequest我们HOOK这个地方，然后，当这个调用触发时，我们检查esp,并向上回溯堆栈，找到call stack，我们发现了什么？哈哈！rootkit的返回地址！再简单的使用ZwQuerySystemInformation,就可以知道这个地址位于哪个模块中，ROOTKIT定位成功！（如果抹去了模块，可以定位这块内存为unknow image)这样，只要HOOK特定的地方，再在ring3调用相关服务，触发hook,检查call stack，就可以轻松得到rootkit的返回地址了(或者hooke

8、r的返回地址，不一定是rootkit :p )示例代码就不写了，有几个注意问题:1.call stack中会有其他一些系统的模块或者硬件驱动的模块，要考虑如何把他们区分出来的问题，相信这个很简单了,呵呵2.使用这种方式，只要你HOOK的地方正确恰当可以检测到90%以上的object hook,无论object结构如何变化，或者是未知的object hook,或者使用一些方式进行object hook的隐藏(例如<<绕过现代Anti-Rookit工具的内核模块扫描>>中提到的方法),都会被检测出来但并非所有的inline hook方式都可能被检测出来，例如修改被HOOK函数参数后使用jump 指令而不是call指令跳转到原始函数，这样就检测不出来另外HOOK的位置也十分关键，HOOK的位置不