ReAgent 評価: Ghidra と LLM でバイナリから C/C++ を再構成する検証付きパイプライン

ReAgent が埋めようとしている穴

逆コンパイラの出力をそのまま読む作業は、変数名の復元、構造体や列挙型の推定、呼び出し関係の追跡を人手で行うことを意味する。Ghidra はデコンパイル結果と xref、struct、enum、vtable、グローバル、文字列といったコンテキストを提供するが、それを C/C++ の関数として書き戻す工程は自動化されていない。ReAgent はこの工程をエージェントに任せる。対象は Python 3.10 以上で動く CLI で、PyPI には auto-re-agent という名前で公開されている。README が想定する利用者は、解析対象のプログラムと、Claude または Codex の CLI、もしくは API キーを既に持っている開発者である。逆アセンブル結果を読む技能の代わりに、ビルドとテストという客観的な足場を要求する設計だと言える。

reverser と checker を分ける理由

README のワークフロー図では、reverser が候補を書き、checker がそれを判定し、fix ループが境界付きのラウンド数で回る。設定ファイルでは llm.provider と agents.checker.provider を別々に指定できるため、生成側に Claude CLI の sonnet を、検査側に Codex の gpt-5.4 を割り当てるといった構成が可能である。同じモデルに自分の出力を採点させると甘くなる傾向があるため、生成と検査を別系統にするのは妥当な判断だ。ただし README は checker が PASS を返すことを成功条件の一つに数えつつ、それを独立した条件として扱っている。つまり checker の判定は他の三条件と並列であり、単独では何も保証しない。

成功とみなされる四つの条件

README は成功の条件を明示している。第一に LLM checker が PASS を返すこと。第二に客観的 verifier が強い構造的ミスマッチを見つけないこと。第三に候補の検証が設定された acceptance policy を満たすこと。第四に parity が設定された RED/YELLOW ポリシーでブロックされないこと。parity は GREEN、YELLOW、RED の三段階で表現される。注目すべきは、これらがすべて満たされても README 自身が「これは保守的な検証であり、意味的等価性の証明ではない」と書いている点である。構造的ミスマッチが見つからないことは、元の関数と論理的に同じであることを意味しない。この但し書きは、ツールの出力をそのまま本番コードに取り込む使い方を明確に否定している。

エビデンス収集は Ghidra ブリッジに依存する

ReAgent 本体はデコンパイルを行わない。ghidra-bridge という別パッケージが Ghidra から情報を引き出し、ReAgent はそれを読む。手順は対象プロジェクトのディレクトリで ghidra-bridge init を実行して ghidra-bridge.yaml を作り、Ghidra のプロジェクトとプログラムのパスを編集し、ghidra-bridge export all でエクスポートする流れになる。ソースやフックのパターンが手元にある場合は ghidra-bridge build-map が推奨され、ghidra-bridge info で設定が見えているかを確認する。この依存関係は導入コストに直結する。Ghidra のインストールとプロジェクトの準備が済んでいなければ、ReAgent は何も解析できない。headless エクスポートを使う場合は auto-re-agent[headless] として PyGhidra 拡張を入れる必要がある。

導入手順と re-agent.yaml の最小構成

インストールは python3 -m pip install --upgrade "auto-re-agent[ghidra-bridge]>=0.4.0" で行う。開発版を追う場合は ghidra-ai-bridge と auto-re-agent をそれぞれ git+https 形式で指定する方法が README に載っている。対象プロジェクト側では re-agent init --profile generic-cpp を実行して設定を生成する。--profile を省略すると GTA-reversed 向けの既定値が残るため、新規プロジェクトでは明示することが推奨されている。用意されているプロファイルは generic-cpp、windows-x64、gta-reversed、openrct2 の四つである。生成された re-agent.yaml では最低限、llm の provider と model、backend の type と cli_path、project_profile の source_root などを埋める。backend.type は ghidra-bridge、cli_path は ghidra-bridge を指す。

0.4.0 で変わった検証コマンドの移植性

0.4.0 の変更点で実務に効くのは、ビルド・テスト・実行時検証が引数配列を直接受け取れるようになったことである。Windows と POSIX の両方で配列を実行できる。ネイティブ Windows ではシェル文字列を配列に変換する必要があり、従来形式の文字列は /bin/sh を要求する。シェルが見つからない場合、re-agent doctor がそれを報告する。ここは移行時に壊れやすい箇所だ。既存の設定がシェル文字列で書かれていると、Windows 上では動かない可能性がある。docs/configuration.md の portable validation commands の節が移行先を示している。同じリリースで re-agent plan、re-agent reverse --manifest、re-agent evidence --manifest、re-agent status --manifest が追加され、モデル呼び出しなしで関数マニフェストを組み、クラスをまたいで選択した関数を依存順に再構成できるようになった。

向かない場面と、別の取り方

ビルドとテストのゲートを用意できないプロジェクトでは、四条件のうち第三が常に満たせない。ファームウェアの断片や、ビルド環境が失われた古いバイナリを対象にするなら、ReAgent の検証機構は空回りする。この場合、Ghidra のデコンパイラ出力を人手で読む従来の進め方のほうが現実的である。Ghidra 自身はデコンパイル結果を C に近い形で提示するが、候補を生成して複数条件で絞り込む仕組みは持たない。ReAgent はその絞り込みを自動化する代わりに、Ghidra プロジェクト、LLM の認証、ビルドコマンドという三つの前提を要求する。前提を満たせない環境では、Ghidra の出力を直接読むほうが速い。また README が明言するとおり、このツールは候補を生成するだけで、元のソースツリーを自動で書き換えない。パッチ適用を期待して導入すると肩透かしを食う。

保守コストとライセンスの確認点

ReAgent 本体は MIT ライセンスである。ただし Ghidra ブリッジは別リポジトリの別パッケージで、Ghidra 本体のライセンスは Apache License 2.0 として配布されている。ライセンス条件の解釈はここでは扱わないが、依存を増やす前に各コンポーネントの条件を確認する必要がある。保守の面では、LLM のモデル名が設定ファイルに直接書かれる点に注意したい。llm.model と agents.checker.model はプロバイダ側の変更で陳腐化する。リリース間隔は 0.2.1 が 2026-07-23、0.3.0 が 2026-09-04、0.4.0 が 2026-09-09 で、直近は短い。設定スキーマが動く前提でバージョンを固定し、アップグレード時は re-agent doctor と re-agent status --manifest で既存の検証コマンドが生きているかを先に確認するのが安全である。

編集部の結論

採用すべきなのは、Ghidra プロジェクトとビルド・テストが既に整った C/C++ コードベースを持ち、関数単位で再構成結果を検証しながら進めたいチームである。逆に、ビルドゲートを用意できない、あるいは意味的等価性の保証を求める用途には向かない。導入前に確認すべきは re-agent doctor の出力、re-agent.yaml の llm と agents.checker の設定、そして validation の acceptance policy が自分のプロジェクトのビルドコマンドで実際に GREEN を返せるかどうかである。

公式情報源

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