怎么利用Ghidra逆向分析Go二進制程序

這篇文章主要介紹“怎么利用Ghidra逆向分析Go二進制程序”，在日常操作中，相信很多人在怎么利用Ghidra逆向分析Go二進制程序問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么利用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結構體

到此，關于“怎么利用Ghidra逆向分析Go二進制程序”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！