Ghidra 逆向實戰
STM32(ARM) MCU 韌體逆向工程
無符號表(Symbol-less)分析技巧

說明與注意事項

本文默認讀者已安裝所有必要工具，如果還不熟悉，建議先參考以下文章：

Ghidra 逆向實戰｜STM32(ARM) MCU 韌體逆向工程 : 工具說明

本實做將以 STM32H7A3 系列微控制器為範例，示範如何在 Ghidra 中進行無符號表(Symbol-less)韌體靜態分析，方法不分先後，依照實際需求與情況選擇適合的步驟進行。這些方法可協助使用者在缺乏符號表的情況下，仍能有效地進行韌體分析。

尋找字串常數

在韌體中，字串常數（如 ASCII 或 Unicode 格式）常見於除錯訊息、錯誤提示、人機介面標示等。若編譯時未移除這些資訊，便能在韌體中直接找到相關字串。

這些字串對逆向工程極為有用，不僅能協助判斷韌體所用的架構或函式庫，還能快速定位程式碼中調用這些字串的位置，是分析流程的重要切入點。

啟動入口與中斷向量表

在韌體中，啟動入口（如 Reset_Handler）與 中斷向量表 是韌體執行的起點。這些區域通常包含初始化程式碼、系統設定與中斷處理程式等。而這些位置的程式碼通常會在韌體啟動時被執行，因此可以作為分析的起點。

不同架構中斷向量表的位置與格式可能有所不同，但通常會包含一系列的函式指標，指向各種中斷服務程式（ISR）或系統呼叫。在 ARM Cortex-M 架構中，中斷向量表規定位於韌體開頭（例如 STM32 通常從 0x08000000 開始，這是由於重定向和偏移），格式如下：

                
Offset  內容
0x00    初始堆疊指標（Initial Stack Pointer）
0x04    Reset_Handler（重設處理函式）
0x08    NMI_Handler（不可屏蔽中斷）
0x0C    HardFault_Handler
0x10    MemManage_Handler
0x14    BusFault_Handler
0x18    UsageFault_Handler
...     其他中斷服務程式（ISR）指標
                
            

這些指標實際上是函式位址，Ghidra 可自動辨識並標註為函式。啟動時便是從 Reset_Handler 開始，追蹤其初始化流程與主程式流向。

附註:

• STM32 的中斷向量表是從 0x08000000 開始的，這是因為 STM32 對韌體程式開頭做了重定向與偏移，部分型號還可通過使用者配置偏移到其他位址。
• 詳細內容請參考對應官方手冊：
• Armv8-M Architecture Reference Manual
• STM32H7XX documentation

標記中斷服務函數(ISR)

在 Ghidra 逆向韌體時，標記 ISR（中斷服務函數）是分析的重要一步，以下以 STM32/ARM MCU 為例，說明實際操作流程：

1. 定位中斷向量表：
   開啟 Ghidra 程式碼視窗，跳至韌體開頭（通常是 Flash 起始位址，如 0x08000000）。檢查每 4 bytes 的指標。如果 Ghidra 沒有自動標記類數據類型，右鍵選擇 Data → Pointer 或使用快捷鍵 'p' 進行手動標記（請注意 Initial Stack Pointer 是 uint 或 dword）。
2. 建立函式：
   在中斷向量表中的每個函式指標上快點左鍵兩下跳轉到對應的程式碼位址。到達後，右鍵選擇 Function → Create Function，讓 Ghidra 將該位址標記為一個函式。
3. 命名與註解：
   依據 ARM 或晶片手冊，對應每個向量表項目，右鍵點擊已建立的函式名稱，選擇 Edit Function，輸入正確的函式名稱（如 Reset_Handler、SysTick_Handler 等），並可加上註解說明其用途。

   

4. 檢查與追蹤：
   點擊已標記的 ISR 函式名稱，使用 Window → Function Graph 或 Window → Function Call Tree，分析其內部邏輯與呼叫關係。
5. 輔助工具：
   可搭配 Window → Symbol Tree 快速檢查所有已建立的函式，或用 Window → Defined Strings 搜尋相關字串輔助判斷。

判斷韌體架構：裸機或 RTOS

即便沒有符號表，依然可從程式流與常數變數中進行逆向工程判斷。韌體架構主要分為 裸機（Bare-metal） 與 RTOS（即時作業系統） 兩大類型。此判斷將直接影響後續的分析策略。

快速判斷方法（依可靠度排序）：

• 軟體中斷與外設觸發：
  觀察是否有直接操作 0xE000ED04 (ICSR)（此位址為 ARM 架構專用的中斷控制暫存器）觸發 PendSV，或強制觸發計時器等外設中斷。這些多為 RTOS 系統調用與任務切換。(這種方法還能找出 RTOS 的部分函數位址)

  

• OS 相關中斷服務程式(ISR)分析：
  觀察 SVC、PendSV、SysTick 等 ISR 的程式流。若這些中斷服務程式包含複雜控制流程（極可能是：上下文切換、排程、系統呼叫），多半為 RTOS 架構；若未使用或邏輯簡單，則偏向裸機。

  

• 搜尋常數區關鍵字：
  即使無法從程式流判斷，仍可在常數區（如字串區，使用 Ghidra 的 Defined Strings 功能）搜尋 FreeRTOS、RTX、ThreadX 等關鍵字。這些字串通常會以常數形式存在，若發現則高度懷疑採用對應 RTOS。此外，Kernel、Thread、task、Queue 這些關鍵字也可用來判斷是否存在 RTOS。

  

• Reset Handler 調用樹追蹤：
  追蹤重啟流程（Reset Handler）在調用樹中的分支。裸機架構初始化後，通常會有一個明顯的大型無限迴圈（如主循環）；而 RTOS 架構則多在初始化後進入排程等待，主流程迅速結束或進入空迴圈（但需注意，由於錯誤處理流程也可能出現空迴圈，需結合調用樹與程式流判斷，大型程式需要一些技巧找到正常程式流，在此不做展開）。

  

生成 BinDiff 用參考檔案

當完成基本架構分析後，利用 BinDiff 這類二進位比對工具，搭配官方 HAL 層範例程式碼 或已知韌體版本，建立「參考檔案」進行比對。

具體步驟如下：

1. 先從 MCU 官方範例 或 HAL/LL 驅動程式 取得對應版本的原始碼，並以相同編譯器與設定編譯出 bin/elf 檔。
2. 將參考檔案與目標韌體載入 Ghidra，利用 BinExport 外掛將兩者匯出為 BinDiff 可讀取的格式。
3. 使用 BinDiff 工具載入匯出的檔案，進行函式比對。
4. 比對結果可協助快速標記出標準函式、外設驅動、RTOS 相關 API，顯著提升逆向效率。
5. 若比對結果函式相似度高，通常可直接複製參考檔案的符號名稱與註解，大幅減少手動分析時間。