Ghidra デバッガの使い方：起動・アタッチ・ステップ実行

Ghidra にデバッガはありますか？

あります。Ghidra のデバッガーは実行中の対象を起動または接続し、トレースを記録し、レジスターやメモリーを表示し、ブレークポイントとステップ操作で実行を観察するための機能です。Decompiler の代わりではありません。Decompiler は静的にバイト列を解釈し、デバッガーは一回の実行時点の状態を観察します。

最初のセッションは三つのビューをつなぐ作業だと考えると分かりやすくなります。GDB などのターゲットエージェントがプロセスを制御し、Ghidra が変化をトレースとして記録し、静的プログラムが関数名や参照先の文脈を与えます。一つのパネルだけで結論を出さず、三つを比較してください。

Ghidra、GDB、安全な検証環境を準備する

2026年8月6日の確認では、公式 NationalSecurityAgency/ghidra の最新リリースは Ghidra 12.1.2 でした。公開日は2026年6月5日で、インストールガイドに記載した 64-bit JDK 21 の要件も変わっていません。まず公式アーカイブが起動することを確認してからデバッガーを調べます。

以下の例はネイティブ対象と GDB の考え方を使います。画面上の項目は OS やターゲットエージェントで変わりますが、対象のアーキテクチャ、エンディアン、引数、ローカル起動かアタッチかリモート接続かを最初に固定する点は共通です。

• 入力と出力が予測しやすい小さな実行ファイルを使う。
• 元ファイル、ハッシュ、Ghidra プロジェクトを別のフォルダーに保存する。
• 対象が不明なときは静的解析から始め、実行を必須にしない。
• ターゲットエージェント別の例は 公式デバッガー資料で確認する。

Ghidra デバッガーで最初の対象を起動する

Non-Shared Project を作成し、練習用の実行ファイルをインポートします。次に Debugger ツールを開きます。最初の目的は完全なソース復元ではありません。対象が起動し、アーキテクチャが一致し、トレースに有効な状態が入ることを確認します。

ローカル GDB の起動方法を選び、Launch を押す前にすべての項目を確認します。Image は対象ファイル、Arguments は実際の引数、gdb command はデバッガー実行ファイル、Architecture と Endian は検体に合わせます。設定が不明なら再試行を繰り返さず、形式とプロセッサーを確認してください。

1. 1

   プロジェクトを作る

   File > New Project から Non-Shared Project を選び、検証用フォルダーに保存します。起動するファイルと同じものをインポートします。

2. 2

   Debugger を開く

   Debugger ツールと環境に合うターゲットエージェント操作を開きます。比較できるよう静的プログラムも残します。

3. 3

   起動項目を確認

   ファイル、引数、GDB コマンド、アーキテクチャ、エンディアン、必要なら端末を設定します。最初は特殊文字を含まないパスにします。

4. 4

   起動して停止

   対象を起動し、最初の停止を待ち、ステップ実行の前にスレッド、プログラムカウンター、Listing、コンソールを確認します。

プロセスへアタッチし、リモート対象へ接続する

Launch はデバッガーの管理下で新しい対象を開始します。Attach はすでに動いているプロセスから始め、リモート接続は GDB server などのターゲットエージェントを使います。権限、アーキテクチャ、メモリーマップ、ネットワーク要素が増えるため、まずローカル起動を成功させてください。

アタッチでは、許可された検証環境でプロセスを選び、コネクターを合わせ、アーキテクチャを確認します。リモートではホスト、ポート、サーバーの版、シンボル、信頼境界を確認します。接続成功だけでは、レジスターやメモリーがトレースに入ったとは限りません。

1. 1

   接続方式を選ぶ

   新しいローカルプロセスなら Launch、既存のローカルプロセスなら Attach、GDB server なら対応するリモート方式を使います。

2. 2

   対象を一致させる

   プロセッサー、エンディアン、OS、アドレス空間を確認し、必要なら対応するシンボルを読み込みます。

3. 3

   最初の停止を確認

   スレッド、カウンター、モジュール、コンソールを確認します。接続バナーだけならまだ準備完了ではありません。

デバッガーのワークスペースを理解する

ワークスペースには同じ実行状態を異なる角度で表示するパネルがあります。まずプログラムカウンターと選択中のスレッドを確認し、一つの疑問に一つのパネルを使います。最初からすべてのビューを開くと原因を見失いやすくなります。

Registers は高水準の説明ではなく、ある停止時点のスナップショットです。値が変わった理由は Listing の命令、スタックやメモリー、静的プログラムの呼び出し関係で確認します。

ブレークポイントとステップ実行を使う

ブレークポイントは、停止した理由を説明できる場所に置くと役立ちます。入口、既知の関数、練習用入力に関係する分岐から始めます。Resume は続行、Interrupt は停止、Step Into は呼び出しへ入り、Step Over は現在の階層を保ち、Step Out は呼び出し元へ戻ります。

設定したブレークポイントが有効にならない場合は、モジュールがロードされたか、アドレスがマップされたか、権限があるか、静的と動的の対応が正しいかを確認します。最適化や inline 化された関数では近くの命令を選ぶ必要があります。

• 最初は一つのブレークポイントだけ設定する。
• ステップ前にカウンター、スレッド、重要なレジスターを記録する。
• 停止ごとに入力、分岐、メモリー値、結論を残す。
• 共有前に一時的なブレークポイントを削除または無効化する。

ライブ状態を CodeBrowser と Decompiler に戻す

トレースと静的プログラムを対応付けると、デバッガーの価値が高まります。プログラムカウンター、モジュール、関数、命令バイトを使って CodeBrowser の同じ場所を探します。Decompiler は仮説として読み、Listing とライブ状態で重要な結論を確認します。

この対応付けが、単独の GDB 端末との違いです。GDB は実行を制御し、Ghidra はシンボル、メモリーブロック、参照、Decompiler の文脈とトレースを並べて保持します。対応がずれるときはモジュールベース、アーキテクチャ、relocation、インポートしたプログラムを確認します。

1. 1

   動的アドレスを探す

   プログラムカウンターやブレークポイントから現在のモジュールとアドレスを特定します。

2. 2

   静的な一致を探す

   CodeBrowser の場所を開き、バイト、関数境界、モジュールの対応を確認します。

3. 3

   動作を説明する

   Listing、Decompiler、レジスター、メモリー、コールスタックを比較し、観測と推測を分けます。

Ghidra デバッガーでよくある問題

最初の失敗の多くは機能不足ではなく設定の不一致です。一度に一つだけ変更し、コンソール出力を保存します。複雑な対象の前に小さな検体でツールチェーンを確認してください。

接続できたことだけで準備完了とは判断しません。スレッド、カウンター、モジュール、データの入った状態パネルを確認します。シンボルがない、または最適化が強い対象では、シンボルとアドレス対応付けに時間が必要です。

最初のデバッグ後に学ぶこと

リモート対象や多数のスレッドへ進む前に、小さく許可されたプログラムで起動と停止の流れを二、三回繰り返します。入力、ブレークポイント、レジスターまたはメモリーの変化、対応する静的関数を一つの説明としてまとめる練習をしてください。

プロジェクト作成、Auto Analysis、参照、Function Graph は Ghidra 初心者チュートリアルを参照してください。擬似コードの型や名前は Decompiler ガイドで確認し、JDK や起動の問題なら インストールガイドへ戻ります。エージェント別の詳細は 公式デバッガー資料が基準です。