———————————————————————————————————————————————————————————————— 在上一篇文章中，我們已經看到 IopParseDevice() 如何對傳入的 OPEN_PACKET 結構進行驗證。假設 ObReferenceObjectByName( ...
————————————————————————————————————————————————————————————————
在上一篇文章中，我們已經看到 IopParseDevice() 如何對傳入的 OPEN_PACKET 結構進行驗證。假設 ObReferenceObjectByName() 的調用者沒有分配並初始化第七個參數 ParseContext，而僅是簡單地傳入 “NULL” ，那麼當調用鏈深入到 IopParseDevice() 內部時，就會因驗證失敗返回 C0000024（STATUS_OBJECT_TYPE_MISMATCH）。
我們根據源碼中的暗示來追蹤 OPEN_PACKET 結構究竟在哪分配的，如前所述，調用鏈 NtCreateFile->IoCreateFile()->IopCreateFile() 的結尾，也就是在 IopCreateFile() 內部，實際負責 OPEN_PACKET 的初始化。下麵貼出的代碼片段以 NT 5.2 版內核源碼為樣例：
也就是說，我們直接複製 IopCreateFile() 中的 OPEN_PACKET 結構初始化部分邏輯就行了？
這裡還有一個問題，負責分配該結構體內核記憶體的常式 IopAllocateOpenPacket() 是一個巨集，Visual C++ 2015 中給出它是用 ExAllocatePoolWithTag() 定義的。這就好辦了，在我們自己的驅動源碼中，添加相應定義即可，如下圖：
————————————————————————————————————————————————————————————
因為 OPEN_PACKET 結構同樣沒有公開的文檔來描述，所以要麼在我們的驅動源碼中用 “#include” 包含定義它的頭文件，要麼直接複製定義的那一部分黏貼進來。很顯然，後者比較輕鬆——OPEN_PACKET 在內核源碼的 “iomgr.h” 中定義，而該頭文件又嵌套包含了一堆雜七雜八的內核頭文件，要理清這些嵌套包含關係很麻煩，而且最重要的是，其中一些頭文件定義的數據類型會與驅動開發中用的 “ntddk.h” 和“wdm.h”重覆，引起編譯器的抱怨。所以直接在 “iomgr.h” 中搜索字串 “typedef struct _OPEN_PACKET”，把找到的定義塊拷貝進來即可。
然而，OPEN_PACKET 結構中唯有一個欄位不是 “原生” 定義的——這就是 “PDUMMY_FILE_OBJECT” 類型，需要包含其它頭文件才不致使編譯器報錯。
我的解決方案是，直接把該欄位的聲明所在行註釋掉，下圖展示了該欄位具體的位置（在 “iomgr.h” 中的行號），方便各位快速查找：
——————————————————————————————————————————————————————————————————
註意，NT 6.1 版內核在編譯時刻的 OPEN_PACKET 結構顯然是未經 “惡意” 修改的，所以編譯器為其 “sizeof(OPEN_PACKET)” 表達式計算 0x70 的值，而我們在自己的驅動中拿掉了 OPEN_PACKET 其中一個欄位使得編譯器為表達式 “sizeof(OPEN_PACKET)” 預計算 0x58 的值（後面的調試階段會驗證），這會造成 “Size” 欄位不是 IopParseDevice() 內部邏輯預期的 0x70，從而導致返回 C0000024（STATUS_OBJECT_TYPE_MISMATCH）。
解決辦法也很簡單，我們的驅動中，不要依賴編譯時刻的計算，直接把 “Size” 欄位的值硬編碼為 0x70 不就好了？
如下圖所示，你還會註意到，我把 “Type” 欄位的常量 “IO_TYPE_OPEN_PACKET” 改成了對應的數值，以確保萬一。
另外，由於 IopAllocateOpenPacket() 等價於 ExAllocatePoolWithTag()，而後者通常返回泛型指針（“ PVOID ”，亦即 “ void * ”），
所以我強制把它轉型為與 “openPacket” 一致的類型。
萬事俱備，“東風” 就在於調用 ObReferenceObjectByName() 時，為第七個參數傳入“openPacket” 即可，上圖顯示的很清楚了。
——————————————————————————————————————————————————————————————————
很不幸的是，我把編譯出來的驅動放到虛擬機（Windows 7，基於 NT 6.1 版內核）裡面動態載入測試，還是無法獲取到
“\Device\QQProtect” 相應的設備對象指針，ObReferenceObjectByName() 返回 C0000024。
為了找出故障原因，我在分配 OPEN_PACKET 邏輯的前面利用內聯彙編添加了一個軟中斷 “__asm{ int 3; } ”，宿主機器上啟動內核調試器 kd.exe，我的啟動參數像是這樣：
kd.exe -n -v -logo d:\virtual_machine_debugging.txt -y SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols -k com:pipe,port=\\.\pipe\com_1,baud=115200,reconnect
參數 “logo” 指定要把整個調試過程的輸出信息寫入日誌；
“-y” 指定符號文件的位置（機器指令中沒有內核函數與變數的符號，所以調試器需要查找額外的符號以向用戶顯示人類可讀的名稱）；
“-k” 參數指定調試類型為 “命名管道模擬串口1”，波特率數值越高，響應越快。
把重新編譯好的驅動放到虛擬機中，在提升許可權後的命令提示符中執行 bcdedit.exe，啟用調試模式，這樣重啟虛擬機後，就會進入調試模式（無需在啟動過程中按下 F8 選擇菜單）。
我把自己的驅動實現成按需載入，也就是利用服務控制管理器（sc.exe）發出命令來動態載入和卸載，實現此功能的相應批處理文件內容如下圖，註意該文件要放在虛擬機中執行，“start= demand” 表明通過 sc.exe 按需啟動；“binpath” 就是驅動文件存放的磁碟路徑，假設我的驅動名為 hideprocess.sys，執行該批處理任務後，就在相關的註冊表位置添加了一項，往後只需在 cmd.exe 中執行 “sc.exe start/stop hideprocess” 就能夠動態加卸載。
按照上述方式載入時，就會自動觸發我們設定好的軟體斷點，即可在宿主機中檢查虛擬機的內核空間。
另外還需註意一點：編譯驅動時的 “構建” 環境應該選擇 Check Build，這樣會一併生成同名稱的符號文件，尾碼為 “.pdb”，從而調試器能夠顯示我們自己驅動中的函數與變數名稱，提高調試效率，如下圖：
——————————————————————————————————————————————————————————————————————
觸發軟體斷點後，我們一般會用 “kv” 命令查看棧回溯信息，它披露出我們的驅動入口點 DriverEntry() 是由 I/O 管理器的 IopLoadDriver() 調用的：
棧的頂層函數 “ReferenceDeviceAndHookIRPdispatchRoutine+0x56” 是我添加軟中斷的地方。執行 “r” 命令查看當前的 x86 通用寄存器狀態，EIP 指向地址 0x8f4a3196 ，執行 “u hideprocess!ReferenceDeviceAndHookIRPdispatchRoutine+0x56 L2”，反彙編輸出的第一行地址就是 0x8f4a3196，與 EIP 的值相符；第二行是把一個 16 進位值 “ 704F6F49h” 壓棧，實際上它是 ASCII 字元 “pOoI” 的 16 進位編碼，換言之，這是在通過內核棧傳遞 ExAllocatePoolWithTag() 的第三個參數（從右往左傳遞，請回顧之前的 IopAllocateOpenPacket() 巨集定義那張圖）。
————————————————————————————————————————————————————————————————
繼續按下 “t” 單步執行，如下圖所示，你可以看到，ExAllocatePoolWithTag() 的第二個參數，分配的內核記憶體大小為 0x70 位元組，因為我在巨集定義中硬編碼了這個值，而不是用 sizeof(OPEN_PACKET) 表達式讓編譯器計算；另一方面，圖中的 “dt” 命令也證實了它的大小為 0x70 位元組。
首個傳入的參數 “NonPagedPool” 為不可換頁池，其內的數據無法被換出物理記憶體，該常量對應的數值為 “0”：
我不想浪費時間在查看內核記憶體的分配細節上，所以我按下 “p”，步過 ExAllocatePoolWithTag() 函數調用，接下來的 cmp/jne 彙編序列對應源碼中檢查是否成功分配了記憶體並用於 openPacket 指針，實際的執行結果是跳轉到地址 0x8f4a31c6 ，對應源碼中初始化 OPEN_PACKET 結構前兩個欄位的邏輯：
接下來一直單步執行到調用 ObReferenceObjectByName() 前夕，在此處我們要 “步入” 它的內部，進行故障排查，所以按下 “t” 跟進，這裡有一個小技巧，我們已經分析過 ObReferenceObjectByName() 的源碼，知道它會調用很多函數，而且大致清楚問題出現在 ObpLookupObjectName() 裡面，所以指令 “tc”可以跟蹤到每個函數調用處停止，再由用戶決定是否跟進該函數內部。
這是我的美好夢想，但現實總是殘酷的，在我跟蹤到原子操作系列函數
nt!ExInterlockedPopEntrySList() 調用時，kd.exe 就卡住了，無法繼續追蹤此後的調用鏈。從稍早的棧回溯信息來看，與源碼中和我們預測的調用序列大致相符，只是不曉得為啥在 nt!ObpAllocateObjectNameBuffer() 中，為了給傳入的驅動對象名稱 “\Device\QQProtect” 分配內核記憶體，調用 nt!ExInterlockedPopEntrySList()，而後者卻無法追蹤。。。。是虛擬機環境的緣故，還是原子操作類函數的不可分割性質？
——————————————————————————————————————————————————————————————
講一點廢話，一般我們在棧回溯中看到的頂層說明行，有一個 “Args to Child” 項目，表示調用者傳遞給它的參數，不過最多也只能顯示前三個。
以下圖為例子吧，傳遞給 nt!ExAllocatePoolWithTag() 的三個參數（從左到右）就是 00000000（NonPagedPool），00000070（我硬編碼的值），704f6f49（ASCII 字元串“pOoI”），同理，傳遞給 hideprocess!DriverEntry() 的第一個參數 867c3550 是 _DRIVER_OBJECT 結構的地址，由I/O 管理器載入它時為它分配（註意與源碼中 DriverEntry() 定義的一枚 _DRIVER_OBJECT 指針不同，“Args to Child”
列出的數據相當於執行解引操作符 * 後的結果），第二個參數是 UNICODE_STRING 結構的地址，對應源碼定義中的一枚 _UNICODE_STRING 指針，該結構中存儲的是我們驅動在註冊表中的完整路徑：
——————————————————————————————————————————————————————————————————
總而言之 ，基於以上理由我無法繼續跟進到 ObpLookupObjectName() 裡面查看它是否執行了 IopParseDevice() 回調，從而無法確定究竟為啥後者返回 C0000024。
我想可能是因為內核源碼版本的變化，導致相關常式的判斷邏輯也不一樣了，不能根據前一版源碼的邏輯來編寫預計運行在後一版內核上的驅動。
其實解決方案還是有的，比較花時間罷了，就是利用 “u” 指令反彙編 ObpLookupObjectName() 起始處對應的機器指令，再反編譯成近似的 C 偽碼，與 NT 5.2 版內核源碼對比，找出其中改動的地方，但這是一個費時費力的工作，且收益甚微，還不如直接在互聯網上搜釋出的 NT 6.1 版內核源碼，或者接近的版本，再思考繞過的方法。
順帶說一下，根據 A 設備名獲得 A 設備對象的指針，然後把 rootkit/自己驅動創建的惡意設備 attach 到 A 設備所在的設備棧，從而攔截檢查經過 A 設備的 IRP 內數據。。。。這種方法已經比較過時了，因為現在反病毒軟體的內核模式組件也會檢查這些設備棧，尋找任何匹配特征碼的惡意設備，再者，內核調試器的 “!devstack” 命令很容易遍歷揭示出給定設備所在的設備棧內容，被廣泛用於電腦調查取證中，從 rootkit 的首要目標——實現隱身——的角度來看， attach 到設備棧就不是一個好榜樣。
相反，通過 ObReferenceObjectByName() 總是能夠獲得驅動對象的指針，進而能夠 hook 該驅動的 IRP 分發常式，這種手段隱蔽性極高，而且不容易被檢測出來。
後續的博文將討論如何將這種技術用在 rootkit 中，同時適應當前流行的對稱多處理器（SMP）環境。
————————————————————————————————————————————————————————————————
