Ghidra とは — NSA 製 OSS リバースエンジニアリングツールの仕組みと使い方 のサムネイル

Ghidra とは — NSA 製 OSS リバースエンジニアリングツールの仕組みと使い方

⏱ 約 17 分 view 104 like 0 LOG_DATE:2026-05-11
目次 / TOC

Ghidra (ギドラ) #

Ghidra (ギドラ) は 米国家安全保障局 (NSA) が内部利用していたリバースエンジニアリング (RE) スイート で、2019 年 3 月の RSA Conference で OSS (Apache License 2.0) として一般公開された。Disassembler (機械語 → アセンブリの再翻訳) と Decompiler (アセンブリ → 高水準言語擬似コード) を中核にした GUI ベースの統合解析環境で、Java + Swing で動作するためクロスプラットフォーム (Windows / Linux / macOS) に対応する。

公開のインパクトは大きかった。それまで高品質な Decompiler を備えた RE ツールは IDA Pro (Hex-Rays) の事実上の独占で、1 ライセンス数千〜数万ドルという値段が個人と小組織を遠ざけていた。Ghidra は同水準の機能を無料 + OSS で提供し、マルウェア解析 / 脆弱性研究 / CTF / ファームウェア解析を学ぶ層を一気に押し上げた。

本稿は 「Ghidra で何ができるか / なぜ NSA が突然 OSS 公開したか / どう動いているか / どう使うか / IDA / Binary Ninja / radare2 と何が違うか / 限界はどこか」 を順に整理する。「無料で IDA の代わりになる」という一行に詰め込まれた中身を解きほぐすのが目的。

1. Ghidra が解いている問題 — リバースエンジニアリングとは #

Reverse Engineering (RE、リバースエンジニアリング)「コンパイル済み実行ファイル / ファームウェア / オブジェクトファイルなどから、**元の設計意図と動作を逆方向に復元する」**作業の総称。ソースコードが手に入らない状況で **「このマルウェアは何をするのか」「このプロプライエタリプロトコルはどう動いているのか」「このパッチで何が直されたのか」**を答える必要があるときに使う。

機械語 (e.g. x86-64 の 48 83 EC 28 ...) を見ても人間には読めない。RE ツールはこの機械語に対して、複数の層で「読める形」に再翻訳する:

  1. 生バイナリ — そのままでは意味不明
  2. Disassembly (アセンブリ)sub rsp, 0x28; mov rax, [rbp-0x10]; ... のように命令単位に分解
  3. Decompilation (擬似 C)int main() { int x = ...; if (x > 0) {...} } のように高水準構造を回復
  4. Annotated graph — 関数間呼び出し / 制御フロー / クロスリファレンス

Ghidra は (1)→(4) のすべてを 1 つの GUI で提供し、逐次的に意味を貼り付ける作業 (関数の改名・型注釈・コメント) を蓄積できるプロジェクト管理機能を持つ。「手作業の知見をプロジェクトに残せる」というプロセス設計が、解析の継続性と共有を支える本質。

2. 歴史 — NSA 内部ツールから 2019 OSS 公開へ #

Ghidra の起源は 1999 年頃の NSA 内部開発SIGINT (Signals Intelligence) 業務における外国製・国産問わず暗号化通信ソフトや組み込み機器の解析のため、Java で書かれたクロスプラットフォーム RE スイートとして育てられた。機密扱いの内部ツールだったが、Edward Snowden が 2013 年に NSA 文書をリークした際に 「Ghidra」という名称と一部スクリーンショットが世界に知られた経緯がある。

転機は 2019 年 3 月。NSA の Cybersecurity Directorate のディレクター Rob JoyceRSA Conference で公開発表し、GitHub に Apache License 2.0 でソース・バイナリを公開した。理由は複数説明されている:

  • 学術 / 研究コミュニティへの貢献 (NSA の "Cybersecurity for the Nation" 路線)
  • 国家として人材育成への投資 — RE 人材は供給不足、ツール公開で裾野を広げる
  • 既に内部リーク文書で名前と機能が知られていた — 完全公開した方が透明性で得
  • 競合 (IDA Pro 等) との人材獲得競争 — 採用面接で「Ghidra なら知ってます」というキャリア入口を作れる

初版 (9.0)デコンパイラの完成度が高く GitHub で 数万 star を一夜で獲得バックドアの噂を疑う声もあったが、ソース完全公開で実装が監査可能であることが時間とともに支持を集めた。2026 年現在の最新は 11.x 系、年に数回のリリースが続いている。

NSA が作ったから危険」というイメージは初期にあったが、Apache 2.0 で完全公開済み + 巨大な OSS コミュニティが調査済みで、実用上は安全と扱われている

3. アーキテクチャ — SLEIGH と P-Code が支える多アーキ対応 #

Ghidra の技術的に最も独自な部分は、SLEIGH というプロセッサ仕様記述言語P-Code という中間表現 (IR) の組み合わせ。「x86 でも ARM でも MIPS でも PowerPC でも RISC-V でも同じ解析エンジンが動く」のはこの 2 つのおかげ:

Ghidra のアーキテクチャ — 1 つのエンジンで多アーキを解析する仕組み SLEIGH (プロセッサ仕様) で機械語をパース → P-Code (IR) に統一 → 共通エンジンが解析 [ 入力: バイナリファイル ] PE / ELF / Mach-O / raw firmware x86 / x86-64 / ARM / ARM64 / MIPS PowerPC / RISC-V / SPARC / 8051 / Z80 / 他 [ SLEIGH 仕様ファイル ] x86.sla / ARM.sla / MIPS.sla / ... 各 ISA の命令フォーマット・ セマンティクスを宣言的に記述 [ Auto-Analyzer ] 関数識別 / シンボル / 文字列 参照解析 / シグネチャマッチ スタックフレーム推定 / 型推論 ① Disassembly — 機械語バイト列 → アセンブリ (SLEIGH が ISA 固有を吸収) 48 83 EC 28 → sub rsp, 0x28 (x86-64) / E5 2D E0 04 → str lr, [sp, #-4]! (ARM) SLEIGH 仕様は宣言的: 「このバイトパターンは sub 命令で、意味は rsp = rsp - imm」と書く ② P-Code への lift — アーキ固有を消した中間表現に変換 sub rsp, 0x28 → INT_SUB(rsp, 0x28) → COPY → rsp (= 4 つの P-Code op の連鎖) x86 でも ARM でも同じ P-Code op の集合に正規化 → 解析エンジンは 1 つで済む ③ データフロー解析 / 制御フロー解析 — P-Code 上で実行 関数境界 / Basic Block / Use-Def 連鎖 / SSA 形式 / レジスタ生存解析 / コンスタント伝播 ここで「stack に何が入っているか」「ループ条件は何か」を P-Code レベルで推定 ④ Decompiler — P-Code から擬似 C コードへ再構築 局所変数 / if / for / while / switch / 関数呼び出しを構造化、Hex-Rays に近い品質の C 風表示 アセンブリ → C のレベル変換が「商用と無料の最大の差」だった部分。Ghidra が無料化した最大功績 [ アナリストが見る画面 — Code Browser ] 左: シンボル / 関数一覧 ・ 中央: Disassembly View ・ 右: Decompiler View ・ 下: References 手作業: 関数名・変数名・型を貼り直す / コメントを書く / Bookmark を打つ → プロジェクトに永続化 スクリプト (Python/Java) でこれらをまとめて自動化できる

SLEIGH の意義:

  • 新しい ISA への対応が「プログラム書き換え」ではなく「仕様ファイル追加」で済む
  • 無名・独自プロセッサ (組み込み機器 / 古い ASIC / 一部 IoT) でも、SLEIGH 仕様を書けば Ghidra で解析可能になる
  • コミュニティ contribute — 6502 / 8086 / SH4 / レトロ機器の SLEIGH 定義が公開されている

P-Code の意義:

  • 「x86 で書いた解析プラグインが ARM でも動く」— アーキ依存を上位レイヤから消す
  • データフロー解析 / シンボリック実行 / 抽象解釈といった重い解析を 1 度書けば全アーキで使える
  • angr / Triton などのシンボリック実行フレームワークも P-Code 経由で Ghidra と統合できる

4. 代表機能 — 解析者が日常的に使うもの #

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) に全状態が保存され、翌日同じ場所から続けられる

5. 典型ワークフロー — Import から Decompile まで #

実際の解析セッションの流れ:

1. プロジェクト作成 (File → New Project → Non-Shared/Shared)
   ↓
2. バイナリを Import (PE / ELF / Mach-O / Raw を自動判別)
   ↓ "Format" "Language" "Compiler" を確認 (大抵 auto-detect で OK)
3. Auto-Analyze (デフォルト全有効、~数秒〜数分)
   ↓ Function ID / Stack / Decompiler Parameter ID / DWARF
4. 「main」または entry point から開始 (Symbol Tree → main)
   ↓
5. Code Browser で Disassembly を読む / Decompiler を見る
   ↓
6. 変数・関数を改名 (L / Ctrl-L) / 型を貼る (Ctrl-L) / コメントを書く (;)
   ↓
7. Cross-references (Ctrl-Shift-F) で呼び出し元 / 参照を辿る
   ↓
8. 文字列やシステムコール (call printf / WriteFile / connect) を起点に解析展開
   ↓
9. スクリプトで定型作業を自動化 (Script Manager → New Python)
   ↓
10. 保存 / プロジェクトを共有 (Shared Project + Ghidra Server)

Decompiler の品質8 割は人間より速く正確、2 割は誤訳する イメージ。疑わしい箇所はアセンブリに戻って検証するのが定石。スタックポインタの追跡ミス / レジスタ生存範囲の誤認 / 関数境界の誤判定などが代表的な失敗パターンで、右クリック → "Override Function Signature""Edit Function" で型を正すと急に Decompiler 出力が良くなる。

ショートカットで生産性が大きく変わる:

キー 動作
L シンボル (関数/変数) のリネーム
; コメント追加
Ctrl-Shift-E 関数のシグネチャ編集
Ctrl-Shift-F Cross References を一覧
G アドレス指定でジャンプ
N グラフを次の関数へ
Ctrl-L データ型を割り当て

6. 他の RE ツールとの比較 #

Ghidra は「唯一の RE ツール」ではない。用途と好みで使い分ける現代の主要ツールを並べる:

主要 RE ツールの比較 — 何を選ぶか

価格 / 起動コスト / Decompiler / スクリプト / コミュニティ規模で住み分け

Ghidra

NSA / Apache 2.0 / 2019

▼ 価格無料 (OSS)
▼ Decompiler○ 標準装備、高品質
○ 多アーキ対応 (SLEIGH)
▼ スクリプトPython (Jython) / Java
▼ コラボ○ Shared Project / Server
▼ 強み無料で IDA 相当
珍しい ISA 対応
Headless 自動化
▼ 弱みJava の起動コスト
UI に独特の癖
プラグイン少ない
▼ 適性初学者 / 個人 / 大量
CI 自動化用途
IDA Pro

Hex-Rays / 商用 / 1991-

▼ 価格$$$ Pro+Decompiler 数千〜
▼ Decompiler◎ Hex-Rays、品質トップ
○ x86/ARM/MIPS など別売
▼ スクリプトIDAPython / IDC
▼ コラボ△ Lumina で部分共有
▼ 強みDecompiler 品質最高
業界デファクト
膨大なプラグイン
▼ 弱み高価 (個人購入困難)
珍しい ISA 別売り
▼ 適性商用 / 大企業 SOC
高品質要求案件
Binary Ninja

Vector 35 / 商用 / 2016-

▼ 価格$ Personal $299〜
▼ Decompiler○ HLIL でアクセス可
○ 多段中間表現
▼ スクリプトPython (CPython, 速い)
▼ コラボ○ Enterprise 版
▼ 強みUI / UX 洗練
API 設計が綺麗
起動・操作が速い
▼ 弱み無料版は制限多
対応 ISA は中程度
▼ 適性プロ個人 / 開発者
API ヘビーユーザ
radare2 / Cutter

OSS / 2006- / Rizin fork

▼ 価格無料 (OSS)
▼ Decompiler△ pdc プラグイン
○ Ghidra 統合 (r2ghidra)
▼ スクリプトCLI 自体がスクリプト
+ Python / r2pipe
▼ コラボ△ 限定的
▼ 強みCLI 完結 / Unix 哲学
非常に多くの ISA
パイプ連携が強い
▼ 弱み学習曲線が急
Decompiler 弱い
▼ 適性CLI 派 / 自動化
CTF / ワンライナー

objdump / nm / readelf / strings は補助ツールとして併用 — 完結した分析環境ではない

使い分けの指針:

  • Ghidra: 学習開始 / 個人 / 大量サンプルの自動化 / 珍しい ISA / 共同解析 — 何より「学べる量と無料度の比」が圧倒的
  • IDA Pro: 業務で最高品質 Decompile が必要 / 既存プラグイン (Hex-Rays Decompiler、Hex-Rays Find Crypt 等) に依存 / IDA で書かれたチームの IDB 資産がある
  • Binary Ninja: UI / API のシャープさを評価する個人プロ / Python ヘビー / 起動の速さ重視
  • radare2 / Cutter: CLI 派 / シェル / Unix 流儀 / 軽量 / CI への組み込み

「Ghidra で始めて、必要なら IDA を買う」 が現代の典型的な学習ルート。最初から IDA を買う必要はない、というのがGhidra が業界に与えた最大の影響

7. 使われ方 — 実用文脈 #

Ghidra の主な実用文脈:

(1) マルウェア解析

サンプル受領 → Ghidra で 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 カメラ / 組込デバイスの firmwarebinwalk で展開 → ELF / raw bin 抽出 → Ghidra で解析MIPS / ARM / RISC-V の処理能力SLEIGH で珍しい組込 CPU にも対応可能な点が活きる。

(5) プロトコル解析

プロプライエタリなネットワークプロトコル (ゲーム / SCADA / 古い独自プロトコル) の挙動を、実装バイナリから逆算してパケット形式を復元する。Cross-references で受信処理から辿るのが定石。

(6) ライセンス検証回避 (法的グレーゾーン)

シェアウェアの「シリアル番号検証」を逆算する古典的ユースケース。正規目的の研究は OK だが、商用ソフトの crack 配布は著作権侵害自分が買ったソフトの自分用の調査にとどめるべき。

8. 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

スクリプトの例 (Python / Jython):

# すべての関数の名前と呼び出し先を列挙
fm = currentProgram.getFunctionManager()
for func in fm.getFunctions(True):
    print("Function:", func.getName())
    for ref in func.getEntryPoint().getReferenceIteratorTo():
        print("  called from:", ref.getFromAddress())
# Strings から URL / IP らしいものを抽出
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 (multiple GitHub repos): Find Crypt / String Decryption / Anti-VM 検知 など
  • Ghidra-CTF: CTF 向けの一般化スクリプト
  • Ghidra Bridge: 外部の CPython (PyPI ライブラリ使い放題) と Ghidra Jython を橋渡し → angr / capa / yara を統合

9. 限界とコツ — 「Decompiler は完璧ではない」 #

Ghidra (および全 RE ツール) の 限界:

  • Decompiler の出力は近似 — 特にスタックの誤認 / レジスタの型推論失敗 / カーネルレベルコード / 高最適化 (LTO/PGO) で誤訳が起きる。**「アセンブリに戻って検証する」**のが原則
  • Packing / Obfuscation — UPX 程度なら自動展開できるが、商用パッカー (VMProtect, Themida)手作りパッカー事前に動的に unpacking (= プロセスダンプ) してから渡す必要がある
  • JIT / JVM / .NET / Python — 機械語ではなく中間バイトコード — Ghidra より dnSpy (C#) / jadx (Java) / Decompyle3 (Python) など専用ツールが向く
  • Stripped binary — シンボル / デバッグ情報がない場合、関数名 / 変数名はすべて自分で貼り直すことになる
  • 巨大なバイナリ — 100MB 級になると Auto-analyze に数十分〜数時間、GUI も重くなる。Headless で部分処理するのが定石
  • JVM の起動コストghidraRun 起動だけで 10〜20 秒
  • UI に独特の癖 — IDA / Binary Ninja から来た人は最初戸惑う

現場の知恵:

  • 小さく試す: 不明な関数は 「呼び出し元から逆に辿る」 (xrefs)最も効率的main からトップダウンで行き詰まりがち
  • シグネチャ DB を活用 — Function ID でライブラリ関数を自動命名しておくと、解析の意味的負荷が一気に減る
  • 構造体を貼る「ここはおそらく XYZ 構造体のメモリ」と気づいたら型を貼る → Decompiler の出力が劇的に良くなる
  • コメントと改名はケチらない半年後の自分が読むのが前提
  • スクリプトで定型化2 回やった作業はスクリプトに

10. 関連ツールとエコシステム #

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 BridgeCPython 側から Ghidra API を叩けるようにし、angr (シンボリック実行) や capa (能力検出) の Python ライブラリと統合するのが上級者の使い方。


Ghidra は NSA が 2019 年に OSS 公開したリバースエンジニアリング統合環境で、SLEIGH によるプロセッサ仕様の宣言的記述 + P-Code 中間表現 + 共通の解析エンジンという設計で、x86 / ARM / MIPS / PowerPC / RISC-V / 珍しい組込 CPU まで 1 つのツールで解析できる

最大の歴史的意義「無料 + OSS の Decompiler を一般に開放した」こと。IDA Pro が事実上独占していた高品質 RE 市場に風穴を開け、マルウェア解析 / 脆弱性研究 / CTF / ファームウェア解析の裾野を一気に押し広げたRE 学習のスタートライン価格ではなく興味と時間」だけにした影響は計り知れない。

技術的には 「Disassembly → P-Code lift → データフロー / 制御フロー解析 → Decompile」のパイプラインが Code Browser GUI で統合され、シンボル / 型 / コメント / Bookmarkがプロジェクトに永続化される。Headless Analyzer による自動化 / Python (Jython) / Java スクリプト / Version Tracking個人〜企業の実用に耐える運用機能を備える。

Decompiler 出力は近似であり完璧ではない / Packing は事前 unpack が必要 / JIT / .NET / Python は別ツールが向く / 学習曲線は急 — 限界はあるが、RE を学び始めるなら Ghidra から、必要に応じて IDA Pro / Binary Ninja / radare2 を併用するのが現代の標準ルート。