執行時替換函式對 golang 這類靜態語言來說並不是件容易的事情，語言層面的不支援導致只能從機器碼層面做些奇怪 hack，往往艱難，但如能成功，那掙脫牢籠帶來的成就感，想想就讓人興奮。

gohook

gohook 實現了對函式的暴力攔截，無論是普通函式，還是成員函式都可以強行攔截替換，並支援回撥原來的舊函式，效果如下(更多使用方式/介面等請參考 github上的單元測試[1]，以及 example 目錄下的使用示例)：

                                                       圖-1

以上程式碼可以在 github 上找到[1]，Linux/golang 1.4 1.12  下執行，輸出如下所示：

  
                                                   圖-2

Hook() 函式原型很簡單：

func Hook(target, replacement, trampoline interface{}) error {}

該函式接受三個引數，第一個引數是要 hook 的目標函式，第二個引數是替換函式，第三個引數則比較神奇，它用來支援跳轉到舊函式，可以理解函式替身，hook 完成後，呼叫 trampoline 則相當於呼叫舊的目標函式(target)，第三個引數可以傳入 nil，此時表示不需要支援回撥舊函式。

gohook 不僅可以 hook 一般過程式函式，也支援 hook 物件的成員函式，如下圖。

                                                  圖-3

HookMethod 原型如下，其中引數 instance 為物件，method 為方法名：

func HookMethod(instance interface{}, method string, replacement, trampoline interface{}) error {}

圖 3 執行結果如下：

                                                 圖-4

目前 GitHub 上有類似功能的第三方實現 go monkey[2]，gohook 的實現受其啟發，但 gohook 相較之有如下幾個明顯優點:

• 跳轉效率更高: 大部分情況下 gohook 通過五位元組跳轉，無棧操作，更可靠，且效能更好，實現上也更容易理解。
• 更安全可靠：跳轉需要修改和拷貝指令，極容易影響 call/jmp/ret 等舊指令，本實現支援修復函式內 call/jmp 指令。
• 支援回撥舊函式: 這是最大優點，也是 gohook 實現的初衷。
• 不依賴 runtime 內部實現: gomonkey 因為跳轉指令的原因依賴 reflect.value 來獲取 funval，而 value 內部結構並不開放，導致 go monkey  對 runtime 的內部實現產生了依賴。

實現解析

Hook 的原理是通過修改目標函式入口的指令，實現跳轉到新函式，這方面和 c/c++ 類似實踐的原理相同，具體可以參考[3]。原理好懂，實現上其實比較坎坷，關鍵有幾點:

1. 函式地址獲取

與 c/c++ 不同，golang 中函式地址並不直接暴露，但是可以利用函式物件獲取，通過將函式物件用反射的 Value 包裝一層，可以實現由 Value 的 Pointer() 函式返回函式物件中包含的真實地址。

2.跳轉程式碼生成

跳轉指令取決於硬體平臺，對於 x86/x64 來說，有幾種方式，具體可以參考文件[3]，或者 intel 開發者手冊[4]，gohook 的實現優先選用 5 位元組的相對地址跳轉，該指令用四個位元組表示位移，最多可以跳轉到半徑為 2 GB 以內的地址。

這對大部分的程式來說足夠了，如果程式的程式碼段超出了 2GB（難以想像)，gohook 則通過把目標函式絕對地址壓到棧上，再執行 ret 指令實現跳轉。

這兩種跳轉方式的結合使得跳轉實現起來相對 gomonkey 簡單容易很多，gomonkey 選用了 indirect jump，該指令需要一個函式地址的中間變數存放到暫存器，因此這個變數必須保證不會被回收，還得注意該暫存器不會被目標函式使用，導致實現上很彆扭且不安全(跳轉程式碼必須放到函式的最開始一段，不能放在中間)，更嚴重的是，因為需要直接使用函式物件，gomonkey 必須猜測 value 物件的記憶體佈局來獲取其中的 function value，runtime 實現一改，這裡就得跪。

3.成員函式的處理

成員函式在 golang 中與普通函式幾乎一樣，唯一區別是物件函式的第一個引數是物件的引用，因此 hook 成員函式與 hook 一般函式本質上是一樣的，無需特殊處理。

4.回撥舊函式

回撥舊函式是很難的，很多問題需要處理，目標函式因為入口地址要被修改，本質上一部分指令會被破壞，因此如果想回調舊函式，有幾種方式可以做到：

1.將被損壞的指令拷貝出來，在需要回調舊函式時，先將指令再恢復回去，再呼叫舊函式。
2.將被損壞的指令拷貝到另一個地方，並在末尾加上跳轉指令轉回舊函式體中相應的位置。
3.將整個舊函式拷貝一份。

gohook 目前採用了第二種方案(後續會支援第三種)，主要考慮有幾個：

• 方案一無法重入，在 golang 協程環境下幾乎無法實際使用。
• 拷貝整個函式消耗較大，且事先無法預測目標函式的大小，函式替身難以準備。

無論是拷貝一部分指令還是全部指令，其中面臨一個問題必須解決，函式指令中的跳轉指令必須進行修復。

跳轉指令要有三類：call/jmp/conditional jmp，具體來說，是要處理這三類指令中的相對跳轉指令，gohook 已經處理了所有能處理的指令，不能處理的主要是部分場景下的兩位元組指令的跳轉，原因是指令拷貝後，目標地址和跳轉指令之間的距離很可能會超過一個位元組所能表示，此時無法直接修復，當然同樣問題對四位元組相對地址跳轉來說也可能會存在，只是概率小很多，gohook 目前能檢測這種情況的存在，如果無法修復就放棄(方案三理論上可以通過替換指令克服這個問題）。

幸運的是，golang 為了實現棧的自動增長，會在每個函式的開頭加入指令對當前的棧進行檢查，使得在需要時能對棧空間做擴充處理，無論是目前的 copy stack(contigious stack) 還是 split stack[5][6][7]，函式入口的 prologue 都相當長，參考下圖. 而 gohook 理想情況下只需要五位元組跳轉，最差情況 14 位元組跳轉，目前 golang 版本下，根本不會覆蓋正常的函式邏輯指令，因此指令修復大部分情況下只是修復函式體裡的一些跳轉，這種跳轉用近距離2位元組指令的可能性相對小很多。

                                           圖-5

5.遞迴處理

遞迴函式會自己呼叫自己，從彙編的角度看，通常就是一個五位元組相對地址的 call 指令，如果我們替換當前函式，那麼這個遞迴應該調到哪裡去才對呢？

當前 gohook 的實現是跳到新函式，我個人認為這樣邏輯上似乎合理些。另一方面，在不修復指令的情況下，遞迴預設跳回函式開頭，執行插入的跳轉指令也是走到新函式，這樣行為反而一致。

實現上為達到這個目的，在需要修復指令的情況下，就需要做些特殊處理，目前做法是當看見是相對地址的 call 指令，就額外看看目的地址是不是跳到函式開頭，如果是就不修復。

為什麼只處理 Call，而不處理 jmp 呢？因為 Go 在函式末尾插入了處理棧增長的程式碼，這部分程式碼最後會跳轉回函式入口的地方，用的 JMP 指令，另外就是，函式體中也可能會有跳回函式開頭的理論性可能(可能性很小很小)，因此如果所有跳回開頭的指令都不修復，那麼這部分邏輯就出問題了，想象一下，runtime 一幫你增長棧就跳到新函式，場面太靈異。

只處理相對地址的 Call 指令理論上也是不完全夠的，雖然大部分情況遞迴用五位元組 call 很經濟實惠，但如果遞迴可以通過尾遞迴進行優化，這時編譯器很可能可能就會用  jmp 指令來跳轉，gcc 在這方面對 c 程式碼有成熟的優化案例，幸運的是目前 golang 沒聽說有尾遞迴優化，所以以後再說了，畢竟這個優化也不是那麼容易的。

注意事項

• 專案原意是用來輔助作測試，目前仍在初級階段，並未全面測試和生產驗證，可靠性有待驗證。
• 特殊情況下通過 push/retn 跳轉時，需要佔用 8 位元組棧空間，而這 8 位元組空間不會被 golang 執行時提前感知，極端情況下，如果剛好處在棧的末尾理論上可能會有問題，但
• 是根據[8][9]關於棧處理的描述，golang 對每個棧保留了幾百位元組的額外空間用來作優化，允許越過stackmin 位元組(通常是 128 bytes)，因此可能也不會有問題，這個問題我目前還不確定。
• 特殊情況下會因為某些指令因為距離溢位無法修復，從而無法 hook。
• 修復指令需要知道函式的大小，目前 gohook 通過 elf 匯出的除錯資訊進行判斷，如果二進位制 strip 過，則通過 function prologue 進行暴力搜尋，對部分特殊庫函式可能無法成功。
• 過小的函式有可能會被 inline，此時無法 hook。

• 32 位環境下沒有完整驗證過，理論上可行，測試程式碼也沒問題。
   

  引用

1、https://github.com/kmalloc/gohook

2、https://github.com/bouk/monkey

3、http://jbremer.org/x86-api-hooking-demystified/

4、https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf

5、https://agis.io/post/contiguous-stacks-golang/

6、https://dave.cheney.net/2013/06/02/why-is-a-goroutines-stack-infinite

7、https://blog.cloudflare.com/how-stacks-are-handled-in-go/

8、https://golang.org/src/runtime/stack.go

9、http://blog.nella.org/?p=