[[177879]]

前言

在日常分析使用某個軟件的過程中，如果我們想要去挖掘軟件的漏洞、或者是通過打補丁的方式給軟件增添一些新的功能，抑或是為了記錄下軟件運行過程中被調用的函數及其參數，有時候我們需要劫持對某些DLL庫的調用過程。在一般情況下，如果我們是軟件的開發者或者該軟件提供源碼下載，那么剛才提到的問題只要對源碼進行一定的修改就可以了，簡直是小菜一碟。但是在更多情況下，我們無從獲取軟件或是庫的源碼，因為他們根本沒有采用源碼發行的方式。那這樣我們是否就一籌莫展了呢?通過閱讀這篇文章，我會告訴你最流行的“API鉤子”方法是什么，并且會以略微不同的方式展現給大家。

API鉤子

正如上文我們已經提到的，劫持DLL最流行的方法被稱作“API鉤子”——一種將庫函數調用重定向到你的代碼的技術。最為流行的API鉤子庫非微軟的 Microsoft Detours (常用于游戲破解)莫屬，并且這個商業庫被打上的價值標簽已經高達9999.95美元(約68999元人民幣)。再舉一個例子，在Dephi語言中有一個庫叫做 madCodeHook，他的商業價值約為349歐元(約2564元人民幣)。

下面就讓我們來看一看API鉤子的具體實現原理。

對于已經加載的DLL庫及對應函數，通過在想要鉤取的函數頭部首字節打上一個補丁(也叫重寫，個人認為叫覆蓋最為貼切)，補丁內容為一個JMP指令，像是 JMP NEAR 這樣的形式，轉換成16進制就是 E9 xx xx xx xx。如下圖所示：

圖1：被鉤取的函數前后內容示意

當控制權被傳遞到我們鉤取過的函數后，通常這時就可以執行我們自己想要執行的代碼了，執行完畢后又會接著運行原函數然后返回到之前從DLL庫中調用該函數的代碼位置。

API鉤子其實會導致一些問題，而問題的來源就在于編譯過的軟件結構和它本身的代碼結構。當我們想要通過鉤子本身來調用原函數的時候(通常不加處理情況下會導致一個死循環)，我們必須要創建一個特殊的代碼區塊來調用原函數代碼，這個代碼區塊有個別稱叫做“蹦床”(個人覺得在國內更常被稱為跳板)，這樣的話就不用管鉤子本身是否在要調用的函數體內了。

另外需要說明的是，API鉤子技術不是萬能的，在受保護的DLL庫中幾乎不可能實現。說得詳細一點就是，比如存在CRC校驗保護的時候，無論是從硬盤上還是內存中對庫DLL庫代碼的修改都是不可行的。

還有一點就是，經典的API鉤子也不適用于DLL庫導出的“偽函數”，這里的偽函數是指導出的變量、類指針等等。因為在這種類型的“函數”條件下我們根本不可能在原函數和我們的代碼之間建立一個經典的代碼鉤子(事實上根本就沒有函數可鉤取)。那是不是就無可奈何了呢?上面我們提到的方法是改寫原函數代碼，而下面要介紹的第二種常見方法就是修改PE導出表。只不過這種方法的局限性很大，遠不如前一種流行，而且只有很少的一部分鉤子庫支持它。

DLL轉發

一種更加有創意但是也更為麻煩的API鉤取方式叫做“DLL”轉發，它通過Windows的內部機制來實現，基本原理就是轉發DLL調用至其他模塊。

DLL轉發技術基于“替換表“來實現，所以也被稱為“DLL代理”，它可以導出所有的原始庫函數，也可以傳遞所有對庫函數的調用——除了我們想要鉤取的那部分函數。而函數調用是被通過一些鮮為人知的Windows機制傳遞給原函數庫的，這樣我們就可以借此來調用其他庫函數，裝作他們本來就是存儲在我們使用的API鉤子庫里一樣，但事實上這些代碼被存儲在其他的庫中。弄明白以上這些過程，我們也就不難得知為什么要叫做“DLL轉發”了。

函數調用慣例

函數調用慣例是一個低等級的用于傳遞函數參數和處理函數調用返回前的堆棧的方式。很大一部分情況下它取決于編譯時的設置，并且在大多數高級編程語言中可以任意選擇函數調用的方式，所以兩者任取其一均可。為了讓我們的API鉤子庫正常運行，它的鉤取函數也必須使用和已經被鉤取的函數相同的調用慣例。他們只有在二進制情況下相互兼容才不會引發像堆棧破壞之類的異常。

表1. 函數調用慣例

調用慣例高度依賴于編譯器的默認設置，比如Delphi默認采用register調用慣例，C語言默認采用cdecl調用慣例。

WinAPI函數(Windows系統函數)默認使用stdcall調用慣例，所以在調用之前，函數的參數都使用push指令存儲在棧中，然后call指令被執行，執行完畢后并沒有必要去修正棧指針ESP，因為在stdcall調用慣例中，棧在函數返回前是自動修正的。這里值得一提的是，一個很有趣的現象是WinAPI中的有些函數并不使用stdcall而是C語言的cdecl，cdecl并不將參數存儲于棧，但棧的修正會在調用完成后根據函數參數的數量被編譯器修正。舉一個例子，user32.dll中的一個函數wsprintfA()(它在C函數庫中的對應是sprintf())就采用cdecl慣例，這種調用方式是備受推崇的，因為這樣除了編譯器之外沒有人知道究竟傳遞了多少個參數。

API鉤子實例

作為一個例子，我想讓它盡量簡單易懂一點，只會用到一個測試庫BlackBox.dll，它只導出兩個函數Sum()和Divide()，想必你已經猜到了，第一個函數的作用是兩個數的求和，第二個函數是兩個數的除法。讓我們假設我們擁有一個完整的庫文檔，并且清楚地知道這兩個函數使用的調用慣例(假設我們有這個庫的頭文件)，而且我們還知道它們各自都使用哪些參數。在其他情況下我們需要使用逆向工程來獲得這些底層信息。

代碼清單1：

6// 該函數將兩個數相加并將結果儲存于Result變量中 
// 成功返回TRUE，失敗返回ERROR  
BOOL __stdcall Sum(int Number1, int Number2, int * Result);  
// 該函數將兩個數相除并將結果儲存于Result變量中  
// 成功返回TRUE，失敗返回ERROR  
BOOL __stdcall Divide(int Number1, int Number2, int * Result); 

在我們的樣例庫中，Divide()函數是有bug的，因為如果除0就會導致程序崩潰(假設我們的程序并沒有做異常處理)，現在我們的目標就是來修補這個漏洞。

代理DLL

為了修補BlackBox.dll中的漏洞，我們接下來需要創建一個中間庫，能夠使Divide()函數得以有效應用而不出現除0異常。該應用采用FASM編譯器(波蘭的mr Tomasza Grysztar 創建)的32位匯編器。在下面你會看到帶有精確注釋的樣例庫模板。

代碼清單2：樣例庫的開頭

-------------------------------------------------  
; DLL 輸出文件格式  
;-------------------------------------------------  
format PE GUI 4.0 DLL  
; DLL 入口點函數名  
entry DllEntryPoint  
; 導入的Windows函數和常數  
include '%fasm%\include\win32a.inc' 

注意源代碼的開頭，你可以在找到輸出文件的類型聲明，并且在頭文件、DLL庫的函數入口點也可以放置這些代碼。

代碼清單3：未初始化的數據段

;------------------------------------------------- 
; 未初始化的數據段 
;------------------------------------------------- 
section '.bss' readable writeable 
; uchwyt HMODULE oryginalnej biblioteki 
hLibOrgdd ? 

可執行文件和DLL庫被分割為一個個獨立的部分，他們其中之一是未初始化的數據段，這部分并不占用硬盤的空間，僅僅擁作于記錄程序所使用的未初始化變量的整體大小信息。可執行文件的段名稱并不重要(它被限制為最多只有8個字符)，通常它會被賦以公司合同的名稱。在這個段的聲明中還會定義訪問權限(如讀、寫、執行)，但是在FASM編譯器下.bss段的聲明還會為變量創建一個未初始化的段。

代碼清單4：數據段

;------------------------------------------------- 
; 初始化的數據段 
;------------------------------------------------- 
section '.data' data readable writeable 
; 原始庫的名稱 
szDllOrgdb 'BlackBox_org.dll',0 

因為原始庫已經有了名稱了，所以這里我們重命名一個BlackBox_org.dll(它以ASCII形式存儲于源代碼中，以null結束)，這個庫會在后面用到。

代碼清單5：帶有DLL入口點的代碼段

;------------------------------------------------- 
; 庫的代碼段 
;------------------------------------------------- 
section '.text' code readable executable 
;------------------------------------------------- 
; DLL庫入口點 (DllMain) 
;------------------------------------------------- 
proc DllEntryPoint hinstDLL, fdwReason, lpvReserved 
moveax,[fdwReason] 
; DLL library 加載完畢后立即傳遞事件 
cmpeax,DLL_PROCESS_ATTACH 
je_dll_attach 
jmp_dll_exit 
; 庫已經加載 
_dll_attach: 
; 獲得原始 DLL 庫的句柄 
; 如果想要調用原始函數就會使用 
pushszDllOrg 
call[GetModuleHandleA] 
mov[hLibOrg],eax 
; 返回 1 說明庫初始化成功 
moveax,1 
_dll_exit: 
ret 

代碼段包含所有庫函數和DLL入口點函數。這是一個特殊的函數，它在庫加載以后被Windows系統函數調用。代碼段需要被標記上可執行的標記，以此來告訴操作系統這段內存區域包含可以執行的代碼段。如果沒有這樣標記，那么任何想從這塊內存區域執行代碼的行為都會以觸發CPU處理器的DEP(Data Execution Prevention)內存保護機制而告終。在初始化函數內部(DllMain),接收到 DLL_PROCESS_ATTACH 事件后我們將使用原始DLL庫名稱來獲得他的句柄，也就是 HMODULE (這樣之后就可以被調用了)。

代碼清單6：過度優化保護

; 調用任何原始庫 
; BlackBox_org.dll 中的函數, 沒有它FASM編譯器就會 
; 移除對庫的引用并且不會被自動加載 
calldummy 

我們自定義的庫會調用到原始庫，但是如果我們一點引用也不放在源代碼中，FASM編譯器會移除所有對它的引用(優化)而且原始庫并不會被自動加載，這就是為什么在ret指令后直接放了一個偽調用的緣故(這樣在任何時候都不會執行)。

代碼清單7：有效的Divide()函數代碼

;------------------------------------------------- 
; 我們修改后能夠處理除0錯誤的Divide() 函數 
;------------------------------------------------- 
proc Divide Number1, Number2, Result 
; 檢查除數是否為0 
; 如果是的話返回ERROR代碼 
movecx,[Number2] 
testecx,ecx 
jeDivisionError 
; 將第一個數字載入 EAX 處理器 
moveax,[Number1] 
;擴展 EDX 寄存器來處理有符號數 
cdq 
; 現在 EDX:EAX 寄存器對可以處理64位數據了 
; EDX:EAX / ECX 除法的實現, 除法在EDX:EAX寄存器對 
; 上實現，就像對待64位數據一樣, 除法的結果保存在EAX 
; 寄存器中, 余數保存在EDX 寄存器中 
idiv ecx 
; 檢查有效的指向結果的指針 
; 如果沒有檢測到則返回error 代碼 
movedx,[Result] 
testedx,edx 
jeDivisionError 
; 在受保護的地址存儲除法的結果 
mov[edx],eax 
; 以 exit code TRUE (1) 返回 
moveax,1 
jmpDivisionExit 
; 除法錯誤，返回FALSE (0) 
DivisionError: 
sub eax,eax 
DivisionExit: 
; 從除法函數中返回 
; 布爾型的exit 代碼被設置在 EAX 寄存器中 
ret 
endp 

修改后的Divide()函數的實現增添了對除0錯誤的校驗，函數遇到錯誤會返回錯誤代碼FALSE，另外還額外做了對指向結果變量result的指針非空檢查，如果指針指向null也會報錯。另外請注意，修改后的函數的調用慣例與原函數是完全一致的，并且在我們的這個例子中使用的是stdcall慣例，所以函數參數被傳遞到棧中，函數返回值儲存于EAX寄存器，棧指針也被FASM編譯器自動修復，方法是根據源代碼中的ret聲明生成ret (number_of_parameters * 4)指令。

代碼清單8：庫的導入表

;------------------------------------------------- 
; 我們的庫使用的函數段 
;------------------------------------------------- 
section '.idata' import data readable writeable 
; 在代碼中用到的庫的列表 
library kernel,'KERNEL32.DLL',\ 
blackbox, 'BlackBox_org.dll' 
; KERNEL32.dll庫的函數列表 
importkernel,\ 
GetModuleHandleA, 'GetModuleHandleA' 
; 聲明了原始庫的用途 
; DLL 庫會被自動加載 
importblackbox,\ 
dummy, 'Divide' 

FASM編譯器允許我們手動地定義我們自己的庫調用到的庫和函數，除了標準系統庫，我們需要在這里添加一個對 BlackBox.dll 的引用。多虧于此，當Windows加載我們的鉤子庫的同時也會根據地址空間加載原始庫，從而無需再手動調用 LoadLibraryA() 函數來加載它。 在某些情況下想要使用導入表來加載庫甚至是強制性要求使用 LoadLibraryA() 的，它需要使用多線程應用程序中TLS(Thread Local Storage)機制的動態鏈接庫來支持。

代碼清單9：函數導出表

;------------------------------------------------- 
; 導出表段包含我們的庫中導出的函數 
; 這里我們也許要聲明原始庫中聲明的函數 
;------------------------------------------------- 
section '.edata' export data readable 
; 導出函數列表及其指針 
export'BlackBox.dll',\ 
Sum, 'Sum',\ 
Divide, 'Divide' 
; 轉發表名稱, 首先目的庫被存儲 (無需.DLL擴展) 
; 然后最終的函數名稱被存儲 
Sum db 'BlackBox_org.Sum',0 

在這個段中我們必須聲明原始庫中的所有函數，而且我們想要鉤取的函數必須在代碼中得以應用，想要傳遞給原始庫的函數存儲在一個特殊的文本格式中：

DestinationDllLibrary.FunctionName

或

DestinationDllLibrary.#1

以此來順序導入函數而非按照名稱的順序。該機制的所有內部工作均交由Windows系統自身處理。以上為DLL轉發。

代碼清單10：重定位部分

;------------------------------------------------- 
; 重定位部分 
;------------------------------------------------- 
section '.reloc' fixups data discardable 

我們的庫中最后一個段是重定位段，它保證了我們的庫能夠正常運行。這是因為動態鏈接庫被加載的基地址是非常多變的，而引起這個多變性的原因在于指針使用的絕對地址和匯編器的指令使用的絕對地址必須根據當前內存中的基地址做出更新，而這個基地址的信息正是由編譯器在重定位段中生成的。

總結

這篇API鉤子介紹的方法可以被成功應用于各種使用動態鏈接庫的場合，較傳統的經典API鉤子方法而言各有利弊，但是在我看來本文的方法為實踐打開了更大的拓展空間，并提供了一種更加簡單的改變軟件完整功能性的方法。該方法同樣可以在高級語言中以適當的導出函數定義文件(DEF)的方式實現。