【実務・中級編】バイナリ解析の必須知識！GDBで隠されたシンボルとPLT/GOTを徹底追跡する方法 – デバッグ・コード品質・テストツール生産性向上バイブル

バイナリ解析の極意：GDBで暴くPLT/GOTとストリップトバイナリの追跡術

テックリードの皆さん、日々のデバッグ作業において「なぜそのセグメンテーション違反（SIGSEGV）が起きたのか」「なぜ共有ライブラリのバージョン差異で挙動が変わるのか」を、ソースコードなしに即座に突き止められたら、どれほど開発スピードが加速することでしょう。

ネットを検索すれば「GDBのインストール方法」や「`break main` のやり方」といった、新米プログラマー向けのマニュアルの翻訳記事が溢れています。しかし、我々プロフェッショナルが直面するのは、ソースコードの無いサードパーティ製バイナリ、シンボルが完全に削ぎ落とされた（ストリップされた）本番環境のコアダンプ、そして動的リンクの裏側で複雑に絡み合うPLT/GOT（Procedure Linkage Table / Global Offset Table）の迷宮です。

今回は、GDBを単なるブレークポイントツールから「バイナリの内部構造を透視する最強のX線装置」へと昇華させる、極限の実践テクニックを伝授します。動的リンクのメカニズムを低レイヤから理解し、実務で即座に使える設定とコマンドライン芸をマスターしましょう。

—

1. 共有ライブラリ呼び出しの裏側：PLT/GOTメカニズムの完全理解

モダンなOSにおける実行ファイルは、メモリフットプリントを削減し、セキュリティ（ASLRなど）を担保するために外部の共有ライブラリ（`.so` や `.dll`）を動的にリンクします。ここで問題になるのが、「実行開始時点では、共有ライブラリ内の関数がメモリ上のどこにロードされるか分からない」という点です。

これを解決するのが PLT と GOT です。

PLT (Procedure Linkage Table) と GOT (Global Offset Table) のデータフロー

GOT (.got.plt): グローバルオフセットテーブル。実際の関数アドレスや、遅延バインディングのためのジャンプ先アドレスが格納されるデータセクション。
PLT: プロシージャリンケージテーブル。実効アドレスが未解決の段階で、動的リンカ（`ld.so`）を呼び出してアドレスを解決するためのスタブコード。

初回呼び出し時の遅延バインディング（Lazy Binding）のシーケンスは以下の通りです：

1. アプリケーションが `printf()` などの外部関数を呼び出す際、コードは直接関数を叩くのではなく、PLTエントリ（例: `printf@plt`）にジャンプする。
2. PLTエントリは、対応するGOTエントリ（例: `.got.plt`）にストアされているアドレスへジャンプしようとする。
3. 初回実行時、GOTエントリには「動的リンカの解決コード（リロケーションルーチン）」のメモリアドレスが入っている。
4. 動的リンカが呼ばれ、libcの中から `printf` の実アドレスを特定し、GOTエントリの内容を実アドレスに書き換える（2回目以降の呼び出しでは、動的リンカをバイパスして直接高速に実行される）。

この仕組みをGDBのメモリダンプ機能で目撃することが、低レイヤデバッグの第一歩です。

—

2. GDBによる動的リンクの追跡とGOT書き換えの瞬間

実際にGDBを用いて、`printf` がどのようにGOTを経由して解決されるのかを追跡してみましょう。

実践：GDBセッションとコマンドシーケンス

以下のコマンド群は、デバッグ対象のバイナリ（例: `app`）を起動し、GOTが書き換わる瞬間を捉えるためのものです。

バイナリをGDBで起動し、環境変数を設定
(gdb) file ./app

main関数にブレークポイントを設定
(gdb) break main
(gdb) run

printfのPLTエントリを確認する
(gdb) disassemble main
出力例:
0x0000000000401126 <+22>: call 0x401030

PLTエントリの中身を逆アセンブルしてGOT参照を確認する
(gdb) disassemble 0x401030
出力例:
0x401030 : endbr64
0x401034 : bnd jmp 0x2ffc(%rip) <- ここがGOTを参照している 0x40103b : push $0x0 <- 初回のみ実行されるリンカへのインデックスプッシュ 0x401040 : jmp 0x401020 <- 動的リンカのエントリへジャンプ GOTエントリのメモリアドレスを特定して確認（初回：リンカのアドレスを指している） (gdb) x/gx 0x404018 0x404018 : 0x00007ffff7fa06a0 (動的リンカ内部のスタブを指している)

printfの呼び出し直前まで実行
(gdb) break 0x0000000000401126
(gdb) continue

【重要】printf実行「前」のGOTの状態を確認
(gdb) x/gx 0x404018
0x404018 : 0x00007ffff7e12900 <-- まだリンカのスタブ stepiでprintf@pltに侵入し、解決処理をステップ実行で抜ける (gdb) stepi (gdb) stepi ... 【重要】printf実行「後」のGOTの状態を確認（アドレスがlibc内の実体に書き換わっている！） (gdb) x/gx 0x404018 0x404018 : 0x00007ffff7e224e0 <-- libc.so内の実際のprintfアドレスに書き換わった！この「GOT書き換えの瞬間」をアセンブリレベルで追跡できるようになると、GOT上書き脆弱性（GOT Overwrite）の解析や、プロファイラ自作レベルの深い洞察が得られます。 ---

3. シンボルストリップされたバイナリの解析と逆算テクニック

実務で最も絶望するのは、`strip` コマンドで関数名やシンボルテーブルが完全に削除されたバイナリを渡されたときです。`info functions` や `break main` すら機能しない場合があります。この絶望的状況を打破するテクニックを解説します。

A. エントリーポイント（`_start`）からの手動トレース

シンボルが無くとも、ELFヘッダに定義されたエントリーポイント（通常は `_start`）は存在します。

エントリーポイントを確認してブレーク
(gdb) info files
Entry point: 0x4010a0 と表示された場合
(gdb) break 0x4010a0
(gdb) run

レジスタ（特にx86_64ならrdxに登録されるfiniポインタなど）やスタック構造を解析し、__libc_start_mainの呼び出しを探す
(gdb) x/20i $pc

B. 関数テーブル（関数ポインタ配列）の逆算

C++の仮想関数テーブル（vtable）や、関数ポインタの配列が構造体の中に埋め込まれている場合、コード領域（`.text` セクション）を指しているメモリアドレスの塊を探すことで、関数の存在を逆算できます。

バイナリのセクション情報を確認
(gdb) info sections
.text セクションの範囲が 0x401000 から 0x401200 だとする

メモリ領域から「コード領域を指しているポインタ」を総検索する (findコマンド)
(gdb) find 0x404000, 0x405000, 0x401000
これにより、GOTやデータセクション内にある関数ポインタのリストを炙り出すことができる

—

4. チーム全体の生産性を爆発させるGDB設定のベストプラクティス

GDBのデフォルトUIは正直言って現代のエンジニアにはスパルタすぎます。ここからは、チーム全体のデバッグ効率を劇的に引き上げるための「神設定」と「設定ファイル共有ルール」を公開します。

必須の拡張・プラグイン：GEF (GDB Enhanced Features)

GDBの標準UIをモダンなハッカー向けUIに一変させるプラグイン GEF (GDB Enhanced Features) または Pwndbg をチーム標準として強制導入してください。レジスタ、スタック、逆アセンブリ、コード領域が1つの画面に美しくタイル表示されます。

導入は以下の1コマンドです：

bash -c “$(curl -fsSL https://gef.blah.cat/sh)”

チーム共有用 `.gdbinit` 設定ファイル

プロジェクトのルートディレクトリや各エンジニアのホームディレクトリに配置し、チーム全体でセキュアかつ高速なデバッグ環境を統一するための `.gdbinit` のベストプラクティス構成例です。

=====================================================================
GDB Global Configuration & Best Practices for C/C++ Development Teams
=====================================================================

1. セキュリティと安全性の設定
ホスト環境への安全でないコマンド実行を許可しない（デフォルト有効だが明示）
set confirm off

2. ページャーの設定
長い出力結果（disassembleなど）で毎回スペースキーを押す手間を省き、一括表示する
set pagination off

3. 逆アセンبリのデフォルトフォーマットをIntel形式に統一
日本人エンジニアや多くのx86系開発者に直感的なIntel記法（op dest, src）を採用
set disassembly-flavor intel

4. 履歴の保存と永続化
デバッグコマンドの履歴をファイルに保存し、チーム間や次回セッションでの再利用性を高める
set history save on
set history size 10000
set history filename ~/.gdb_history

5. デバッグシンボル自動ロードの安全確保（Auto-load safe-path）
セキュリティ脆弱性（CVE-2018-11236等）を防ぐため、安全なパスのみスクリプトの自動実行を許可
add-auto-load-safe-path /app/workspace/
add-auto-load-safe-path /usr/share/gdb/

6. 例外やシグナル発生時のハンドリング
子プロセスがforkした際に自動的にデバッグ対象を追跡する設定
set detach-on-fork off
set follow-fork-mode child

7. ユーザー定義マクロ/コマンドの読み込み（チーム共有スクリプト）
プロジェクト特有のデータ構造を綺麗に表示するカスタムプリンタをインポート
python
import sys
sys.path.insert(0, ‘/app/workspace/tools/gdb_helpers’)
from custom_pretty_printers import register_my_printers
register_my_printers()
end

—

5. 開発スピードを極限まで引き上げるキーボードショートカット

GUIデバッガやマウス操作に依存していると、思考のコンテキストスイッチが発生し、バグ追跡の集中力が途切れます。GDBのCLI環境で指を離さずに高速移動するための「隠れたキーボードショートカット」を体に叩き込んでください。

—

結びに代えて

PLT/GOTの構造を理解し、シンボルが削ぎ落とされたバイナリの迷宮をGDBの低レイヤコマンド（`x`, `stepi`, `disassemble`）で切り裂くスキルは、一朝一夕には身につきません。しかし、この領域をマスターしたエンジニアは、世の中のいかなるブラックボックスなシステムに対しても、怯むことなく原因を突き止める圧倒的な自信を手に入れることができます。

明日からのデバッグセッションで、ぜひ今回の設定ファイルとコマンド群を実践し、あなたのチームの生産性を圧倒的な高みへと引き上げてください。