如何實現API鉤子 
--------------------------------------------------------------------------------
作者：不詳 　來源于：不詳 　發布時間：2005-2-24 14:17:00 
  
一、

序言對大多數的Windows開發者來說，如何在Win32系統中對API函數的調用進行攔截一直是項極富挑戰性的課題，因為這將是對你所掌握的計算機知識較為全面的考驗，尤其是一些在如今使用RAD進行軟件開發時并不常用的知識，這包括了操作系統原理、匯編語言甚至是關于機器指令代碼的（聽上去真是有點恐怖，不過這是事實）。

 

當前廣泛使用的Windows操作系統中，像Win 9x和Win NT/2K，都提供了一種比較穩健的機制來使得各個進程的內存地址空間之間是相互獨立，也就是說一個進程中的某個有效的內存地址對另一個進程來說是無意義的，這種內存保護措施大大增加了系統的穩定性。不過，這也使得進行系統級的API攔截的工作的難度也大大加大了。

 

當然，我這里所指的是比較文雅的攔截方式，通過修改可執行文件在內存中的映像中有關代碼，實現對API調用的動態攔截；而不是采用比較暴力的方式，直接對可執行文件的磁盤存儲中機器代碼進行改寫。 

 

 

二、

API鉤子系統一般框架通常，我們把攔截API的調用的這個過程稱為是安裝一個API鉤子（API Hook）。一個API鉤子至少有兩個模塊組成：一個是鉤子服務器（Hook Server）模塊，一般為EXE的形式；一個是鉤子驅動器（Hook Driver）模塊，一般為DLL的形式。

 

服務器主要負責向目標進程注入驅動器，使得驅動器工作在目標進程的地址空間中，這是關鍵的第一步。驅動器則負責實際的API攔截工作，以便在我們所關心的API函數調用的前后能做一些我們需要的工作。

 

一個大家比較常見的API鉤子的例子就是一些實時翻譯軟件（像金山詞霸）中必備的的功能：屏幕抓詞，它主要是對一些GDI 函數進行了攔截，獲取它們的輸入參數中的字符串，然后在自己的窗口中顯示出來。針對上述的兩個部分，有以下兩點需要我們重點考慮的： 選用何種DLL注入技術 采用何種API攔截機制

 

 三、

注入技術的選用由于在Win32系統中各個進程的地址是互相獨立的，因此我們無法在一個進程中對另一個進程的代碼進行有效的修改。而你要完成API鉤子的工作就必須進行這種操作。因此，我們必須采取某種獨特的手段，使得API鉤子（準確的說是鉤子驅動器）能夠成為目標進程中的一部分，才有較大的可能來對目標進程數據和代碼進行有控制的修改。

 

通常有以下幾種注入方式： 

 

1．利用注冊表如果我們準備攔截的進程連接了User32.dll，也就是使用了User32中的API（一般圖形界面的應用程序都符合這個條件），那么就可以簡單把你的鉤子驅動器DLL的名字作為值添加在下面注冊表的鍵下： HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Windows\AppInit_DLLs 值的形式可以為單個DLL的文件名，或者是一組DLL的文件名，相鄰的名稱之間用逗號或空格間隔。所有由該值標識的DLL將在符合條件的應用程序啟動的時候裝載。這是一個操作系統內建的機制，相對其他方式來說危險性較小，但它有一些比較明顯的缺點： 該方法僅適用于NT/2K操作系統?？纯存I的名稱你就應該明白 為了激活或停止鉤子的注入，必須重新啟動Windows。這個就似乎太不方便了 不能用此方法向沒有使用User32的應用程序注入DLL，例如控制臺應用程序 不管需要與否，鉤子DLL將注入每一個GUI應用程序，這將導致整個系統性能的下降

 

2． 

 

建立系統范圍的Windows鉤子要向某個進程注入DLL，一個十分普遍也是比較簡單的方法就是建立在標準的Windows鉤子的基礎上。Windows鉤子一般是在DLL中實現的，這是一個全局性的Windows鉤子的基本要求，這也符合我們的需要。當我們成功地調用SetWindowsHookEx函數之后，便在系統中安裝了某種類型的消息鉤子，這個鉤子可以是針對某個進程，也可以是針對系統中的所有進程。一旦某個進程中產生了該類型的消息，操作系統會自動把該鉤子所在的DLL映像到該進程的地址空間中，從而使得消息回調函數（在SetWindowsHookEx的參數中指定）能夠對此消息進行適當的處理，在這里，我們所感興趣的當然不是對消息進行什么處理，因此在消息回調函數中只需把消息鉤子向后傳遞就可以了，但是我們所需的DLL已經成功地注入了目標進程的地址空間，從而可以完成后續工作。

 

我們知道，不同進程中使用的DLL之間是不能直接共享數據的，因為它們活動在不同的地址空間中。但在Windows鉤子DLL中，有一些數據，例如Windows鉤子句柄HHook，這是由SetWindowsHookEx函數返回值得到的，并且作為參數將在CallNextHookEx函數和UnhookWindoesHookEx函數中使用，顯然使用SetWindowsHookEx函數的進程和使用CallNextHookEx函數的進程一般不會是同一個進程，因此我們必須能夠使句柄在所有的地址空間中都是有效的有意義的，也就是說，它的值必須必須在這些鉤子DLL所掛鉤的進程之間是共享的。為了達到這個目的，我們就應該把它存儲在一個共享的數據區域中。

 

在VC++中我們可以采用預編譯指令#pragma data_seg在DLL文件中創建一個新的段，并且在DEF文件中把該段的屬性設置為“shared”，這樣就建立了一個共享數據段。對于使用Delphi的人來說就沒有這么幸運了：沒有類似的比較簡單的方法（或許是有的，但我沒有找到）。不過我們還是可以利用內存映像技術來申請使用一塊各進程可以共享的內存區域，主要是利用了CreateFileMapping和MapViewOfFile這兩個函數。這倒是一個通用的方法，適合所有的開發語言，只要它能使用Windows的API。

 

在Borland的BCB中有一個指令#pragma codeseg與VC++中的#pragma data_seg指令有點類似，應該也能起到一樣的作用，但我試了一下，沒有沒有效果，而BCB的聯機幫助中對此也提到的不多，不知怎樣才能正確的使用。一旦鉤子DLL加載進入目標進程的地址空間后，在我們調用UnHookWindowsHookEx函數之前是無法使它停止工作的，除非目標進程關閉。

 

這種DLL注入方式有兩個優點： 這種機制在Win 9x/Me和Win NT/2K中都是得到支持的，預計在以后的版本中也將得到支持 鉤子DLL可以在不需要的時候，可由我們主動的調用UnHookWindowsHookEx來卸載，比起使用注冊表的機制來說方便了許多盡管這是一種相當簡潔明了的方法，但它也有一些顯而易見的缺點： 首先值得我們注意的是，Windows鉤子將會降低整個系統的性能，因為它額外增加了系統在消息處理方面的時間 其次，只有當目標進程準備接受某種消息時，鉤子所在的DLL才會被系統映射到該進程的地址空間中，鉤子才能真正開始發揮作用。因此如果我們要對某些進程的整個生命周期內的API調用情況進行監控，用這種方法顯然會遺漏某些API的調用 

 

3．

 使用 CreateRemoteThread函數在我看來這是一個相當棒的方法，然而不幸的是，CreateRemoteThread這個函數只能在Win NT/2K系統中才得到支持，雖然在Win 9x中這個API也能被安全的調用而不出錯，但它除了返回一個空值之外什么也不做。整個DLL注入過程十分簡單。我們知道，任何一個進程都可以使用LoadLibrary來動態地加載一個DLL。但問題是，我們如何讓目標進程在我們的控制下來加載我們的鉤子DLL（也就是鉤子驅動器）呢？這里有一個API函數CreateRemoteThread，通過它可在一個進程中可建立并運行一個遠程的線程。

 

調用該API需要指定一個線程函數指針作為參數，該線程函數的原型如下： Function ThreadProc(lpParam: Pointer): DWORD；我們再來看一下LoadLibrary的函數原型： Function LoadLibrary(lpFileName: PChar): HModule；可以看出，這兩個函數原型實質上是完全相同的（其實返回值是否相同關系不大，因為我們是無法得到遠程線程函數的返回值的），只是叫法不同而已，這種相同使得我們可以把直接把LoadLibrary當做線程函數來使用，從而在目標進程中加載鉤子DLL。

 

類似的，當我們需要卸載鉤子DLL時，也可以FreeLibrary作為線程函數來使用，在目標進程中移去鉤子DLL。一切看來是十分的簡潔方便。通過調用GetProcAddress函數，我們可以得到LoadLibrary函數的地址。由于LoadLibrary是Kernel32中的函數，而這個系統DLL的映射地址對每一個進程來說都是相同的，因此LoadLibrary函數的地址也是如此。這點將確保我們能把該函數的地址作為一個有效的參數傳遞給CreateRemoteThread使用。 

AddrOfLoadLibrary := GetProcAddress(GetModuleHandle(‘Kernel32.dll’), ‘LoadLibrary’); 

HremoteThread := CreateRemoteThread(HTargetProcess, nil, 0, AddrOfLoadLibrary, HookDllName, 0, nil); 

 

要使用CreateRemoteThread，我們需要目標進程的句柄作為參數。當我們用OpenProcess函數來得到進程的句柄時，通常是希望對此進程有全權的存取操作，也就是以PROCESS_ALL_ACCESS為標志打開進程。但對于一些系統級的進程，直接這樣顯然是不行的，只能返回一個的空句柄（值為零）。為此，我們必須把自己設置為擁有調試級的特權，這樣將具有最大的存取權限，從而使得我們能對這些系統級的進程也可以進行一些必要的操作。 

 

4． 

 

通過BHO來注入DLL 有時，我們想要注入DLL的對象僅僅是Internet Explorer。幸運的是，Windows操作系統為我們提供了一個簡單的歸檔的方法（這保證了它的可靠性）―― 利用Browser Helper Objects（BHO）。一個BHO是一個在 DLL中實現的COM對象，它主要實現了一個IObjectWithSite接口，而每當IE運行時，它會自動加載所有實現了該接口的COM對象。 

 

四、

 

攔截機制在鉤子應用的系統級別方面，有兩類API攔截的機制――內核級的攔截和用戶級的攔截。內核級的鉤子主要是通過一個內核模式的驅動程序來實現，顯然它的功能應該最為強大，能捕捉到系統活動的任何細節，但難度也較大，不在我們探討的范圍之內（尤其對我這個使用Delphi的人來說，還沒涉足這塊領域，因此也無法探討）；

 

而用戶級的鉤子則通常是在普通的DLL中實現整個API的攔截工作，這才是我們現在所重點關注的。攔截API函數的調用，一般可有以下幾種方法： 

1． 代理DLL（特洛伊木馬）一個容易想到的可行的方法是用一個同名的DLL去替換原先那個輸出我們準備攔截的API所在的DLL。當然代理DLL也要和原來的一樣，輸出所有函數。如果想到DLL中可能輸出了上百個函數，我們就應該明白這種方法的效率是不高的。另外，我們還得考慮DLL的版本問題。 

 

2．改寫執行代碼有許多攔截的方法是基于可執行代碼的改寫。其中一個就是改變在CALL指令中使用的函數地址，這種方法有些難度，也比較容易出錯。它的基本思路是檢索出在內存中所有你所要攔截的API的CALL指令，然后把原先的地址改成為你自己提供的函數的地址。

 

另外一種代碼改寫的方法的實現方法更為復雜，它的主要的實現步驟是先找到原先的API函數的地址，然后把該函數開始的幾個字節用一個JMP指令代替（有時還不得不改用一個INT指令），使得對該API函數的調用能夠轉向我們自己的函數調用。實現這種方法要牽涉到一系列壓棧和出棧這樣的較底層的操作，顯然對我們的匯編語言和操作系統底層方面的知識是一種考驗。這個方法倒和很多病毒的感染機制相類似。 

 

3．以調試器的身份進行攔截另一個可選的方法是在目標函數中安置一個調試斷點，使得進程運行到此處就進入調試狀態。然而這樣一些問題也隨之而來，其中較主要的是調試異常的產生將把進程中所有的線程都掛起。它也需要一個額外的調試模塊來處理所有的異常，整個進程將一直在調試狀態下運行，直至它運行結束。

4．改寫輸入地址表這種方法主要得益于現如今Windows系統中所使用的可執行文件（包括EXE文件和DLL文件）的良好結構――PE文件格式（Portable Executable File Format），因此它相當穩健，又簡單易行。要理解這種方法是如何運作的，首先你得對PE文件格式有所理解。

 

一個PE文件的結構大致如下圖所示： 一般PE文件一開始是一段DOS程序，當你的程序在不支持Windows的環境中運行時，它就會顯示“This Program cannot be run in DOS mode”這樣的警告語句，接著這個DOS文件頭，就開始真正的PE文件內容了。首先是一段稱為“IMAGE_NT_HEADER”的數據，其中是許多關于整個PE文件的消息，在這段數據的尾端是一個稱為Data Directory的數據表，通過它能快速定位一些PE文件中段（section）的地址。在這段數據之后，則是一個“IMAGE_SECTION_HEADER”的列表，其中的每一項都詳細描述了后面一個段的相關信息。接著它就是PE文件中最主要的段數據了，執行代碼、數據和資源等等信息就分別存放在這些段中。

 

在所有的這些段里，有一個被稱為“.idata”的段（輸入數據段）值得我們去注意，該段中包含著一些被稱為輸入地址表（IAT，Import Address Table）的數據列表。每個用隱式方式加載的API所在的DLL都有一個IAT與之對應，同時一個API的地址也與IAT中一項相對應。當一個應用程序加載到內存中后，針對每一個API函數調用，相應的產生如下的匯編指令： 

JMP DWORD PTR [XXXXXXXX] 

 

如果在VC++中使用了_delcspec(import)，那么相應的指令就成為

CALL DWORD PTR [XXXXXXXX]。

 

不管怎樣，上述方括號中的總是一個地址，指向了輸入地址表中一個項，是一個DWORD，而正是這個DWORD才是API函數在內存中的真正地址。因此我們要想攔截一個API的調用，只要簡單的把那個DWORD改為我們自己的函數的地址，那么所有關于這個API的調用將轉到我們自己的函數中去，攔截工作也就宣告順利的成功了。這里要注意的是，自定義的函數的調用形式應該是API的調用方式，也就是stdcall方式，而Delphi中默認的是pascal的調用方式，也就是register方式，它們在參數的傳遞方式等方面存在著較大的區別。