首先感謝下PCHunter的作者提供了這麼優秀且還是免費的內核工具。
這次逆向是我在科銳學習32位內核課程後，練手的小項目，感覺自己寫得比較用心的，所以作為自己的首貼逆向貼，發布到看雪上來，與大家分享一下。
這篇作為第一篇，主要內容是通過分析PCHunte3環請求到0環的通信協議內容，來精準定位PCHunter驅動功能相關函數，之後的篇幅會在此基礎上，逐篇分析PCHunter的各項內核功能的實現。
---
樣本名：PCHunter64ao.sys (之後簡稱樣本)
版本號：1.0.0.5
樣本來源：PCHunter64.exe 釋放的驅動文件
調試環境：host: win7_64 + IDA + VirtualKd
dest: WMware(win7_64)
當前樣本模塊加載基址：
PCHunter64ao.sys FFFFF88003400000 00000000000C0000
nt fffff800`03e00000 fffff800`043ea000
因為雙機調試環境搭建相關的帖子很多，所以略去。
在調試目標機開啟PCHunter前, IDA載入樣本PCHunter64ao.sys。
概述：
經過IDA分析之後,得知樣本函數數量規模,大於等於1004個。
我的首要任務是解決在這眾多的函數中，如何找到我們要分析的功能？
根據自己開發驅動的經驗,功能較多的驅動服務中，3環應用程式一般使用DeviceIoControl函數，通過其提供的控制碼功能,來實現與0環的功能請求通信，0環則通過派遣回調函數表對應的 IRP_MJ_DEVICE_CONTROL 項中，3環傳入的控制碼來實現用戶請求功能的區分和功能向下派發。
但是在實際分析過程中我發現，PCHunter 3環所有的用戶請求控制項碼都是同一個，樣品並沒有使用常歸的通信手法,難道另闢蹊徑或是加密了？
之後經過一系列努力，最後發現作者確實是在設備控制的基礎上，又實現了一套自己的3環與 0環通信協議，並對協議作了加密，解密後的內容中又發現了動態與靜態的2處校驗碼。
至此心中對作者又升起一股由衷的敬意。一款免費的驅動工具，作者卻一點也不馬虎。
下面開始具體介紹菜鳥分析挑戰之旅(大神老鳥可以略過)。
---
通過IDA很快找到樣本入口處，也就是DirverEntry，F2設置斷點，在目標機中打開PCHunter工具，於是IDA中斷下來了。
如下圖所示：
此時我已經有了pDriverObject對象指針
WINDBG>dt nt!_DRIVER_OBJECT
+0x000 Type : Int2B
+0x002 Size : Int2B
+0x008 DeviceObject : Ptr64 _DEVICE_OBJECT
//略
+0x068 DriverUnload : Ptr64 void
+0x070 MajorFunction : [28] Ptr64 long
下一目標是要找到 pDriverObject+0x070 位置的寫入，也是註冊其成員派遣函數表的代碼。
根據結構體信息參照，從入口向下，不遠處就看到了關鍵位置，如下圖所示：
設備控制回調下標宏是 IRP_MJ_DEVICE_CONTROL，是第14項
計算偏移等於 0x70+8*14= 0xE0，由此可以斷定圖上第二個紅框就是設備控制回調函數註冊的地方，對其進行命名。
鑑於0環和3環的通信常規是用控制碼，下一步目標就是進入設備控制派遣函數中分析3環傳來的控制碼。
經過對該函數中第二個參數，IRP結構體的反覆校驗後，得到了通信控制碼，並且找到SystemBuffer及它的長度校驗位置。在此一併進行了標記，
如下圖所示：
signed __int64 __fastcall DispatchDeviceControl(__int64 pDevObj, _IRP *pIRP)
但是當我回到目標機器,多次刷新不同的PCHunter功能後，發現中斷下來的控制碼全部相同，此時斷定了其採用的是統一通信控制碼，並且在之後對這個固定通信控制碼作合法校驗，如果不等於此校驗碼就提前結束函數。
于是之前的思路就走不通了，剩下還有一種可能，就是它的功能是通過3環傳的IOBuffer內的數據來區分用戶功能請求的。
接著向下分析發現，發現了對3環傳入的 IOBuffer 的操作相關代碼：
這段彙編代碼是個循環，循環內逐字節的先作異或再求反的動作，疑似在做解密。
於是乎，我在此位置下斷，並通過在3環反覆操作PCHunter相同和不同功能，得到多份解密後的內容，經過分析比較後得出結論：
PCHunter確實是通過3環傳入0x30位元組的IntputBuffer實現通信協議的,
下面是總結後的通信協議相關欄位的功能：
解密後的請求協議內容：
接著向下分析，
樣本在完成通信協議內容解密後，先用前4位元組作為固定籤名，用以驗證3環請求調用者的身份。
之後是校驗協議中的動態校驗碼：
在用戶請求動態校驗成功後，再對 (請求功能號作 -0Fh + 90Dh)*8 的運算，運算結果就是服務功能函數的相對分發基址(g_srvfn) 的偏移， 通過全局服務請求函數信息指針加上該偏移，就能找到實現服務請求的相關功能函數，再調用此函數就實現了3環用戶請求的向下派發，如下圖所示：
對應的得出用戶請求功能處理偽函數聲明信息：
函數指針聲明：
__int64 (__fastcall *)pfnSrvFunc(pIndata,IndataSize,pRetBuf,RetBufSize);
函數指針偏移：偏移 = (用戶請求號 - 0Fh +90Dh) * 8 ;
相關功能函數地址：在rax中
在用戶請求功能處理函數執行完後，用戶請求的操作結果和數據返回在協義的相關欄位，
如Retbuffer中。
到此，如何定位PCHunter用戶層相關功能請求的處理函數就分析完了，之後再分析PCHunter其它功能，就只要在上圖紅框處下斷點 (請求功能向下派發處 )，觀察用戶層操作之後，通信協議中的功能號 和 傳入傳出的buff數據，就能精準定位PCHunter驅動功能的實現代碼。
本文由看雪論壇 hjbfa 原創
轉載請註明來自看雪社區
往期熱門閱讀：
掃描二維碼關注我們，更多乾貨等你來拿！