MJ0011內(nèi)核研究所——基于CallStack的AntiRootkitHOOK檢測思路

1、.基于CallStack的Anti-Rootkit HOOK檢測思路：MJ00112007-11-2th_decoderAnti-Rootkit目前掃描Hook的方法主要有以下幾種:1.對抗inline -hook ,IAT/EAT HookAnti-Rootkit使用讀取磁盤上系統(tǒng)文件并將之進(jìn)行map重定位后，同內(nèi)存中的代碼進(jìn)行對比的方法來檢測inline hook(或EAT/IAT HOOK，后同）,類似的工具例如Rootkit Unhooker, gmer, Icesword等等為了對抗Anti-Rootkit的inline Hook掃描,Rootkit們使用一些方法來進(jìn)行自己HOOK的

2、隱藏例如Shadow Walker的方法，HOOK Int 0Eh缺頁中斷來隱藏內(nèi)存中被HOOK的代碼或者是例如流氓軟件CNNIC中文上網(wǎng)，HOOK FSD的IRP_MJ_READ,當(dāng)讀取到ntfs.sys等文件時，修改數(shù)據(jù)，將錯誤的結(jié)果返回回去，導(dǎo)致Anti-rootkit工具誤認(rèn)為內(nèi)存中的代碼是正確的多種方式都可以讓這種傳統(tǒng)的INLINE HOOK檢測方法失效2.Object HookObject Hook一般更隱藏，更難檢測為大家所熟知的Object hook例如有修改driver object中的MajorFunction dispatch表或者是hook KeyObject(KCB)

3、中的一些call back routine/GetCell Routine(zzzzevazzzz放出過相關(guān)代碼）又或者是hook Object中一些其他的通用鏈中的代碼指針來進(jìn)行自我隱藏/保護(hù)功能(例如tombkeeper的一些文章提到的細(xì)節(jié))目前的辦法一般是掃描這些OBJECT的結(jié)構(gòu),找到對應(yīng)指針，利用特征搜索、模塊范圍對比等方法，檢測他們是否被HOOK類似的工具例如 rootkit unhooker,gmer(rootkit unhooker中檢測的object hook較多）但這些工具都只能檢測他們已知的object hook一旦Rootkiter利用未知的object hook進(jìn)行隱

4、藏，或者是轉(zhuǎn)換平臺，數(shù)據(jù)結(jié)構(gòu)發(fā)生變化，就很難檢測到object hook, 傳統(tǒng)的Object hook檢測方式也很容易被rootkiter饒過，詳見我的<<繞過現(xiàn)代Anti-Rookit工具的內(nèi)核模塊掃描>>一文這里提出一種新的hook檢測方式: 即利用CallStack進(jìn)行HOOK檢測讓我們來看一種典型的rootkit的HOOK方式:例如hook FileSystemNtfs的 IRP_MJ_DIRECTORY_CONTROL來進(jìn)行文件隱藏，有上相關(guān)的代碼它們的代碼通常是這樣的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/首先調(diào)用原始函數(shù),以便得到結(jié)果/下面進(jìn)行處理，hack CompletionRoutine,或者是直接修改 UserBuffer的數(shù)據(jù)/.上面就是一個hook fsd來隱藏文件的ROOTKIT的大概結(jié)構(gòu)讓我們來看看，在MyNtfsDriCtl中call g_OldNtfsDriCtl時，發(fā)生了什么？它會跳轉(zhuǎn)到原始的g_OldNtfsDriCtl中，并且保存返回地址，這個返回地址在哪兒？rootkit的代碼體內(nèi)！那么就簡單了，我們簡單地Hook 原始dispatch中的更深層的地方，例如，Ntfs的DriectoryCo

7、ntrol快結(jié)束時會call KeLeaveCriticalRegion或者IofCompleteRequest我們HOOK這個地方，然后，當(dāng)這個調(diào)用觸發(fā)時，我們檢查esp,并向上回溯堆棧，找到call stack，我們發(fā)現(xiàn)了什么？哈哈！rootkit的返回地址！再簡單的使用ZwQuerySystemInformation,就可以知道這個地址位于哪個模塊中，ROOTKIT定位成功?。ㄈ绻ㄈチ四K，可以定位這塊內(nèi)存為unknow image)這樣，只要HOOK特定的地方，再在ring3調(diào)用相關(guān)服務(wù)，觸發(fā)hook,檢查call stack，就可以輕松得到rootkit的返回地址了(或者h(yuǎn)ooke

8、r的返回地址，不一定是rootkit :p )示例代碼就不寫了，有幾個注意問題:1.call stack中會有其他一些系統(tǒng)的模塊或者硬件驅(qū)動的模塊，要考慮如何把他們區(qū)分出來的問題，相信這個很簡單了,呵呵2.使用這種方式，只要你HOOK的地方正確恰當(dāng)可以檢測到90%以上的object hook,無論object結(jié)構(gòu)如何變化，或者是未知的object hook,或者使用一些方式進(jìn)行object hook的隱藏(例如<<繞過現(xiàn)代Anti-Rookit工具的內(nèi)核模塊掃描>>中提到的方法),都會被檢測出來但并非所有的inline hook方式都可能被檢測出來，例如修改被HOOK函數(shù)參數(shù)后使用jump 指令而不是call指令跳轉(zhuǎn)到原始函數(shù)，這樣就檢測不出來另外HOOK的位置也十分關(guān)鍵，HOOK的位置不