------- 軟件調試——註銷 QQ 過濾驅動設置的事件通知 CallBack （完）-------

——————————————————————————————————————————————————————————————————————————————————

本系列的最後一篇演示如何經過調試手段摘除 QQ 過濾驅動設置的事件通知 CallBack。

內核中有幾個全局的數組用來存放這些事件通知 CallBack 的指針，第一個就是 nt!PspCreateProcessNotifyRoutine，

當有進程被建立時，該數組中的函數指針就會依次被調用，與此相似，當有線程被建立時，nt!PspCreateThreadNotifyRoutine

數組中的函數指針就被調用；nt!PspLoadImageNotifyRoutine 中的回調則是在有內核模塊加載時被調用。

驅動程序經過向這些數組中加入 CallBack 指針，就可以監控相應的事件。

首先來看下哪些驅動程序正在監控系統範圍的進程建立事件：

1 r @$t0=poi(nt!PspCreateProcessNotifyRoutineCount);
2 r @$t1=nt!PspCreateProcessNotifyRoutine;
3 .for(r @$t2=0; @$t2<@$t0; r @$t2=@$t2+1){dds (poi(@$t1+@$t2*4)^7)+4 l1;}

 

 

從上圖您能夠看到，QQFrmMgr.sys 中有一個例程正在監視着進程建立事件。除此以外的其它內核模塊都是合法的，好比

「avkmgr」與「avdevprot」是安裝德國小紅傘反病毒軟件時，附帶安裝的兩個內核模式驅動程序，它們註冊了各自的回調在

監控着進程建立事件，這是實現 Real-Time Protection 用到的系統底層機制之一；「tcpip」不用我說各位也知道，它是

Windows 內核網絡棧的主要實現模塊之一：

 

 

 

注意，系統最多支持註冊 8 枚事件回調指針，nt!PspCreateProcessNotifyRoutineCount 存儲當前註冊的回調指針數量，以下圖，

這個全局變量的值與第一張圖片中的事件回調指針枚數一致：

 

 

如今，咱們嘗試從中摘除 QQFrmMgr.sys 的監控例程：

 

 

 

 使用相似的手段，檢查 QQFrmMgr.sys 有沒有監控線程建立與內核模塊加載事件：

 

 1 r @$t0=poi(nt!PspCreateThreadNotifyRoutineCount);
 2 r @$t1=nt!PspCreateThreadNotifyRoutine;
 3 .for(r @$t2=0; @$t2<@$t0; r @$t2=@$t2+1){dds (poi(@$t1+@$t2*4)^7)+4 l1;}
 4 
 5 
 6 
 7 
 8 r @$t0=poi(nt!PspLoadImageNotifyRoutineCount);
 9 r @$t1=nt!PspLoadImageNotifyRoutine;
10 .for(r @$t2=0; @$t2<@$t0; r @$t2=@$t2+1){dds (poi(@$t1+@$t2*4)^7)+4 l1;}

 

您看，這傢伙監控的地方還真很多，爲的就是保護它本身免受其它惡意軟件攻擊！或許你會好奇：圖中的「XLGuard」是啥東

東？

它就是在安裝「迅雷」（一種基於 BitTorrent 協議的 P2P 下載/分享軟件）時，一併安裝的內核模式驅動程序之一，以下圖：

 

 

從名稱中的「Guard」來看，應該也是用來保護迅雷自身組件的——如今的軟件都比女性還懂得怎麼保護本身呢！

你可使用前述的方法來阻止 QQFrmMgr.sys 監控線程建立與內核模塊加載事件——就佈置成家庭做業吧！

———————————————————————————————————————————————————

 

寫到這裏，本系列算是大體功德圓滿了。。。。還記得上一篇我抱怨說「!chkimg」調試器擴展命令不能用嗎？

折騰的這幾天總算找出問題所在了——從 MSDN 網站下載的 Windows 7 零售版符號包中的 ntoskrnl.exe 版本問題——我聽信

該站點的建議下載了 Windows 7 Service Pack 1 x86 零售符號，結果其中的 ntoskrnl.exe 內核映像版本被最新版的

WinDbg 排斥，因此我換用了 Windows 8.1 x86 32 位零售符號，以便雙機物理調試環境中檢查目標機器上的 Windows 8.1

內核工做狀況，也證明了 QQ 驅動沒有采起反虛擬機技術，它的行爲模式與在真實機器上的表現一致（至少在寫做本文的時間點上

是如此，之後就難說了，搞很差也會引入反調試技術。。。），以下圖：

 

 

最後貼上在 32 位 Windows 8.1 上利用「!chkimg」自動檢查並恢復 SSDT 的過程，以饗讀者：

 

 

 

 

NND，爲啥前面手工檢查 SSDT 可以發現的 QQ hooks，經過「!chkimg」自動檢查卻探測不到，只識別了 inline hook ？

閱讀一下該擴展命令的官方文檔，原來是須要指定一個特殊的選項：

 

 

正如圖中紅框部分所講的那樣：Hal.dll 與 Ntoskrnl.exe 中的某些特定地址不會被檢查，由於當這些部分被載入時，會發生某些改變。

包含 -nospec 選項則能夠檢查這些地址。事實上，這就是我在前一篇談到的——每次系統啓動時都隨機建立 SSDT 的基址，因此

「!chkimg」就忽略了這些「隨機」的部分，恰恰給 QQ 驅動留下了可乘之機。。。。添加 -nospec 選項後，咱們成功地

分析出 SSDT 中的全部 hooks，下面我僅截取了輸出的前三個 hooks，它們對應於前面有一張「dps」命令解析圖中的三個 hooks：

 

 以上圖中的黃框部分爲例，第一個 hook 是從 8151b3a8 到 8151b3aa 的三個字節修改；冒號左邊是磁盤文件中的原始字節

序列，冒號右邊是內存映像中的已修改字節序列，該項 hook 距離 nt!KiServiceTable 起始地址的偏移量爲 0xC。

讓咱們看看前三個 hook 的受害例程（原始系統服務）是什麼？

 

原來 QQFrmMgr.sys hook 了 NtWriteVirtualMemory()（寫入任意進程的虛擬內存）、NtUnmapViewOfSection()（取消

映射 section 的視圖；Windows 內存管理器中用來實現共享內存和映射文件的底層原語就叫作 "section 對象" ；合法的驅動

程序程序應該僅使用 ZwOpenSection()，ZwMapViewOfSection()，以及 ZwUnmapViewOfSection() 等函數操縱 section

對象；因而 hook 該系統服務的用意在於監視映射文件與查看其中部份內容的請求）、

以及 NtTerminateProcess()（終止進程），這與我前一篇的手工分析一致。

 最後，讓咱們用「!chkimg」的「-f」開關，自動修正內存映像中的錯誤：

 

 

 

————————————————————————————————————————————————————————
小結：本篇討論了摘除惡意事件通知回調函數的相關技巧，並演示自動修復關鍵系統設施的方法，文中介紹的調試技術只是

內核攻防中的冰山一角，並且這些方法隨着內核與惡意軟件的不斷進化也正面臨着挑戰！

持續研究與探索不一樣內核驅動/rootkit 的行爲模式仍舊是必要的！
————————————————————————————————————————————————————————