利用Ghidra逆向分析Go二進制程序(下篇)
動態分配字符串結構
在第一種情況下,字符串結構是在運行時創建的,為此,需要使用一系列匯編指令在字符串操作之前設置相應的結構。由于指令集的不同,不同的架構之間的結構也是不同的。讓我們通過幾個案例,來展示我們的腳本(find_dynamic_strings.py)尋找的指令序列。
x86架構下字符串結構的動態分配
首先,我們先來看看“Hello Hacktivity”這個例子。

圖20 hello_go中字符串結構的動態分配情況
圖21 hello_go中未定義的“hello, hacktivity”字符串
運行腳本后,代碼是這樣的:
圖22 執行find_dynamic_strings.py后,hello_go中動態分配的字符串結構
可以看到,該字符串已經被定義:
圖23 hello_go中已經定義了“hello hacktivity”字符串
同時,字符串“hacktivity”也可以在Ghidra的Defined Strings視圖中找到。
圖24 通過"hacktivity"過濾在hello_go中已定義的字符串
實驗證明,我們的腳本能夠在32位和64位x86二進制文件中尋找以下指令序列:
圖25 eCh0raix字符串結構的動態分配
圖26 hello_go中動態分配的字符串結構
ARM架構下字符串的動態分配
對于32位ARM架構,我們將以eCh0raix勒索軟件樣本為例來說明字符串的恢復方法。
圖27 eCh0raix中字符串結構的動態分配
圖28 eCh0raix中指向字符串地址的指針
圖29 eCh0raix中未定義的字符串
執行腳本后,代碼將變成下面的樣子:
圖30 執行find_dynamic_strings.py后,eCh0raix中動態分配字符串結構
我們可以看到,指針已經被重新命名,并定義了字符串:
圖31 執行find_dynamic_strings.py后,eCh0raix中指向字符串地址的指針
圖32 執行find_dynamic_strings.py后,eCh0raix中定義的字符串
該腳本在32位ARM二進制文件中查找可以下指令序列:
對于64位ARM架構,我們將通過一個Kaiji樣本來演示字符串的恢復方法。在這里,代碼使用了兩個指令序列,但是只在一個序列中發生了變化:
圖33 Kaiji中字符串結構的動態分配
執行腳本后,代碼將變為:
圖34 執行find_dynamic_strings.py后,Kaiji中字符串結構的動態分配情況
我們可以看到,這些字符串已經被定義:
圖35 執行find_dynamic_strings.py后,Kaiji中定義的字符串
該腳本能夠在64位ARM二進制文件中找到以下指令序列:

如您所見,該腳本可以恢復動態分配的字符串結構。這非常有助于逆向工程師閱讀匯編代碼,或在Ghidra中的Defined String視圖中尋找可疑的字符串。
這種方法所面臨的挑戰
這種方法最大的缺點是,每種架構(甚至同一架構內的不同解決方案)都需要在腳本中添加一個新的分支。而且,規避這些預定義的指令集是很容易的。在下面的例子中,對于Kaiji 64位ARM惡意軟件樣本來說,由于字符串的長度被移到了一個寄存器中,而腳本卻沒有預料到這一點,因此會漏掉這個字符串。
圖36 Kaiji以不尋常的方式動態分配字符串結構
圖37 Kaiji中一個未定義的字符串
靜態分配字符串結構
在接下來的這個案例中,我們的腳本(find_static_strings.py)用于查找靜態分配的字符串結構。這意味著字符串指針后面是字符串長度。
這就是x86 eCh0raix勒索軟件樣本中找到的字符串指針及其長度:
圖38 eCh0raix中靜態分配的字符串結構
在上圖中,字符串指針后面是字符串長度值,然而,Ghidra無法區分地址和整數數據類型,但是代碼中直接引用的第一個指針除外。
圖39 eCh0raix中的字符串指針
未定義的字符串可以通過字符串地址找到:
圖40 eCh0raix中未定義的字符串
執行該腳本后,將定義字符串地址、字符串長度值和字符串本身:
圖41 執行find_static_strings.py后,eCh0raix中靜態分配的字符串結構
圖42 執行find_static_strings.py后,eCh0raix中定義的字符串
挑戰:消除誤報和字符串遺漏
我們希望消除誤報,為此,我們需要:
- 限制字符串的長度
- 搜索可打印字符
- 在二進制文件的數據段進行搜索
很明顯,由于這些限制,字符串很容易成為漏網之魚。如果你使用這個腳本,請隨意試驗:不停改變這些值,以找到最佳設置。其中,以下代碼用于限制長度和字符集:
圖43 find_static_strings.py.
圖44 find_static_strings.py
字符串恢復所面臨的進一步挑戰
Ghidra的自動分析可能會錯誤地識別某些數據類型。如果發生這種情況,我們的腳本將無法在該特定位置創建正確的數據。為了解決這個問題,必須先刪除不正確的數據類型,然后才能創建新的數據類型。
例如,先我們來看看eCh0riax勒索軟件中靜態分配的字符串結構。
圖45 eCh0raix中靜態分配的字符串結構
在這里,地址的識別是正確的,但是,字符串長度值(應該是整數數據類型)被錯誤地識別為未定義的值。
在我們的腳本中,以下幾行代碼用于刪除不正確的數據類型:
圖46 find_static_strings.py
執行該腳本后,不僅所有的數據類型都被正確識別出來了,而且所有字符串也被定義了:
圖47 執行find_static_strings.py后,eCh0raix中字符串結構的靜態分配情況
另一個問題來自于這樣一個事實:在Go二進制文件中,字符串將被串聯并存儲到一個大的字符串blob中。在某些情況下,Ghidra會將整個blob定義為單個字符串。這些可以通過大量的offcut引用來識別。Offcut引用是對已定義字符串的某些部分的引用,不是對字符串起始地址的引用——注意,它是對字符串內部的某個位置的引用。
下面的內容來自ARM Kaiji樣本:
圖48 Ghidra錯誤定義的字符串
圖49 Kaiji對錯誤定義的字符串的offcut引用
要找到錯誤定義的字符串,可以使用Ghidra中的Defined Strings窗口,按照offcut引用數對字符串進行排序。在執行字符串恢復腳本之前,可以手動取消對具有大量offcut引用的大型字符串的定義。這樣,腳本就可以成功地創建正確的字符串數據類型。
圖50 Kaiji中定義的字符串
一旦通過手動方式或通過我們的腳本成功定義了一個字符串,它就能夠在Ghidra的列表視圖中正確的顯示出來,從而幫助逆向工程師順利閱讀匯編代碼。但是,Ghidra中的反編譯器視圖無法正確處理固定長度的字符串,并且,無論字符串的長度如何,它都會顯示所有內容,直到找到空字符為止。幸運的是,這個問題將在Ghidra(9.2)的下一個版本中得到解決。
下面,我們以eCh0raix樣本為例來說明這個軟件問題:
圖51 eCh0raix顯示在Listing視圖中的已定義字符串
圖52 eCh0raix顯示在Decompile視圖中的已定義字符串
小結
本文重點探討了逆向分析Go二進制文件時所面臨的兩個難題的解決方法,以幫助逆向工程師使用Ghidra對使用Go編寫的惡意軟件進行靜態分析。具體來說,我們首先討論了如何恢復剝離型Go二進制文件中的函數名,并提出了幾種在Ghidra中定義字符串的解決方案。我們創建的腳本和本文中的例子所使用的文件都是公開的,大家可以通過下面的鏈接找到它們。
實際上,這只是在Go二進制程序的逆向之旅中邁出的一小步。接下來,我們計劃深入研究Go函數的調用約定和類型系統。
在Go二進制代碼中,參數和返回值是通過棧而不是寄存器傳遞給函數的,而Ghidra目前很難正確檢測到這些內容。因此,幫助Ghidra支持Go的調用約定將有助于逆向工程師理解所分析的函數的用途。
另一個有趣的話題是Go二進制文件中的類型。正如我們從被調查的文件中提取函數名稱所顯示的那樣,Go二進制文件也存儲有關所用類型的信息。恢復這些類型對逆向工程有很大的幫助。在下面的例子中,我們恢復了一個eCh0raix勒索軟件樣本中的main.Info結構體。這個結構體能夠告訴我們,惡意軟件希望從C2服務器得到哪些信息。
圖53 eCh0raix中的main.info結構體
圖54 eCh0raix中的main.info字段
圖55 eCh0raix中的main.info結構體
正如你所看到的,從逆向工程的角度來看,在Go二進制代碼中還有很多有趣的地方有待考察,對此感興趣的讀者,請關注我們的下一篇文章。
保存本文中所用腳本和其他材料的Github倉庫的地址如下所示:
- https://github.com/getCUJO/ThreatIntel/tree/master/Scripts/Ghidra
- https://github.com/getCUJO/ThreatIntel/tree/master/Research_materials/Golang_reversing
本文所使用的相關文件:
File name SHA-256
[1] hello.c ab84ee5bcc6507d870fdbb6597bed13f858bbe322dc566522723fd8669a6d073
[2] hello.go 2f6f6b83179a239c5ed63cccf5082d0336b9a86ed93dcf0e03634c8e1ba8389b
[3] hello_c efe3a095cea591fe9f36b6dd8f67bd8e043c92678f479582f61aabf5428e4fc4
[4] hello_c_strip 95bca2d8795243af30c3c00922240d85385ee2c6e161d242ec37fa986b423726
[5] hello_go 4d18f9824fe6c1ce28f93af6d12bdb290633905a34678009505d216bf744ecb3
[6] hello_go_strip 45a338dfddf59b3fd229ddd5822bc44e0d4a036f570b7eaa8a32958222af2be2
[7] hello_go.exe 5ab9ab9ca2abf03199516285b4fc81e2884342211bf0b88b7684f87e61538c4d
[8] hello_go_strip.exe ca487812de31a5b74b3e43f399cb58d6bd6d8c422a4009788f22ed4bd4fd936c
[9] eCh0raix – x86 154dea7cace3d58c0ceccb5a3b8d7e0347674a0e76daffa9fa53578c036d9357
[10] eCh0raix – ARM 3d7ebe73319a3435293838296fbb86c2e920fd0ccc9169285cc2c4d7fa3f120d
[11] Kaiji – x86_64 f4a64ab3ffc0b4a94fd07a55565f24915b7a1aaec58454df5e47d8f8a2eec22a
[12] Kaiji – ARM 3e68118ad46b9eb64063b259fca5f6682c5c2cb18fd9a4e7d97969226b2e6fb4
參考資料
- https://rednaga.io/2016/09/21/reversing_go_binaries_like_a_pro/
- https://2016.zeronights.ru/wp-content/uploads/2016/12/GO_Zaytsev.pdf
- https://carvesystems.com/news/reverse-engineering-go-binaries-using-radare-2-and-python/
- https://www.pnfsoftware.com/blog/analyzing-golang-executables/
- https://github.com/strazzere/golang_loader_assist/blob/master/Bsides-GO-Forth-And-Reverse.pdf
- https://github.com/radareorg/r2con2020/blob/master/day2/r2_Gophers-· AnalysisOfGoBinariesWithRadare2.pdf
相關工具
IDA Pro
- https://github.com/sibears/IDAGolangHelper
- https://github.com/strazzere/golang_loader_assist
radare2/Cutter
- https://github.com/f0rki/r2-go-helpers
- https://github.com/JacobPimental/r2-gohelper/blob/master/golang_helper.py
- https://github.com/CarveSystems/gostringsr2
Binary Ninja
- https://github.com/f0rki/bn-goloader
Ghidra
- https://github.com/felberj/gotools
- https://github.com/ghidraninja/ghidra_scripts/blob/master/golang_renamer.py
本文翻譯自:https://cujo.com/reverse-engineering-go-binaries-with-ghidra如若轉載,請注明原文地址。