基于CallStack的Anti-Rootkit HOOK检测思路：

基于CallStack的Anti-Rootkit HOOK检测思路：

MJ0011
2007-11-2
th_decoder@126.com

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的代码

或者是例如流氓软件CNNIC中文上网，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饶过，
详见我的<<绕过现代Anti-Rookit工具的内核模块扫描>>一文



这里提出一种新的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的返回地址，不一定是rootkit :p )

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

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

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

(例如<<绕过现代Anti-Rookit工具的内核模块扫描>>中提到的方法),
都会被检测出来

但并非所有的inline hook方式都可能被检测出来，例如修改被HOOK函数参数后使用jump 指令而不是call指令跳转到原始函数，这样就检测不出来

另外HOOK的位置也十分关键，HOOK的位置不对，一些ROOTKIT可能HOOK的路径就会被放过，HOOK得过深的话，进程context就会丢失(例如hook到disk或atapi来检测文件/磁盘HOOK时)，这样判断上就会有一定的困难

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

从调用栈找钩子的问题，我以前也想过，某些情况还是不错的。
但rootkit也有相应的绕过方法。

1，搜索整个被挂钩函数所在的模块，找以下任意一条“跳板”指令：
jmp esi;
jmp edi;
jmp ebp;
call esi;
call edi;
call ebp;
…………

2，比如找到了jmp esi，那么调用原函数时这样做：
push esi;
mov esi, ret_addr;
push 参数n;
push 参数n-1;
……
push 参数0;
push 跳板指令地址;  --> jmp esi;
push 原函数地址;
ret;
ret_addr:
pop esi;

这样调用栈上出现的就是跳板指令的地址，绕过了模块定位。

即使jmp xxx和call xxx都没有， ret指令总是有的。
于是：
push ret_addr;
push 参数n;
push 参数n-1;
……
push 参数0;
push 跳板指令地址;  --> ret;
push 原函数地址;
ret;
ret_addr:

这个ret_addr虽然在栈上，但正常堆栈回溯时不会被当作返回地址。

 

（PS：到处都看到这个帖子，汗一个先。这里人气旺，我也再回一遍，呵呵）

呵呵，主要是对难以检测的OBJECT HOOK有奇效~~

今天又钩了啊，在哪钩都要挂啊。杀毒自己react OS吧，哈哈

有俗话[ 我是流氓我怕谁 ]，这个方法大范围采用先天不足。