剛開始看到通過 ssdt 來 hook zw*** 核心函式的方法時不是很了解, 等把 zw*** 反彙編後才發現技術細節.
原來也沒什麼新鮮的,就是找到目標函式在 ssdt 中的位置( 偏移量＝位置*4 ), 然後儲存並替換偏移量處的值為自己新的函式位址就行了。
這種技術現在已是老掉牙了,不過在實際的軟體開發中也比較常用, 可以實現各種監控功能.
上次安了個諾頓, 它把所有的 zw*** 都給 hook, 而且在 service.exe 注入了監視執行緒,作用是防止主程序被關閉.
不說別的了,免得思路被打斷了.
下面以 hook zwdeviceiocontrolfile 為例說明一下:
例如下面的 ring0 級**:
void hookstart( void )
}你能想象這樣的**能取得 zwdeviceiocontrolfile 在 ssdt 中的位置嗎?
現在再讓我們看看反彙編**：
.text:00010381 mov eax, ds:zwdeviceiocontrolfile; 儲存 zwdeviceiocontrolfile 位址到 eax
.text:00010386 mov ecx, ssdt; 取得 ssdt 的位址, 儲存到 ecx
.text:0001038c push esi
.text:0001038d mov edx, [eax+1];取得 zwdeviceiocontrolfile 在 ssdt 中的位置, 參看
; 該函式反彙編後的** b838000000 mov eax,00000038, eax+1 的效果是跳過了b8, 指向了38000000。[eax+1] 的值自然就是 00000038 (note: little-endian).現在 edx 值為 00000038.
.text:00010390 mov esi, [ecx]; 取得 ssdt 的位址 ==> esi
.text:00010392 mov edx, [esi+edx*4]; 儲存 zwdeviceiocontrolfile 真正的函式位址
.text:00010395 pop esi
.text:00010396 mov dword_10814, edx
.text:0001039c mov eax, [eax+1]; zwdeviceiocontrolfile 函式在 ssdt 的位置 ===> eax
.text:0001039f mov ecx, [ecx]; ssdt 位址
.text:000103a1 mov dword ptr [ecx+eax*4], offset sub_1030e; 用我們自己新的函式替換
; zwdeviceiocontrolfile 在ssdt位置中的數值
ok!! ,現在已經在 dword_10814 儲存了正確的 zwdeviceiocontrolfile 位址, 並把我們自己的函式 dword_10814 替換了zwdeviceiocontrolfile , 到此完成!
下面是 zwdeviceiocontrolfile的反彙編**, 可以簡單的在windbg 中用 "u zwdeviceiocontrolfile" 得到反彙編**
00400bc6: b838000000 mov eax, 00000038
00400bcb: 8d542404 lea edx, [esp+04]
00400bcf: cd2e int 2e
00400bd1: c22800 retn 0028
入口點加1，便是系統呼叫號.
直播技術細節概要
直播技術細節概要 技術細節 效能指標 接入推薦人日 費用httpdns bgp即border gateway protocol 邊界閘道器協議 國內常見公開的直播協議有幾個 rtmp,hls,hdl http flv rtp 即使用http協議流式的傳輸 內容 hls是5 7秒的延遲 rtp即rea...
android容易忽略的技術細節
1 在onpause 中進行資料持久化。activity的生命週期為oncreate onrestart onstart onresume onpause onstop ondestroy 其中oncreate onrestart onstart onresume 執行結束後不能立即結束程序，所以o...
丟包排錯錄 技術細節
sery 163.com 網管員世界 2006年7期 一 先判斷丟包發生在那裡。從辦公室的計算機分別ping 兩個機房的伺服器 然後是閘道器，通過觀察輸出進行比較，發現問題在望京機房。在用路由跟蹤的方式測試，結論也是一樣。1 從網段內的某些伺服器ping閘道器，發現丟包。2 從外網的某台計算機pin...