ReAgent：用 Ghidra 加 LLM 把編譯後的函式還原成 C/C++

它想解決的是「反編譯出來讀不動」，不是「反編譯不出來」

Ghidra 這類工具本來就能把二進位檔吐出 C 虛擬碼，問題在於那份虛擬碼離可編譯、可維護的原始碼還很遠：變數名是 iVar1、uVar2，結構體攤平成指標位移，函式之間的呼叫關係要自己追。ReAgent 的目標讀者是手上已經有一棵原始碼樹、正在做還原工程的人。README 開頭把它定位成「AI reverse-engineering agent」，工作是把編譯後的函式重建並驗證成 C/C++，而不是幫你理解一個完全陌生的樣本。這個區分很重要，因為它整套設計都建立在「有東西可以拿去編譯和測試」這個前提上。

反過來說，如果你的情境是惡意程式分析、CTF、或只有一個孤立執行檔，這套流程的價值會大幅下降。四個驗證條件裡有兩個（候選建置測試、parity 比對）需要專案環境，缺了它們，剩下的就只有 LLM 產生的候選碼和一個結構檢查。

四個獨立條件才算成功，這是保守驗證而非等價證明

README 把「成功的還原」定義成四個條件同時成立：LLM 檢查器回傳 PASS；客觀驗證器沒有找到強結構不匹配；候選驗證滿足設定的 acceptance policy；parity 沒有被 RED/YELLOW 政策擋下。文件自己也寫明這是「conservative verification, not a proof of semantic equivalence」。這個措辭值得肯定，因為市面上不少同類工具會用「正確還原」這種說法含混帶過。

保守的代價是假陰性。一個語意上等價、但結構特徵與原函式不同的候選（例如編譯器對迴圈做了不同展開）可能被判成 YELLOW 或 RED，於是你得回頭看它到底哪裡不同。反過來，四個條件都過也不代表語意等價，只代表在設定的政策下沒有被抓到問題。把這個當成「通過了就可以合併」的訊號是誤讀。

資料流：從 Ghidra 匯出到候選 overlay，原始碼樹不會被自動改寫

從 README 的流程圖看，一次 reverse 的資料流大致是：讀取 YAML 設定與環境變數覆寫；依 dependency-order、easiest-first 或 high-impact 選函式；收集來源與二進位脈絡，包括 decompile、xrefs、structs、enums、vtables、globals、strings，以及正規化後的高階 P-code、CFG、組語與鄰近專案原始碼；進入 reverser 與 checker 的修正迴圈，輪數與調查次數都有上限；再由結構驗證器把關；接著產生候選 overlay，跑設定的建置、測試與執行期關卡；最後是 parity gate。輸出包含報告、每次呼叫的日誌、每輪檢查點、session 歷史與 knowledge graph。

有兩點容易被忽略。第一，reverser 與 checker 可以是不同模型，設定上分開放在 llm 與 agents.checker 底下，這種獨立檢查的設計比同一個模型自我複查有意義。第二，README 明講工具「does not patch the original source tree automatically」，候選碼是疊在 overlay 上驗證的，要進版控得自己動手。這是刻意的安全邊界，不是功能缺失。

安裝與設定：從 ghidra-bridge init 到 re-agent.yaml

安裝走 PyPI，套件名是 auto-re-agent，而且要帶 extra：

python3 -m pip install --upgrade "auto-re-agent[ghidra-bridge]>=0.4.0"

若要做 headless Ghidra 匯出，改用 headless extra。想跟開發版就從 GitHub 以 git+ 形式裝 ghidra-ai-bridge 與 auto-re-agent 兩個套件。

Ghidra 證據的產生要在目標專案目錄下跑：先 ghidra-bridge init 產生 ghidra-bridge.yaml 並編輯其中的 Ghidra 專案與程式路徑，再 ghidra-bridge export all，有還原原始碼或 hook 樣式時可選 ghidra-bridge build-map，最後用 ghidra-bridge info 確認匯出與設定可見。

代理端設定用 re-agent init --profile generic-cpp，另有 windows-x64、gta-reversed、openrct2 三個 profile。文件特別提醒：不加 --profile 會沿用原本的 GTA-reversed 預設值，新專案應該明示 profile。re-agent.yaml 至少要知道用哪個 LLM、bridge 執行檔路徑、原始碼路徑與驗證方式，範例裡 llm.provider 是 claude-cli、model 是 sonnet，agents.checker 可換成 codex 與 gpt-5.4，backend.cli_path 指向 ghidra-bridge。

0.4.0 新增的 plan、reverse --manifest、evidence --manifest、status --manifest 讓你不必逐一指名函式，可以先產生有界的函式清單再批次處理。plan 不呼叫模型，這對想先估工作量的人有用。

Windows 上的參數陣列是硬限制，不是提醒

0.4.0 的變更說明指出，建置、測試與執行期驗證現在支援參數陣列，可直接在 Windows 與 POSIX 上執行；但在原生 Windows 上必須把 shell 字串轉成陣列，舊式字串仍然需要 /bin/sh，而 re-agent doctor 會回報缺少 shell。這意味著在原生 Windows 上沿用舊設定的使用者會直接卡住，而且症狀是驗證關卡跑不起來，不是模型出錯，排查方向容易搞錯。

同一版還修了幾個與平台相關的細節：Clang 索引處理 CRLF 位移、Codex CLI 請求對大型 prompt 改用 UTF-8 stdin、後端回傳空訊息時 manifest 仍保持可讀。這些都指向同一個現實：這套工具對作業系統與外部 CLI 的細節相當敏感，設定檔的正確性比模型選擇更早決定成敗。

與純反編譯器加人工閱讀的差別在哪

最直接的替代方案是 Ghidra 或 IDA 匯出虛擬碼，由工程師自己對照原始碼樹重寫。兩者的差別不在產出速度，而在可驗證性。人工路線的驗證通常是「看起來對」加上執行時不出錯；ReAgent 把驗證拆成 LLM 檢查、結構驗證、候選建置測試與 parity 四段，每一段都可以單獨看日誌與檢查點。當一個函式沒過關，你知道是哪一關擋下的。

代價是前置成本。你得先有可建置的專案、可跑的測試、可匯出的 Ghidra 設定，還要付模型呼叫的費用。對於一次性的、十幾行的函式，這套流程的固定成本遠高於手寫。反過來，在動輒數百個函式的還原專案裡，manifest、dependency ordering、累積驗證與 session 歷史帶來的可重複性，才是這套工具真正在賣的東西。文件沒有提供任何準確率或速度數字，也不該拿來當選型依據。

維護成本與授權：MIT，但依賴鏈會動

ReAgent 本身是 MIT 授權，寬鬆，商用與閉源專案都能用。要注意的是它並非單一依賴：Ghidra 是獨立專案，走的是自己的授權，ghidra-bridge 也是獨立套件。把這條鏈放進產品流程前，該確認的是 Ghidra 與 bridge 的授權條款如何與你的散布方式互動，這部分本文不提供法律意見。

維護面上，從版本節奏可以看出專案還在快速變動：0.2.1、0.3.0、0.4.0 三個版本分別落在 2026 年 7 月、9 月 4 日與 9 月 9 日，0.4.0 距離前一版只有五天，而且改動包含驗證指令格式這種會讓舊設定失效的東西。設定檔與驗證指令要跟著版本走，升級前先讀 CHANGELOG.md 與 docs/configuration.md 的 portable validation commands 一節，會比事後除錯省事。

編輯結論

ReAgent 適合已經有可建置、可跑測試的專案，並且願意把 Ghidra 匯出流程固定下來的人：例如在做 GTA reversed 或 OpenRCT2 這類有現成 profile 的還原工程。若你只是想看懂一個閉源執行檔裡的某段邏輯，沒有原始碼樹、沒有測試可跑，這套四道驗證關卡會大多空轉，純反編譯器加人工閱讀更直接。動手前先確認三件事：ghidra-bridge init 產生的 ghidra-bridge.yaml 裡專案與程式路徑正確、re-agent doctor 在你的作業系統上回報的 shell 狀態、以及候選驗證指令是參數陣列而非 shell 字串。這三項沒過，後面的模型呼叫只是白花錢。

官方來源

1. Dryxio/reagent on GitHub
2. Issues
3. License: MIT
4. README
5. Releases