說明：本文轉載于 ： iceboy @ baidu.hi
很久很久以前, 電腦一般是單核的, 即電腦上一般只有一個處理器. 這樣, 如果我們要修改一段內核代碼, 似乎 IoCreateMdl(), MmBuildMdlForNonPagedPool() / MmLockAndProbePages() 然后 KeRaiseIrqlToDpcLevel() 以后, 就可以很安全地改寫內存的數據. 因為系統只有一個 CPU, 這個 CPU 在 Irql >= DPC_LEVEL 的時候不會被調度, 因此在改寫代碼期間 eip 不可能指向被 hook 的代碼, 但是到了多處理器電腦上這一切都變了.
當一個 cpu 在 DPC_LEVEL 的時候, 它是不會被調度的. 問題是, 系統中有不止一個 cpu, 其它的 cpu 還是想干啥干啥. 如果用上述方法, 其它 cpu 很有可能在你代碼修改到一半的時候去執行, 就會造成系統崩潰, 藍屏重啟.
我們可以做一個實驗:
#include <ntddk.h>
int a;
VOID XXThread(PVOID XXContext)
{
DbgPrint("Thread created.\n");
while (1) {
if (a == 1) DbgPrint("Irql=%d, Processor=%d", KeGetCurrentIrql(), KeGetCurrentProcessorNumber());
else if (a == 2) {
DbgPrint("Thread terminated.\n");
PsTerminateSystemThread(0);
}
}
}
NTSTATUS DriverEntry(PDRIVER_OBJECT XXObject, PUNICODE_STRING XXPath)
{
HANDLE hThread;
KIRQL OldIrql;
ULONG i;
a = 0;
PsCreateSystemThread(&hThread, 
, XXThread, 0);
OldIrql = KeRaiseIrqlToDpcLevel();
DbgPrint("Irql=%d, Processor=%d", KeGetCurrentIrql(), KeGetCurrentProcessorNumber());
a = 1;
for (i = 0; i < 100..0; i++) __asm nop; // wait for some time
a = 2;
KeLowerIrql(OldIrql);
// wait for hThread and close it
return STATUS_UNSUCCESSFUL;
}
這個地方沒有裝 DDK, 程序是隨便寫的, 大意即是如此. 我以前做這個實驗時寫過一個類似的程序, 并證明了 Irql 是 CPU 相關的這一事實. 也就是說, 在多處理器系統上, 上述 inline hook 的方法不再安全. 然而, 越來越多的電腦使用雙核, 甚至三核、四核的處理器, 我們如果不注意這個問題, 就是對用戶不負責任. (PsNull3 中使用 CreateMdl + ProbeAndLockPages + RaiseIrql + cli + WPOFF 大雜燴方法, 實際上仍然可以證明不安全)
這個問題該怎么解決呢? 我也沒有成熟的想法. 問題的本質在于在我們修改一段代碼的前后, 這段代碼中的任何語句都不應該被執行. 于是有以下思路 (我們按照雙核處理器電腦討論):
1. inline hook 一般是 5 個字節, 總之一般不超過 8 個字節, 我們可以找一條能夠一次操作 64bit 的指令. 問題是, 真的存在這樣的指令嗎? (lock xxx, movq xxx, mmx) 不知道 cpu 執行它的時候, 是一次完成的呢, 還是用了一段微程序分步完成. (我們的 cpu 是 32bit 的~) 即使存在這樣的指令, 也不安全. 假設被 hook 的指令是這樣的:
mov edi, edi
push ebp
mov ebp, esp
這是一個典型的函數開頭. 我們假設 cpu0 執行到 push ebp 這一條指令 (eip = $+0x2). 這個時候 cpu1 執行傳說中的 move_qword 指令:
movq [$+0x0], mm0
其中 mm0 中包含這樣的指令: jmp 12345678, 其機器碼是 E9 AA BB CC DD.
問題出現了. 當 cpu1 執行完這一條指令的時候, cpu0 的 eip 指向如下字節流: BB CC DD XX XX XX. 結果顯然是系統崩潰.
2. 有了以上的經驗和教訓, 我們很自然地想到, 在修改代碼的時候, 霸占所有的 cpu. 好在我們有以下導出符號幫忙:
KeNumberProcessors
KeGetCurrentProcessorNumber()
KeInitializeDpc()
KeSetTargetProcessorDpc()
KeInsertQueueDpc()
KeWaitForSingleObject()
我們可以先 Raise Irql, 然后 Get Current Processor Number, 然后向所有非本 Processor Number 的 Processors 注入 Dpc, 讓它 Stall Execution 或者 Wait For XXX Event (我錯了...). 一切似乎都很美好?
神奇的MJ0011(3537xxxxx) 20:02:20
DPC下沒法WAIT
以上代碼有嚴重問題, 可能導致系統死鎖. 假設有兩個程序幾乎同時試圖霸占整個系統, 它們同時先后執行了 KeRaiseIrqlToXXX(), 這時兩個 cpu 都處于 IRQL = DPC_LEVEL 的狀態, 并且都試圖注入 DPC 到另一個 cpu 中, 糟糕的是, 它們都等待這個 DPC 創建完畢. 然而, 兩個 DPC 都只有在 KeLowerIrql() 之后才開始執行. 它們就這樣一直等啊等...
KeStallExecutionProcessor() 或許可以在一定程度上解決這個問題, 但是仍不完美.
神奇的MJ0011(3537xxxxx) 20:11:50
是我的DPC等待我現在的CPU
神奇的MJ0011(3537xxxxx) 20:11:56
不是我的CPU等待我投遞的DPC
我又錯了... 再思考思考~
3. 很多函數的代碼開頭都有 mov edi, edi 這一行, 按照某傳說的說法, 這是微軟大發慈悲, 讓編譯器在函數首部加入這樣一行指令. 并在這一指令前, 上一個函數后, 留下 5 個 nop. 這就可以讓我們有充分的時間在前面 5 個 nop 中寫入一個跳轉指令, 并使用一條原子指令將 mov edi, edi 改成 jmp $-0x5 (也是兩個字節).
這個方法也有不少問題. 首先, 不是所有的函數開頭都有這一行指令, 比如 KiFastCallEntry 似乎就沒有. 其次, 使用這個方法需要大家都遵循一個規范, 即 hook 函數的開頭也必須是 nop nop nop nop nop mov edi, edi, 并且在恢復 hook 的時候需要把下一個 hook 接上去, 這又涉及到計算偏移等問題. 很多程序作者都是自私的, 不考慮鉤子的共存問題, 或者說, 它們也沒有能力使用好函數頭的這一條語句. 據我所知, KV 的程序員在這一點做得很好, 如果函數頭有 mov edi, edi, 它會從下一條指令開始 hook. 而 KAV 的程序員則是不顧一切地在函數頭寫上一個 jmp. 無奈的是, 總有人在函數頭寫上 jmp, 這樣, 這個方法就不能用了. 否則用戶會說: 某某程序和某某大公司的某某軟件不兼容, 肯定是這個程序作者的問題.
------
那么, 有沒有更好的方法呢? 歡迎大家討論.