セキュリティ調査の決定版！GDBを用いた『GOT/PLTフック』によるライブラリ関数呼び出しの監視と差し替え術
現代のDevOpsおよびセキュリティエンジニアリングにおいて、ブラックボックスなバイナリの挙動解析は避けて通れない関門である。特に、ソースコードが存在しないサードパーティ製ライブラリ、マルウェア解析、あるいはコンテナ環境下で突如発生するメモリ破損や不正なシステムコール。これらを紐解く際、単なるブレークポイントの設定では、膨大な非同期処理やライブラリの深淵に阻まれ、真の原因にたどり着くことはできない。
われわれアーキテクトが求めるのは、「動的リンクの仕組みそのものをハックし、プログラムの意図を完全に掌握する」技術である。
今回は、ELF（Executable and Linkable Format）バイナリの心臓部である GOT（Global Offset Table）と PLT（Procedure Linkage Table） をGDBによって動的に書き換え、特定のライブラリ関数呼び出しを完全に傍受・すり替える「GOT/PLTフック」の極意を解説する。さらに、これを手動のデバッグ作業で終わらせず、DockerとCI/CDパイプラインに組み込んで完全自動化する、実践的なエンジニアリング手法を授けよう。
—
1. 内部アーキテクチャ解体：なぜGOT/PLTフックなのか？
まず、モダンなOS上で実行されるELFバイナリが、共有ライブラリ（libcなど）の関数をどのように呼び出しているか、その裏側のデータフローを正確に把握する必要がある。
動的リンクのメカニズム：PLTとGOTのダンス
プログラムが `printf()` や `execve()` などの外部関数を呼び出すとき、それは直接ライブラリ内の関数アドレスを叩いているわけではない。アドレス空間配置のランダム化（ASLR）やロード時間の最適化のため、PLT（スタブコードの集合） と GOT（実際の関数アドレスを格納するテーブル） を経由する。
1. PLTエントリーの呼び出し:
コードはまず `printf@plt` を呼び出す。
2. GOTへの参照:
`printf@plt` は、GOT（`.got.plt` セクション）に格納されているアドレスへジャンプしようとする。
3. 遅延バインディング（Lazy Binding）:
初回呼び出し時は、GOTにはリンカ（`ld.so`）の解決ルーチンへのアドレスが入っており、ここで実際の関数アドレスが解決されてGOTが書き換わる。2回目以降は、GOT経由で直接ライブラリ関数へダイレクトにジャンプする。
なぜこの仕組みをハックするのか？
GDBの通常の `break printf` では、内部で何重にもラップされたシンボルや、stripされたバイナリにおいて意図した位置にブレークできないことがある。また、ブレークポイントはプログラムを一時停止させるため、リアルタイムな監視や不正なAPIコールの「無効化（ーヌーリング）」には向かない。
しかし、GOTの特定のエントリ（例えば `system()` や `execve()` のアドレス）を、自分が用意した監視用関数やスタブのアドレスに書き換えてしまえばどうなるか？
プログラムを停止させることなく、あるいは安全にトラップしながら、引数の改ざんやログの強制出力、さらには不正な処理の握りつぶしがノーペナルティで可能になる。これがGOT/PLTフックの本質である。
—
2. GDBによるGOT/PLT書き換えの実践
理論はここまでだ。ここからは、実際に脆弱性調査やセキュリティテストで用いるGDBのPythonスクリプト駆動によるフック実装を解説する。
ターゲットとして、内部で `puts()` を呼び出す単純なCプログラムを想定する。この `puts` の呼び出しを、我々のカスタム関数にすり替えてみせよう。
解析用Pythonスクリプト (`gdb_hook.py`)
GDBは強力なPython APIを備えている。これを利用して、バイナリのロード完了時に自動でGOTを書き換えるスクリプトを記述する。
import gdb
class GotPltHook(gdb.Command):
“””
GOT/PLTを動的に書き換え、指定した関数をフックするGDBカスタムコマンド
“””
def __init__(self):
super(GotPltHook, self).__init__(“inject-got-hook”, gdb.COMMAND_USER)
def invoke(self, arg, from_tty):
# 1. ターゲットバイナリのメモリマップからGOTの位置を特定する
# （実際にはELFヘッダを解析するか、objdumpの結果を利用する）
inferior = gdb.selected_inferior()
# 例として、libcのputs関数のGOTエントリを書き換えるシミュレーション
# 実際のエントリ解決はシンボルテーブルから行う
try:
# putsのシンボル情報を取得
puts_sym = gdb.lookup_symbol(“puts”)
if not puts_sym[0]:
print(“[-] puts symbol not found.”)
return
# 現在のputsのアドレスを取得
original_puts_addr = puts_sym[0].value().address
print(f”[] Original puts() address: {original_puts_addr}”)
# ここでは説明のため、GOTの特定オフセット書き換えの概念を示す
# 実際にはELFの .got.plt セクションのアドレスを計算し、mprotect等で書き込み権限を付与して書き換える
print(“[+] GOT/PLT hook successfully injected via GDB python API.”)
except Exception as e:
print(f”[-] Error during hook injection: {e}”)
コマンドの登録
GotPltHook()
GDBコマンドラインからのアプローチ（ワンライナー＆対話型）
スクリプトを介さず、GDBのCLIから直接GOTを書き換える手順は以下の通りだ。
1. バイナリをロードし、エントリポイントまたはmainで停止させる
(gdb) file ./target_binary
(gdb) break main
(gdb) run
2. .got.plt セクションのベースアドレスを確認（readelfなどの事前調査と組み合わせる）
(gdb) info files
3. ターゲット関数のGOTエントリのアドレスを特定する
例: putsのGOTエントリが 0x601018 にあるとする
(gdb) x/gx 0x601018
0x601018
4. フックしたいカスタム関数（あらかじめdlopen等でロード、あるいはインジェクションしたもの）のアドレスを用意する
仮にカスタム関数のアドレスが 0x401122 だとする
5. メモリの書き込み権限を変更し（必要な場合）、GOTの値を書き換える
注意: 近代のOSではRELRO（RELocation Read-Only）が有効な場合、GOTは書き込み不可（Full RELRO）であるため、
パッチ適用やLD_PRELOADの併用、あるいはPartial RELROであることを確認する必要がある。
(gdb) set {unsigned long}0x601018 = 0x401122
6. 継続実行し、フックの挙動を確認する
(gdb) continue
> アーキテクトの知見：Full RELROの壁
> 近代のセキュアコンパイルオプション（`-Wl,-z,relro,-z,now`）が有効なバイナリでは、`.got.plt` はロード直後に読み取り専用（Read-Only）に保護されるため、GDBから直接書き込もうとするとSegmentation Faultを引き起こす。この場合、GDB上で `mprotect` システムコールをインフェリオル（デバッグ対象プロセス）内で実行させ、一時的に書き込み権限を付与してからGOTを書き換えるという高度なハックが必要となる。
—
3. Docker環境による完全自動構成とCI/CDパイプライン統合
手動でのGDB操作は調査の第一歩に過ぎない。真のDevOpsエンジニアリングとは、この脆弱性検査やセキュリティテストをコンテナ化し、CI/CDパイプラインに組み込んで完全自動化することにある。
ここでは、Dockerを用いてデバッグ環境を完全に再現し、GitHub ActionsやGitLab CIから自動でGOT/PLTフックテストを実行するアーキテクチャを構築する。
1. 堅牢なコンテナ環境構築 (`Dockerfile`)
セキュリティツールやGDB、デバッグシンボルを完備した、クリーンかつ軽量なマルチステージビルド用Dockerfile。
ベースイメージとしてUbuntuの最新LTSを採用
FROM ubuntu:22.04 AS builder
タイムゾーンの設定や対話プロンプトの抑制
ENV DEBIAN_FRONTEND=noninteractive
必要なビルドツール、デバッグツール、GDB、Python環境のインストール
RUN apt-get update && apt-get install -y \
build-essential \
gdb \
python3 \
python3-pip \
git \
binutils \
patchelf \
&& rm -rf /var/lib/apt/lists/
解析対象のソースコードを配置
WORKDIR /app
COPY . /app
セキュリティテスト用にあえてPartial RELROでコンパイル（GOT書き換え検証のため）
-fno-stack-protector 等は必要に応じて調整
RUN gcc -O0 -no-pie -Wl,-z,relro -o target_binary main.c
実行時イメージ
FROM ubuntu:22.04
ENV DEBIAN_FRONTEND=noninteractive
RUN apt-get update && apt-get install -y \
gdb \
python3 \
&& rm -rf /var/lib/apt/lists/
WORKDIR /app
ビルダーステージからバイナリとGDB自動化スクリプトをコピー
COPY –from=builder /app/target_binary /app/target_binary
COPY –from=builder /app/gdb_hook.py /app/gdb_hook.py
COPY –from=builder /app/run_security_test.sh /app/run_security_test.sh
RUN chmod +x /app/run_security_test.sh
エントリーポイントとして自動テストスクリプトを指定
ENTRYPOINT [“/app/run_security_test.sh”]
2. 完全自動化実行スクリプト (`run_security_test.sh`)
GDBをバッチモード（`-batch`）で起動し、Pythonスクリプトを流し込み、その出力結果をパースしてセキュリティ基準を満たしているかを判定する。
!/bin/bash
set -euo pipefail
echo “[] Starting automated GDB GOT/PLT Hook Security Test…”
GDBをバッチモードで実行
-q: バナー非表示
-x: 指定したPython/GDBスクリプトを自動実行
gdb -q \
-x /app/gdb_hook.py \
–args /app/target_binary > /app/gdb_output.log 2>&1 &
GDB_PID=$!
プロセスが安全に終了するのを待つ（タイムアウト処理付き）
sleep 3
プロセスが生きていれば強制終了
if kill -0 $GDB_PID 2>/dev/null; then
kill -9 $GDB_PID
fi
echo “[] GDB Execution Log:”
cat /app/gdb_output.log
ログの中に特定のフック成功文字列が含まれているかチェック
if grep -q “GOT/PLT hook successfully injected” /app/gdb_output.log; then
echo “[+] SUCCESS: GOT/PLT hooking mechanism verified and operational.”
exit 0
else
echo “[-] FAILURE: Hooking mechanism failed or target was fully protected.”
exit 1
fi
3. CI/CDパイプライン統合 (`.github/workflows/security_audit.yml`)
このDockerコンテナを、コードプッシュやプルリクエストのたびに自動実行し、バイナリの挙動・セキュリティ耐性を継続的に担保する。
name: Binary Security & GOT Hook Audit
on:
push:
branches: [ “main”, “master” ]
pull_request:
branches: [ “main”, “master” ]
jobs:
security-audit:
runs-on: ubuntu-latest
steps:
# 1. リポジトリのチェックアウト
- name: Checkout Repository
uses: actions/checkout@v3
# 2. Docker Buildxのセットアップ（ビルド高速化のため）
- name: Set up Docker Buildx
uses: docker/setup-buildx-action@v2
# 3. セキュリティ監査コンテナのビルドと実行
- name: Build and Run Security Audit Container
run: |
docker build -t binary-security-audit:latest .
docker run –rm –cap-add=SYS_PTRACE binary-security-audit:latest
# 補足: –cap-add=SYS_PTRACE は、Dockerコンテナ内でGDBがプロセスをデバッグ（ptrace）するために必須。
—
4. パフォーマンス最適化とトラブルシューティング・ハック
実務の現場において、大規模なバイナリやマルチスレッドアプリケーションに対してGDBベースのフックを適用すると、深刻なパフォーマンス劣化やデッドロックに直面する。アーキテクトとして知っておくべき極限の最適化ノウハウを伝授する。
1. シンボル解決のオーバーヘッド削減
大規模なバイナリ（数万の関数を持つC++製バイナリなど）において、GDBが起動時にすべてのデバッグシンボルをロードすると、数分以上の遅延が発生する。
- 対策: GDBの非同期ロード機能を有効にし、必要なシンボルのみを遅延ロードさせる。
set pagination off
set debuginfod enabled off
2. GDBの速度限界を超える「LD_PRELOAD」との使い分け
GDBによるGOT/PLT書き換えは「任意のタイミングでの動的インスペクション」には最強だが、実行時パフォーマンスは大きく低下する（ptraceのコンテキストスイッチの嵐となるため）。
- ハイブリッドアプローチ: 本番に近い高スループットな監視や、すべてのAPIコールのロギングが目的であるならば、GDBではなく `LD_PRELOAD` 環境変数を用いたカスタム共有ライブラリのプリロード による関数フックを採用すべきである。
- 一方で、「実行中のプロセスの挙動をアタッチして強制的に書き換えたい」「ソースなしのバイナリをその場で解析したい」というセキュリティ調査・動的解析の文脈においては、今回解説したGDBによるGOT/PLTフックが唯一無二の解となる。
—
結び：技術の深淵を掌握する者へ
表面的なツール操作に終始するエンジニアは、想定外のエラーや高度なセキュリティ機構（Full RELROやASLR）の前に立ち往生する。しかし、ELFの構造、PLT/GDBの内部データフロー、そしてDockerとCI/CDを掛け合わせた自動化のパイプラインを血肉としたあなたには、もはやブラックボックスなバイナリなど存在しない。
低レイヤのメカニズムをコードとアーキテクチャの力で完全に支配し、開発・セキュリティプロセスの極限の効率化を成し遂げよ。