在Window平臺上開發任何稍微底層一點的東西，基本上都是Hook滿天飛， 普通應用程序如此，安全軟件更是如此， 這里簡單記錄一些常用的Hook技術。
基本上做Windows開發都知道這個API， 它給我們提供了一個攔截系統事件和消息的機會， 并且它可以將我們的DLL注入到其他進程。
但是隨著64位時代的到來和Vista之后的UAC機制開啟，這個API很多時候不能正常工作了：
首先，32位DLL沒法直接注入到64位的應用程序里面， 因為他們的地址空間完全不一樣的。當然盡管沒法直接注入，但是在權限范圍內，系統會盡量以消息的方式讓你能收到64位程序的消息事件。
其次，UAC打開的情況下低權限程序沒法Hook高權限程序， 實際上低權限程序以高權限程序窗口為Owner創建窗口也會失敗， 低權限程序在高權限程序窗口上模擬鼠標鍵盤也會失敗。
有人說我們可以關閉UAC， Win7下你確實可以，但是Win8下微軟已經不支持真正關閉UAC， 從這里我們也可以看到微軟技術過渡的方式， 中間會提供一個選項來讓你慢慢適應，最后再把這個選項關掉， UAC和Aero模式都是如此。
那么我們如何解決這些問題？
對于64位問題 ， 解決方法是提供2個DLL，分別可以Hook32和64位程序。
對于權限問題， 解決方法是提升權限， 通過注冊系統服務， 由服務程序創建我們的工作進程。這里為什么要創建一個其他進程而不直接在服務進程里干活？ 因為Vista后我們有了Session隔離機制，服務程序運行在Session 0，我們的其他程序運行在Session 1, Session 2等， 如果我們直接在服務程序里干活，我們就只能在Session 0里工作。通過創建進程，我們可以在
DuplicateTokenEx后將Token的SessionID設置成目標Session，并且在
CreateProcessAsUser時指定目標WinStation和Desktop， 這樣我們就既獲得了System權限，并且也可以和當前桌面進程交互了。
很多人可能都不知道這個API， 但是這個API其實挺重要的， 看名字就知道它是Hook事件(Event)的， 具體哪些事件可以看
這里.
為什么說這個API重要， 因為這個API大部分時候沒有SetWindowsHookEx的權限問題， 也就是說這個API可以讓你Hook到高權限程序的事件， 它同時支持進程內(WINEVENT_INCONTEXT)和進程外(WINEVENT_OUTOFCONTEXT)2種Hook方式， 你可以以進程外的方式Hook到64位程序的事件。
為什么這個API沒有權限問題， 因為它是給Accessibility用的， 也就是它是給自動測試和殘障工具用的， 所以它要保證有效。
我曾經看到這樣一個程序，當任何程序(無論權限高低)有窗口拖動(拖標題欄改變位置或是拖邊框改變大小)， 程序都能捕獲到， 當時很好奇它是怎么做到的？
Spy了下窗口消息, 知道有這樣2個消息：WM_ENTERSIZEMOVE和WM_EXITSIZEMOVE表示進入和退出這個事件， 但是那也只能獲得自己的消息，其他程序的消息它是如何捕獲到的？當時懷疑用的是Hook， 卻發現沒有DLL注入。查遍了Windows API 也沒有發現有API可以查詢一個窗口是否在這個拖動狀態。最后發現用的是SetWinEventHook的EVENT_SYSTEM_MOVESIZESTART和EVENT_SYSTEM_MOVESIZEEND。
API Hook
常見的API Hook包括2種， 一種是基于PE文件的導入表(IAT), 還有一種是修改前5個字節直接JMP的inline Hook.
對于基于IAT的方式， 原理是PE文件里有個導入表， 代表該模塊調用了哪些外部API，模塊被加載到內存后， PE加載器會修改該表，地址改成外部API重定位后的真實地址， 我們只要直接把里面的地址改成我們新函數的地址， 就可以完成對相應API的Hook。《Windows核心編程》里第22章有個封裝挺好的CAPIHook類，我們可以直接拿來用。
對于基于Jmp方式的inline hook, 原理是修改目標函數的前5個字節， 直接Jmp到我們的新函數。雖然原理挺簡單， 但是因為用到了平臺相關的匯編代碼， 一般人很難寫穩定。真正在項目中用還是要求穩定， 所以我們一般用微軟封裝好的Detours, 對于Detours的原理，這里有篇不錯的文章 微軟研究院Detour開發包之API攔截技術。
比較一下2種方式：
IAT的方式比較安全簡單， 但是只適用于Hook導入函數方式的API。
Inline Hook相對來說復雜點， 但是它能Hook到任何函數(API和內部函數)，但是它要求目標函數大于5字節， 同時把握好修改時機或是Freeze其他線程， 因為多線程中改寫可能會引起沖突。
還有一種是Hook被調用模塊的導出表（EAT）， 但是感覺一般用得用的不多。原理是調用模塊里IAT中的函數地址是通過被調用模塊的EAT獲取的， 所以你只要修改了被調用模塊的EAT中的函數地址，對方的調用就自然被你Hook了。但是這里有個時機問題， 就是你替換EAT表要足夠早，要在IAT使用它之前才行。但是感覺這個行為是由PE加載器決定的， 一般人很難干涉， 不知道大家有什么好方法？
我們一般可以將IAT Hook和EAT Hook結合起來使用， 先枚舉所有模塊Hook IAT，這樣當前已有模塊的API都被你Hook了，然后再Hook EAT， 這樣后續的模塊也被你Hook了（因為要通過EAT獲取函數地址）。
如果你只用Hook IAT而不Hook EAT, 當有新模塊加載時，你要Hook它的IAT， 所以你就要Hook LoadLibrary(Ex)和GetProcAddress來攔截新模塊的加載。所以理論上感覺 Hook EAT不是很有必要， 因為單用Hook IAT已經可以解決我們所有的問題了， HOOK IAT還有一種優勢是我們可以過濾某個模塊不Hook，而一旦hook EAT， 它就會影響我們所有調用該函數的模塊。
COM Hook
Window上因為有很多開發包是以COM方式提供的(比如DirectX)， 所以我們就有了攔截COM調用的COM Hook。
因為COM里面很關鍵的是它的接口是C++里虛表的形式提供的， 所以COM的Hook很多是時候其實就是虛表（vtable）的Hook。
對于COMHook，考慮下面2種case：
一種是我們Hook程序先運行，然后啟動某個游戲程序（DirectX 9）， 我們想Hook游戲的繪畫內容。
這種方式下， 我們可以先Hook API Direct3DCreate9， 然后我們繼承于IDirect3D9， 自己實現一個COM對象返回回去， 這樣我們就可以攔截到所有對該對象的操作，為所欲為了， 當然我們自己現實的COM對象內部會調用真正的Direct3DCreate9，封裝真正的IDirect3D9。
當然有時我們可能不用替代整個COM組件，我們只需要修改其中一個或幾個COM函數， 這種情況下我們可以創建真正的IDirect3D9對象后直接修改它的虛表， 把其中某些函數改成我們自己的函數地址就可以了。
還有一種case是游戲程序已經在運行了， 然后才啟動我們的Hook進程， 我們怎么樣才能Hook到里面的內容？
這種情況下我們首先要對程序內存有比較詳細的認識， 才能思考創建出來的D3D對象的虛表位置， 從而進行Hook， 關于程序內存布局，可見我這篇 理解程序內存。
理論上說COM對象如果是以C++接口的方式實現， 虛表會位于PE文件的只讀數據節(.rdata), 并且所有該類型的對象都共享該虛表， 所以我們只要創建一個該類型對象，我們就可以獲得其他人創建的該類型對象的虛表位置，我們就可以改寫該虛表實現Hook（實際操作時需要通過VirtualProtect修改頁面的只讀屬性才能寫入）。
但是實際上COM的虛表只是一塊內存， 它并不一定是以C++實現， 所以它可以存在于任何內存的任何地方。另外對象的虛表也不一定是所有同類型的對象共享同一虛表， 我們完全可以每個對象都有自己的一份虛表。比如我發現IDirect3D9是大家共享同一虛表的（存在D3D9.dll）， 但是IDirect3DDevice9就是每個對象都有自己的虛表了(存在于堆heap)。所以如果你要Hook IDirect3DDevice9接口，通過修改虛表實際上沒法實現。
但是盡管有時每個對象的虛表不一樣，同類型對象虛表里的函數地址卻都是一樣的， 所以這種情況下我們可以通過inline Hook直接修改函數代碼。當然有些情況下如果是靜態鏈接庫，即使函數代碼也是每個模塊都有自己的一份， 這種情況下就只能反匯編獲取虛表和函數的地址了。
posted on 2013-11-08 08:15
王海光 閱讀(715)
評論(0) 編輯 收藏 引用 所屬分類:
C++