Ghidra (ギドラ) は NSA が内部利用していたリバースエンジニアリング・スイートで、2019 年 RSA Conference で Apache License 2.0 として OSS 公開された。Disassembler と「無料の Decompiler」を一般に開放した点で IDA Pro 独占の RE 市場に風穴を開け、マルウェア解析・CTF・ファームウェア解析の裾野を一気に押し広げた。本稿では SLEIGH と P-Code による多アーキ対応の仕組み、典型ワークフロー、他ツールとの比較、自動化、限界までを通しで扱う。
難しく見えても本質は次の 3 つだけ。(1) Ghidra は 「機械語を人間が読める形に翻訳するツール」。ソースコードが手に入らない exe / ELF / firmware を分解して中身を読める。(2) 2019 年に NSA が無料公開して以降、これまで有料 (数十万円) だった「Decompiler (擬似 C への変換)」が 誰でも無料で使えるようになった、というのが業界を変えた最大の出来事。(3) 主な使い道は マルウェア解析 / CTF / IoT ファームウェア解析 / 脆弱性パッチ差分 の 4 つ。— ここを土台に各章を順に開いていけばいい。
Ghidra が解いている問題 — リバースエンジニアリングとは #
Reverse Engineering (RE) はコンパイル済み実行ファイル・ファームウェア・オブジェクトファイルから、元の設計意図と動作を逆方向に復元する作業の総称。ソースコードが手に入らない状況で「このマルウェアは何をするのか」「このプロプライエタリプロトコルはどう動くのか」「このパッチで何が直されたのか」を答える必要がある時に使う。
料理人がレシピなしの料理を食べて 「砂糖が小さじ 2、塩はひとつまみ…」と材料と工程を逆推測するのと同じ作業。プログラムは 「機械語のバイト列」という料理として出てくるので、(1) アセンブリに分解 (= 食材を 1 つずつ取り出す) → (2) 擬似 C コードに再構築 (= レシピの形に組み直す) → (3) 関数名や型に意味を貼る (= 「これは下ごしらえの工程」とコメントを書く)、という 3 段階で「読める形」に戻す。Ghidra はこの 3 段階を 1 つの GUI で支援するツール。
機械語 (例: x86-64 の 48 83 EC 28 ...) は人間には読めない。RE ツールは複数の層で「読める形」に再翻訳する:
sub rsp, 0x28; mov rax, [rbp-0x10]; ... のように命令単位に分解。int main() { int x = ...; if (x > 0) {...} } のように高水準構造を回復。Ghidra は (1)→(4) のすべてを 1 つの GUI で提供し、逐次的に意味を貼り付ける作業 (関数の改名・型注釈・コメント) を蓄積できるプロジェクト管理機能を持つ。「手作業の知見をプロジェクトに残せる」プロセス設計が、解析の継続性と共有を支える本質。
歴史 — NSA 内部ツールから 2019 OSS 公開へ #
Ghidra の起源は 1999 年頃の NSA 内部開発。SIGINT 業務における外国製・国産問わず暗号化通信ソフトや組み込み機器の解析のため、Java で書かれたクロスプラットフォーム RE スイートとして育てられた。機密扱いの内部ツールだったが、Edward Snowden が 2013 年に NSA 文書をリークした際に「Ghidra」の名称と一部スクリーンショットが世界に知られた経緯がある。
転機は 2019 年 3 月。NSA の Cybersecurity Directorate のディレクター Rob Joyce が RSA Conference で公開発表し、GitHub に Apache License 2.0 でソース・バイナリを公開した。
理由は複数説明されている:
- 学術 / 研究コミュニティへの貢献 (NSA の "Cybersecurity for the Nation" 路線)
- 国家として人材育成への投資 — RE 人材は供給不足、ツール公開で裾野を広げる
- 既に内部リーク文書で名前と機能が知られていた — 完全公開した方が透明性で得
- 競合 (IDA Pro 等) との人材獲得競争 — 採用面接で「Ghidra なら知ってます」というキャリア入口を作れる
初版 9.0 はバックドアの噂を疑う声もあったが、Apache 2.0 で完全公開済み + 巨大な OSS コミュニティが調査済み で、実用上は安全と扱われている。2026 年現在の最新は 11.x 系、年に数回のリリースが続く。
アーキテクチャ — SLEIGH と P-Code が支える多アーキ対応 #
Ghidra の技術的に最も独自な部分は、SLEIGH という独自プロセッサ仕様記述言語と P-Code という中間表現 (IR) の組み合わせ。x86 でも ARM でも MIPS でも PowerPC でも RISC-V でも同じ解析エンジンが動くのはこの 2 つのおかげ。
世界には x86 / ARM / MIPS / RISC-V など 無数の CPU 言語がある。普通の解析ツールは 「x86 専用」「ARM 専用」と別々の翻訳機を用意するが、Ghidra は (1) SLEIGH = 各 CPU の「文法書」 + (2) P-Code = 翻訳した結果を統一する「共通言語 (エスペラント語)」という 2 段構成。だから珍しい IoT CPU でも SLEIGH 仕様を 1 個書けば即対応できるし、解析プラグインは P-Code レベルで書けば 全 CPU で同じものが動く。これが「Ghidra は珍しい CPU に強い」と言われる仕組み。
x86.sla / ARM.sla / ...) がバイトパターンを解釈。48 83 EC 28 → sub rsp, 0x28 (x86-64)、E5 2D E0 04 → str lr, [sp,#-4]! (ARM)。sub rsp, 0x28 → INT_SUB(rsp, 0x28) → COPY → rsp のような P-Code op の連鎖。x86 でも ARM でも同じ集合に正規化。SLEIGH の意義:
- 新しい ISA への対応が「プログラム書き換え」ではなく「仕様ファイル追加」で済む
- 無名・独自プロセッサ (組み込み機器 / 古い ASIC / 一部 IoT) でも、SLEIGH 仕様を書けば Ghidra で解析可能
- コミュニティ contribute で 6502 / 8086 / SH4 / レトロ機器の SLEIGH 定義が公開されている
P-Code の意義:
- x86 で書いた解析プラグインが ARM でも動く — アーキ依存を上位レイヤから消す
- データフロー解析 / シンボリック実行 / 抽象解釈を 1 度書けば全アーキで使える
- angr / Triton などのシンボリック実行フレームワークも P-Code 経由で統合できる
代表機能 — 解析者が日常的に使うもの #
Ghidra は「これがウリ」と一言で説明しづらい統合環境だが、解析者が日常的に使う主な機能は次の通り。
| 機能 | 何をする |
|---|---|
| Code Browser | バイナリ全体の中央 UI。Disassembly / Decompiler / シンボル / 参照を 1 画面に統合 |
| Decompiler | アセンブリから擬似 C コードを再構築 (Ghidra の最大の魅力) |
| Function Graph | 関数の制御フローを Basic Block の有向グラフで可視化 |
| String Search | バイナリ内の文字列定数を抽出 → マルウェアの URL / プロセス名 / API 関数名の発見 |
| Symbol Tree | 関数・グローバル変数・名前空間を tree で整理 |
| Cross References (xrefs) | この関数 / 変数を呼んでいる箇所を双方向に辿る |
| Data Type Manager | 構造体 / 共用体 / 列挙体を定義してメモリ領域に型を貼る |
| Function ID / FidDb | 既知ライブラリ関数 (libc / OpenSSL / .NET 等) のシグネチャマッチで自動命名 |
| Bookmark | 「ここ重要」をマーク、後で戻れるように |
| Version Tracking | 2 つのバイナリ (パッチ前後 / 異なる亜種) の関数を対応付け |
| Headless Analyzer | GUI を介さず CLI でプロジェクト作成・解析・スクリプト実行 (CI 統合) |
| Script Manager | Python (Jython) / Java で機能拡張 |
| Collaborative Server | Ghidra Server を立てて複数解析者がリアルタイム共有解析 |
「何もない状態のバイナリに、解析者が逐次的に意味を貼り付けていく」プロセスを支える設計が一貫している。1 セッションで終わらない解析でも、プロジェクトファイル (.gpr) に全状態が保存され、翌日同じ場所から続けられる。
典型ワークフロー — Import から Decompile まで #
実際の解析セッションの流れ:
File → New Project で Non-Shared / Shared を選ぶ。; でコメント。逐次的に意味を貼り付ける。上の 7 ステップは本格運用向け。初めて Ghidra を開いたとき何をすればいいか分からない、という人向けの最短コース。(1) サンプル exe を Import (CTF 用の Easy バイナリ or 自分でビルドした C 実行ファイル)。(2) Auto-analyze を全 ON のままで実行 (数秒〜数分)。(3) 左の Symbol Tree から main をダブルクリック。(4) 右側の Decompiler ペインで擬似 C コードを読む。(5) 意味が分かった変数を L キーでリネーム / ; でコメントを書く。これだけで「機械語が読める」体験ができる。慣れたら CTF の Reverse カテゴリ Easy 問題から本格的に学習を始めるのが最短ルート。
スタックポインタの追跡ミス / レジスタ生存範囲の誤認 / 関数境界の誤判定が代表的な失敗パターン。疑わしい箇所はアセンブリに戻って検証するのが定石。右クリック → "Override Function Signature" や "Edit Function" で型を正すと、急に Decompiler 出力が良くなる。
# Code Browser での主要キー
L シンボル (関数/変数) のリネーム
; コメント追加
Ctrl-Shift-E 関数のシグネチャ編集
Ctrl-Shift-F Cross References を一覧
G アドレス指定でジャンプ
N グラフを次の関数へ
Ctrl-L データ型を割り当て他の RE ツールとの比較 #
Ghidra は「唯一の RE ツール」ではない。用途と好みで使い分ける現代の主要ツール:
| ツール | 価格 | Decompiler | 強み | 弱み | 適性 |
|---|---|---|---|---|---|
| Ghidra (NSA / OSS) | 無料 | ○ 標準装備、多アーキ (SLEIGH) | 無料で IDA 相当 / 珍しい ISA / Headless 自動化 / Shared Project | Java の起動コスト / UI に癖 / プラグイン少 | 初学者 / 個人 / 大量サンプル / CI |
| IDA Pro (Hex-Rays, 1991-) | $$$ (数千〜) | ◎ Hex-Rays、品質トップ (別売) | Decompiler 品質最高 / 業界デファクト / プラグイン豊富 | 高価 / 珍しい ISA が別売り | 商用 / 大企業 SOC / 高品質要求案件 |
| Binary Ninja (Vector 35, 2016-) | $ ($299〜) | ○ HLIL、多段中間表現 | UI / UX 洗練 / API 設計が綺麗 / 起動・操作が速い | 無料版は制限多 / ISA 対応中程度 | プロ個人 / API ヘビーユーザ |
| radare2 / Cutter (OSS, 2006-) | 無料 | △ pdc / r2ghidra で補強 | CLI 完結 / Unix 哲学 / 多 ISA / パイプ連携 | 学習曲線急 / Decompiler 弱い | CLI 派 / 自動化 / CTF |
「IDA Pro」(数十万円) と「Ghidra」(無料) のどちらを選ぶか迷うが、2026 年現在、初学者の答えは Ghidra 一択。理由: (1) 無料で IDA に近い品質の Decompiler が使える、(2) 全 CPU 対応で珍しい IoT も解析可能、(3) Headless モードで自動化できる。Ghidra で物足りなくなる頃にはプロ仕事をしているはずで、その時に IDA Pro / Binary Ninja を会社経費で買えばよい。「Ghidra で始めて、必要なら IDA を買う」が現代の典型的な学習ルート。
Ghidra で始めて、必要なら IDA を買う が現代の典型的な学習ルート。最初から IDA を買う必要はない、というのが Ghidra が業界に与えた最大の影響。objdump / nm / readelf / strings は補助ツールとして併用 — 完結した分析環境ではない。
使われ方 — 実用文脈 #
Ghidra の主な実用文脈を 6 つ。
(1) マルウェア解析 サンプル受領 → Import → Auto-analyze → Strings で URL / IP / API 名抽出 → 怪しい関数を Decompile して挙動を読む。Sunburst (SolarWinds, 2020) や WannaCry の公開直後から Ghidra 解析記事が多数。Initial Triage を Ghidra で済ませてから動的解析 (Cuckoo Sandbox / x64dbg) に渡すのが定番。
(2) 脆弱性研究 / パッチ差分 CVE 公開後、Microsoft / Adobe 等のパッチを Before / After で diff し、どこが直されたかを特定する。Ghidra の Version Tracking が関数単位の対応付けと差分表示を支援。BinDiff / Diaphora が併用される。
(3) CTF CTF の Reverse カテゴリは Ghidra が事実上の標準。stripped ELF からフラグを取り出す、Rust / Go バイナリの構造を解く、カスタム VM を逆コンパイルする、といった問題で Ghidra のフレキシブルさが効く。
(4) ファームウェア / IoT ルータ / IP カメラ / 組込デバイスの firmware を binwalk で展開 → ELF / raw bin 抽出 → Ghidra で解析。MIPS / ARM / RISC-V の処理能力、SLEIGH で珍しい組込 CPU にも対応可能な点が活きる。
(5) プロトコル解析 プロプライエタリなネットワークプロトコル (ゲーム / SCADA / 古い独自プロトコル) の挙動を、実装バイナリから逆算してパケット形式を復元する。Cross-references で受信処理から辿るのが定石。
(6) ライセンス検証回避 (法的グレーゾーン) シェアウェアの「シリアル番号検証」を逆算する古典的ユースケース。
正規目的の研究は OK だが、商用ソフトの crack 配布は著作権侵害。自分が買ったソフトの自分用の調査にとどめるべき。マルウェア解析でも、検体は VirusTotal / Malshare / MalwareBazaar 等の正規ソースから入手する。
Headless Analyzer とスクリプト — 自動化の話 #
Ghidra は GUI を介さず CLI から動かせる (analyzeHeadless)。大量サンプルの自動解析 / CI 統合 / バッチ処理で使う。
# プロジェクト作成 + Import + Auto-analyze
$ analyzeHeadless /path/to/project ProjectName \
-import sample.exe \
-postScript MyAnalysisScript.py
# 既存プロジェクトに対してスクリプトだけ実行
$ analyzeHeadless /path/to/project ProjectName \
-process sample.exe \
-scriptPath ./scripts \
-postScript ExtractStrings.py# Script Manager → New Python で書く
fm = currentProgram.getFunctionManager()
for func in fm.getFunctions(True):
print("Function:", func.getName())
for ref in func.getEntryPoint().getReferenceIteratorTo():
print(" called from:", ref.getFromAddress())import re
listing = currentProgram.getListing()
for data in listing.getDefinedData(True):
if data.hasStringValue():
s = data.getValue()
if re.search(r"https?://|\b\d+\.\d+\.\d+\.\d+\b", str(s)):
print(data.getAddress(), s)Ghidra-Scripts (GitHub の複数 repos): Find Crypt / String Decryption / Anti-VM 検知。Ghidra-CTF: CTF 向けの一般化スクリプト。Ghidra Bridge: 外部 CPython (PyPI ライブラリ使い放題) と Ghidra Jython を橋渡し → angr / capa / yara を統合できる。
限界とコツ — 「Decompiler は完璧ではない」 #
Ghidra (および全 RE ツール) の限界:
- Decompiler の出力は近似 — スタック誤認 / レジスタの型推論失敗 / カーネルコード / 高最適化 (LTO/PGO) で誤訳が起きる。アセンブリに戻って検証するのが原則
- Packing / Obfuscation — UPX 程度なら自動展開できるが、商用パッカー (VMProtect, Themida) や手作りパッカーは事前に動的 unpacking (= プロセスダンプ) してから渡す必要がある
- JIT / JVM / .NET / Python — 機械語ではなく中間バイトコード — dnSpy (C#) / jadx (Java) / Decompyle3 (Python) など専用ツールが向く
- Stripped binary — シンボル / デバッグ情報がない場合、関数名 / 変数名はすべて自分で貼り直す
- 巨大なバイナリ — 100MB 級だと Auto-analyze に数十分〜数時間、GUI も重くなる。Headless で部分処理する
- JVM の起動コスト —
ghidraRunの起動だけで 10〜20 秒 - UI に独特の癖 — IDA / Binary Ninja から来た人は最初戸惑う
上の限界のうち最も重要な点が「Decompiler の精度」。Decompiler が出した擬似 C コードは 「機械翻訳」と同じで、文法的には読めても 意味的に間違っていることがよくある。「Decompiler の出力を鵜呑みにしない / 怪しい箇所はアセンブリに戻って確認する」のが鉄則。逆に 「ここは構造体っぽい」「ここはこの型」と人間が教えてあげると Decompiler 出力が劇的に良くなる — つまり 解析者と Ghidra の「対話」で精度が上がるツール、と理解する。
- 小さく試す — 不明な関数は 「呼び出し元から逆に辿る (xrefs)」 が最も効率的。main からトップダウンは行き詰まりがち
- シグネチャ DB を活用 — Function ID でライブラリ関数を自動命名すると、意味的負荷が一気に減る
- 構造体を貼る — 「ここはおそらく XYZ 構造体のメモリ」と気づいたら型を貼る → Decompiler 出力が劇的に良くなる
- コメントと改名はケチらない — 半年後の自分が読む前提
- スクリプトで定型化 — 2 回やった作業はスクリプトに
関連ツールとエコシステム #
Ghidra 単体ではなく周辺ツールと組み合わせるのが現代の解析。
| 役割 | ツール |
|---|---|
| 動的解析 | x64dbg / OllyDbg / GDB / WinDbg / Frida |
| サンドボックス | Cuckoo Sandbox / Joe Sandbox / Hybrid Analysis / Any.Run |
| ファームウェア展開 | binwalk / firmware-mod-kit / unblob |
| Diff / Version Tracking | BinDiff (Google) / Diaphora |
| シンボリック実行 | angr / Triton / KLEE |
| シグネチャ / YARA | yara / yarGen / capa |
| アンパッカー | unipacker / scyllahide / Volatility (メモリダンプ) |
| マルウェア配信プラットフォーム | VirusTotal / Malshare / MalwareBazaar |
| 解析ノート | Obsidian / Notion / Markdown + Git |
Ghidra Bridge で CPython 側から Ghidra API を叩けるようにし、angr (シンボリック実行) や capa (能力検出) の Python ライブラリと統合するのが上級者の使い方。
Ghidra は SLEIGH によるプロセッサ仕様の宣言的記述 + P-Code 中間表現 + 共通の解析エンジンで、x86 / ARM / MIPS / PowerPC / RISC-V / 珍しい組込 CPU まで 1 つのツールで解析できる。最大の歴史的意義は 「無料 + OSS の Decompiler を一般に開放した」こと。RE 学習のスタートラインを価格ではなく「興味と時間」だけにした影響は計り知れない。RE を学び始めるなら Ghidra から、必要に応じて IDA Pro / Binary Ninja / radare2 を併用するのが現代の標準ルート。
