一、引言

Windows系統是建立在事件驅動的機制上的，每一個事件就是一個消息，每個運行中的程序，也就是所謂的進程，都維護者一個或多個消息隊列，消息隊列的個數取決于進程內包含的線程的個數。由于一個進程至少要擁有一個線程，所以進程至少要有一個消息隊列。雖然Windows系統的消息分派是以線程為單位的，但并不是所有的線程都有消息隊列，一個新創建的線程是沒有消息隊列的，只有當線程第一次調用GDI或USER32庫函數的時候Windows才 為線程創建消息隊列。消息最終由屬于線程的窗口來處理，普通的應用程序只能獲取本線程的消息隊列中的消息，也就是只能獲得系統分派的、屬于本線程的消息， 換句話說，一個線程在運行過程中是不知道其它線程發生了什么事情的。但是有一類特殊的程序卻可以訪問其他線程的消息隊列，那就是鉤子程序。

編寫鉤子程序是Windows系統提供給用戶的一種對Windows運行過程進行干預的機制，通過鉤子程序，Windows將 內部流動的消息暴露給用戶，使用戶能夠在消息被窗口管理器分派之前對其進行特殊的處理，比如在調試程序的時候跟蹤消息流程。但是，任何事情都有其兩面性， 一些密碼竊取工具就是利用系統鍵盤鉤子截獲其他程序的鍵盤消息，從而獲取用戶輸入的密碼，可見非法的鉤子程序對計算機信息安全具有極大的危害性。本文針對 鉤子程序安裝和運行的特點，設計了一種檢測系統中安裝的鉤子程序的方案，并開發了一個檢測鉤子程序的開源軟件AntiHook。

二、鉤子檢測的原理

在開始分析鉤子檢測的原理之前先要了解一下鉤子程序。Windows系統的鉤子程序根據作用范圍可以分為兩類：一類是只能獲取本進程內某個線程消息的局部鉤子（Thread Local Hook），另一類是可以獲取當前系統中所有線程消息的全局鉤子（Global Hook 或 System Hook）。局部鉤子的程序代碼既可以位于線程相關的EXE可執行文件中，也可以位于DLL動態鏈接庫中，全局鉤子則只能是DLL動態鏈接庫的形式，這是由全局鉤子的加載方式所決定的，本文稍后將詳細介紹原因。鉤子程序根據定義方式與實現目的又可分為鍵盤鉤子、鼠標鉤子、系統Shell鉤子以及消息過濾鉤子等類型，查閱MSDN中關于SetWindowsHookEx()函數的說明可以了解這些不同類型鉤子的詳細信息。

對 于局部鉤子來說，它所能夠訪問到的消息僅限于它所在的進程中的消息隊列，在安裝鉤子的時候需要指明是要截取哪個線程的消息。與之相對應的全局鉤子則沒有范 圍的限制，它可以截取整個桌面環境下所有線程中的消息，用來竊取密碼的鍵盤鉤子通常就是將自己安裝成全局鉤子。安裝局部鉤子和全局鉤子使用的是同一個API函數：SetWindowsHookEx()，只是傳遞的參數不同，關于這個API函數的用法不是本文的重點，此處就不詳細介紹了，對鉤子程序感興趣的朋友可以參考MSDN或其它相關文檔。

一般來講，應用程序安裝的局部線程鉤子對其他程序沒有影響，而危害比較大的是全局鉤子，因為只有全局鉤子有能力“染指”其它程序的消息隊列，系統的安全檢測也以檢測全局鉤子為主要目的。全局鉤子檢測的原理其實也非常簡單，這是由Windows操作系統加載全局鉤子的方式所決定的，所以我們先來了解一下全局鉤子的加載方式。

32位的Windows程序都是運行在保護模式，每一個進程都有獨立的進程空間，進程之間不能直接共享內存地址，也就是說，進程之間的資源是嚴格受保護的，一個進程不能直接訪問另一個進程中的資源，當然也包括消息隊列。既然Windows保護地如此嚴格，鉤子程序又是如何做到這一點呢，難道它能夠凌駕于操作系統之上？當然不是，鉤子程序和普通的Windows應用程序一樣只能運行在Ring3安全級別上，它的詭秘之處在于Windows對鉤子程序的加載方式。當鉤子安裝程序調用SetWindowsHookEx()函數在系統中安裝一個全局鉤子后，Windows對鉤子程序做的特殊處理就是將其加載到每個應用程序單獨的進程空間中。也就是說，系統中每一個程序（包括系統程序）的進程空間中都被Windows“強行”掛接了一個鉤子程序（模塊）的副本，這就使鉤子模塊和應用程序所倚賴的其它模塊一樣運行在這個程序的進程空間之中，如此一來鉤子程序就能夠訪問這個進程中所有線程的消息隊列了。

本文前面提到，全局鉤子必須做成DLL動 態鏈接庫的形式，這里就解釋了原因－－因為全局鉤子不是獨立運行的程序，它是作為其它程序的一部分被加載運行的。原理就是如此的簡單，當一個全局鉤子安裝 后，系統中運行的每個進程都被強行加載了一個鉤子程序的模塊，這就為檢測鉤子提供了一個思路，那就是檢測程序作為系統中運行的普通程序也會被強行加載鉤子 模塊，只要鉤子檢測程序能夠發現自己進程空間中被強行加載的不明模塊，就可以懷疑系統中運行有鉤子程序。

現在的問題是如何使鉤子檢測程序能夠發現加載到自己進程空間中的不明模塊。使用API HOOK介 入模塊的運行，直接分析二進制代碼可能是最直接、最有效的方法，但是且不說這種方法容易破壞系統運行的穩定性，單就二進制代碼的邏輯分析就不是少量代碼能 夠實現的。那么有沒有簡單一點的方法呢？其實，繞開這些技術層面上的問題的糾纏，還有更簡單的方法能夠檢測不明模塊，那就是“模塊比較法”。和普通的Windows應用程序一樣，鉤子檢測程序運行時也需要很多系統模塊的支持，這些模塊是運行鉤子檢測程序所必須的，也被認為是安全的模塊。而被Windows “強行”加載的鉤子模塊則不是鉤子檢測程序運行必須的模塊，所以被認為是不明模塊。鉤子檢測程序一旦編譯完成，就已經決定了它在運行中需要哪些支持模塊，有一點需要注意，那就是模塊的名稱和數量在Windows 95/98/Me系統下和基于Windows NT技術構建的Windows 2000/XP系統下有很大的不同，但是對于特定的Windows 版 本來說是一定的，這也是“模塊比較法”的主要理論依據。“模塊比較法”的原理就是定期查看鉤子檢測程序進程中加載的模塊列表，將這個列表與安全模塊列表做 對比，檢查是否有不屬于安全模塊的不明模塊被加載到檢測程序的進程空間中，如果發現不明模塊就發出告警，提示用戶作出相應的處理。剩下的問題就是創建安全 模塊列表并將其保存到程序配置文件中，利用Depends工具或進程模塊查看工具可以很容易地獲取鉤子檢測程序所必須的支持模塊（安全模塊），唯一需要注意的是要在一個“干凈”的Windows 系統上執行這些操作。

“模塊比較法”的關鍵是查找進程加載的所有模塊，在Windows平臺上有很多查看進程信息的方法，比如Toolhelp系列API、PSAPI、CDPH API，甚至是使用Windows NT的Native API，由于鉤子檢測程序不需要詳細的模塊信息，所以使用Toolhelp系列API和PSAPI兩種方法就足夠了。使用PSAPI遍歷進程和模塊信息比使用Toolhelp系列API效率高，但是PSAPI不支持較早的Windows系統，比如Windows 98，所以需要Toolhelp系列API提供對Windows 98這樣的操作系統的支持。使用Toolhelp API遍歷進程模塊信息首先要調用CreateToolhelp32Snapshot得到進程加載的所有模塊信息的一個“快照”，然后使用Module32First和Module32Next配合遍歷“快照中的信息”，下面的代碼演示了如何使用Toolhelp API遍歷進程模塊信息：

MODULEENTRY32 module;

DWORD dwCurProcID = ::GetCurrentProcessId();

//給當前進程的模塊做個快照

HANDLE hModEnum = ::CreateToolhelp32Snapshot(TH32CS_SNAPMODULE,dwCurProcID);

if(hModEnum != INVALID_HANDLE_VALUE)

{

??? module.dwSize=sizeof(MODULEENTRY32);

??? if(::Module32First(hModEnum,&module))

??? {

??????? do

??????? {

??????????? //對module中的模塊信息進行處理，比如判斷是否是不明模塊等等

??????? }while(::Module32Next(hModEnum,&module));

??? }

??? ::CloseHandle(hModEnum);//關閉快照，釋放資源

}

本文來自CSDN博客，轉載請標明出處：http://blog.csdn.net/chinawash/archive/2006/08/30/1143729.aspx