Ghidra 文字列検索：アドレス・命令・関数を見つける方法

手掛かりに合う検索ツールを選ぶ

Ghidraで文字列検索を始める前に、Ghidraがすでに定義したデータを探すのか、プログラムモデル内のテキストを探すのか、ロード済みメモリの生バイトを探すのか、完全なアドレスへ移動するのかを決めます。Defined Stringsは便利な一覧ですが、すべての文字列を保証するものではありません。短い文字列が未定義のこともあり、Unicodeの表現やメモリブロックの範囲が違えば同じ画面に表示されない場合もあります。

アドレス単位の確認ではListingを基準にします。検索で根拠を見つけた後にDecompilerを使って関数を説明し、Decompilerだけで検索を済ませないでください。より広いCodeBrowserの流れは公式初心者向けドキュメントで確認できます。このページは、初めての人が迷いやすい検索の判断に絞っています。

• 読める文字列：Defined StringsまたはSearch for Stringsから始め、参照を確認します。
• ラベル、シンボル、関数、コメント：Search Program TextまたはSymbol Treeを使います。
• 正確なアドレス：Go Toで移動し、ロード済みブロックと命令を確認します。
• バイト列や命令パターン：範囲を指定してSearch Memoryを使います。
• 利用元の関数：XREFを追い、Listing、Function Graph、Decompilerを比較します。

Decompilerで推測する前に文字列を検索する

表示メッセージ、URL、ファイルパス、コマンド、エラーの一部が分かっているなら、何百もの関数を読む前に文字列を検索します。Ghidraが認識済みの文字列を一覧にしたい場合はDefined Stringsを開きます。見つからない場合は文字列検索を使い、エンコーディング、最小長、アラインメント、終端、メモリブロックの範囲を確認します。結果が空でも、文字列が存在しないとは限らず、定義や範囲の設定が合っていないことがあります。

検索結果はアドレスを確認して初めて役立ちます。Listingで一致箇所を開き、バイト列と周辺データを確認し、ロード済みブロック内かを見ます。未定義データとして表示された場合は、アラインメントと近くの参照を確認してから定義します。大量の定義を行うときは元のプロジェクトを保管し、コピーで作業してください。

1. 1

   特徴的な手掛かりから始める

   完全なURL、特徴的な断片、珍しい拡張子は、一般的な語や初期化名より偽陽性が少なくなります。

   Defined Strings / Search for Strings
2. 2

   エンコーディングと範囲を確認する

   ASCII、UTF-8、UTF-16など対象に合う表現を試し、ロード済みブロック、全ブロック、選択範囲のどれを検索するか確認します。

   Encoding + memory block scope
3. 3

   Listingでアドレスを開く

   バイト列、データ型、周辺の文字列、参照を確認します。ハイライトだけで利用元の関数だと判断しません。

   Open in Listing
4. 4

   有効な参照を一つ追う

   ReferencesやXREFから、値を比較・整形・呼び出しするコードへ移動し、文字列の役割を確認します。

   References / Show XRefs

文字列が使われる場所と意味を確認する

URLやメッセージを見つけても、それは調査の途中です。データ項目を選び、参照を確認します。URLはネットワーク処理へ渡される場合も、ローカル値と比較される場合も、使われないリソースの場合もあります。メッセージもエラー処理、ライセンス確認、メニュー、デバッグ用分岐などさまざまです。参照先のアドレスは値を消費する場所を示し、呼び出し元と呼び出し先が役割を説明します。

複雑な関数に到達したらListingとDecompilerを行き来します。Listingは実際の命令とアドレスを示し、Decompilerは制御フローや変数の解釈を提案します。根拠がそろう前に名前を変更せず、観測した事実と推測を分けて記録すると、検索結果を過大評価せずに済みます。

• 近いアドレスの一致ではなく、実際のコードまたはデータ参照か確認します。
• 基本ブロックを読み、比較、呼び出し、整形処理を特定します。
• 関数名に意味を付ける前に呼び出し元と呼び出し先を確認します。
• 直線的なListingで分岐を追いにくいときはFunction Graphを使います。
• 擬似コードの読み方が問題ならDecompilerガイドを参照します。

メモリアドレス、値、バイトパターンを見つける

「0x00421A3Fはどこか」という質問は、まずナビゲーションの問題です。Go Toでアドレスへ移動し、Listingに表示されたプログラム、メモリブロック、言語、アドレス空間を確認します。ファイルオフセット、仮想アドレス、イメージベース、再配置後のアドレスは同じではありません。コピーしたアドレスが開けない場合は、ファイル、デバッガのトレース、ログ、再配置されたモジュールのどこから来た値かを確認します。

生データにはテキスト検索よりSearch Memoryが向いています。バイトの順序、エンディアン、アラインメントを考え、結果が多ければブロックや選択範囲を狭めます。一致した値がコード、データ、パディング、無関係な構造体にある可能性もあります。検索は候補を作る手段であり、周囲のバイトと参照を確認してから意味を判断します。

命令と命令パターンを検索する

命令検索では「この単語を探す」より具体的な質問が必要です。ニーモニック、レジスタ、定数オペランド、命令列、コンパイラが生成したバイト列のどれを探すのか決めます。Listingに表示される命令文字列ならSearch Program Text、エンコーディングが分かっているならSearch Memoryが向いています。インポート時に選んだアーキテクチャと言語が同じバイトのデコード方法を決めるため、先に設定を確認します。

Java命令や特定プラットフォームの語を探すときは、ソース言語の用語と逆アセンブリの表記を混ぜないようにします。Listingに実際に表示される表現を検索し、一致した命令のオペランドと制御フローを確認します。繰り返し使うパターンなら、アーキテクチャ、エンディアン、ワイルドカード、ロード済みメモリか選択範囲かを記録します。

1. 1

   パターンを定義する

   ニーモニック、オペランド、バイト、レジスタ、定数を書き出し、ビルドで変化する部分を分けます。

   Pattern = mnemonic + operands + optional wildcards
2. 2

   テキストかバイトかを選ぶ

   デコードされた表示が安定しているならテキスト、バイト表現が安定しているならメモリ検索を使います。

   Search Program Text / Search Memory
3. 3

   一致を検証する

   結果を開き、命令全体と基本ブロックを読み、参照と呼び出し元を比較します。

   Listing + XREF + Function Graph

関数、未定義関数、境界を確認する

検索結果がコードを指している場合は、Symbol Tree、Function Window、Listingの現在位置からGhidraが関数を認識しているか確認します。Undefinedは、解析がまだ関数境界を作っていない、アドレスがデータである、インポートしたアーキテクチャの見直しが必要、といった意味になります。近くの命令列が見慣れているからといって、すぐに関数を作らないでください。入口、参照、呼び出し規約、戻りの証拠を確認します。

検索中心の作業では、関数は証拠を整理する境界であり、動作の結論ではありません。アドレス、見つかったデータまたは命令、両者を結ぶ参照、次に値を使う関数を記録します。初心者向けチュートリアルでは、Auto AnalysisとFunction Graphを含む全体の流れを説明しています。

結果がない、または多すぎるときの確認点

Ghidraの検索で最も多い失敗は、手掛かりとプログラム内の表現が一致していないことです。URLが分割・エンコード・圧縮されている、UTF-16で保存されている、実行時に組み立てられている場合があります。アドレスが別のモジュールベースに属することもあります。命令パターンは、コンパイラが別のレジスタを選んだだけで変わります。設定は一度に一つだけ変え、元の手掛かりを残します。

結果が多すぎる場合は、メモリブロック、選択範囲、データ型、最小長、言語、アドレス範囲を絞ります。結果がない場合は、条件を一つだけ広げ、隣接バイト、別エンコーディング、ロード済みメモリを確認します。版による違いは古いスクリーンショットではなく、現在の公式ヘルプで確認します。