Reverse Engineering & Binary Analysis

リバースエンジニアリングとバイナリ解析

目的

バイナリ解析、アセンブリの解釈、逆コンパイル、ファームウェアのリバースエンジニアリング、プロトコル解析などのタスクで、Claude が支援できるようにします。Claude は RE ツールの出力を使って、逆アセンブルされたコードを直接読み解き、パターンを特定し、ロジックを再構築して、複雑なバイナリの解析を支援します。

---

アクティベーションのトリガー

ユーザーが次の内容について質問したときに、このスキルが有効になります。

• ELF、PE（exe/dll）、Mach-O、または生のバイナリの解析
• x86、x64、ARM、MIPS、または RISC-V のアセンブリコードの解釈
• 組み込み機器や IoT デバイスのファームウェアのリバースエンジニアリング
• ネットワークプロトコルのリバースエンジニアリング
• Ghidra、IDA Pro、radare2、または Binary Ninja の出力の利用
• バイナリや関数の動作の特定
• 逆アセンブル結果からの脆弱性の発見
• CTF のバイナリチャレンジ（pwn、reversing カテゴリ）
• アンチデバッグやアンチ解析手法の特定
• バイナリのアンパックや難読化解除

---

前提条件

pip install capstone pyelftools pefile lief

推奨 RE ツール：

• Ghidra — NSA のオープンソース RE フレームワーク（無料）
• radare2 / Cutter — オープンソース RE フレームワーク
• Binary Ninja — スクリプト機能を備えた商用 RE プラットフォーム
• IDA Pro / Free — 業界標準の逆アセンブラー
• GDB + GEF/PEDA/pwndbg — 動的デバッグ
• Binwalk — ファームウェアの抽出と解析
• strings, file, objdump, readelf — Linux 標準ユーティリティ

---

主な機能

1. バイナリの初期トリアージ

ユーザーがバイナリを提供した場合、またはファイルの種類を尋ねた場合：

次のコマンドを実行し、出力を Claude と共有して解析します。

# File type identification
file suspicious_binary

# Strings extraction (often reveals C2, keys, paths)
strings -a suspicious_binary | grep -E "(http|/etc|password|key|secret|flag)"

# ELF analysis
readelf -a suspicious_binary
objdump -d suspicious_binary | head -100

# PE analysis
python scripts/binary_analyzer.py --file malware.exe --strings --imports

# Entropy analysis (high entropy = packed/encrypted)
python scripts/binary_analyzer.py --file binary --entropy

バイナリのトリアージ用チェックリスト：

[ ] File type and format (magic bytes): ELF / PE / Mach-O / raw
[ ] Target architecture: x86 / x64 / ARM32 / ARM64 / MIPS / RISC-V
[ ] Endianness: little-endian / big-endian
[ ] Linking type: statically linked / dynamically linked
[ ] Security features: PIE / ASLR / NX/DEP / Stack Canary / RELRO
[ ] Packing detected: UPX / Themida / custom (high entropy sections)
[ ] Compiler identified: GCC / MSVC / Clang / Rust / Go
[ ] Interesting strings: URLs, IPs, credentials, file paths
[ ] Import/Export table: suspicious API calls
[ ] Entry point and sections mapping

セキュリティ機能の検出：

# Linux: checksec (from pwntools)
checksec --file=./binary

# Or check manually:
readelf -l binary | grep GNU_STACK    # NX bit
readelf -d binary | grep RELRO        # RELRO

2. アセンブリコードの解釈

ユーザーが逆アセンブルしたコードや Ghidra の逆コンパイル結果を貼り付けた場合：

Claude は次の処理を行います。

1. 命令の構文からアーキテクチャを特定します
2. 提供されたエントリーポイントから実行フローを追跡します
3. 関数呼び出し（call/bl/jal 命令）を特定します
4. アセンブリから高水準のロジックを再構築します
5. 各ブロックに、その目的を説明するコメントを付けます
6. セキュリティに関わるパターンを指摘します

よくある x86-64 のパターン：

パターン	命令	意味
関数プロローグ	push rbp; mov rbp, rsp; sub rsp, N	スタックフレームの設定
関数エピローグ	leave; ret または pop rbp; ret	スタックフレームの解放
ローカル変数	mov [rbp-N], rax	値をスタックに保存
ループカウンター	cmp rax, N; jl/jge loop_top	カウンターを使ったループ
スタック上のバッファー	sub rsp, 0x100	256 バイトのローカルバッファー
文字列コピー	rep movsb	メモリコピー
Memset	rep stosb	メモリのゼロクリア／値の設定
Switch-case	間接ジャンプ：jmp [rax*8 + table]	ジャンプテーブル
システムコール（Linux）	mov rax, N; syscall	直接システムコール
Printf／フォーマット文字列	lea rdi, [rip+str]; call printf@plt	出力文
ヒープ割り当て	call malloc / call operator new	動的メモリ割り当て

よくある ARM64 のパターン：

パターン	命令	意味
関数プロローグ	stp x29, x30, [sp, #-N]!	フレームポインターと LR の保存
リターン	ret（x30 を使用）	関数からの復帰
ペアのロード／ストア	ldp/stp	2 つのレジスターのロード／ストア
分岐とリンク	bl func	関数呼び出し
条件分岐	b.eq / b.ne / b.lt	条件付きジャンプ
システムコール	svc #0	システムコール

暗号定数の検出：

# Common crypto constants to watch for:
AES_SBOX = bytes.fromhex("637c777bf26b6fc5...") # AES SubBytes table
SHA256_K = [0x428a2f98, 0x71374491, ...]         # SHA-256 round constants
RC4_INIT_PATTERN                                   # Sequential 0x00-0xFF

3. ファームウェアのリバースエンジニアリング

ユーザーが組み込みファームウェアの解析を依頼した場合：

# Step 1: Identify firmware format
file firmware.bin
binwalk firmware.bin

# Step 2: Extract filesystem
binwalk -e firmware.bin
# Extracts to _firmware.bin.extracted/

# Step 3: Analyze extracted filesystem
ls -la _firmware.bin.extracted/
find . -name "*.cgi" -o -name "passwd" -o -name "shadow" -o -name "*.conf"

# Step 4: Find sensitive data
grep -r "password\|admin\|secret\|key" . --include="*.conf" --include="*.xml"

# Step 5: Find binary entry points
file _firmware.bin.extracted/bin/*
strings -a httpd | grep -E "(password|auth|key)"

ファームウェア解析チェックリスト：

[ ] Identify firmware packaging format (SquashFS, JFFS2, CPIO, raw)
[ ] Extract filesystem using binwalk -e
[ ] Identify target OS and RTOS (Linux, VxWorks, ThreadX, FreeRTOS)
[ ] Find hardcoded credentials in /etc/passwd, config files, binaries
[ ] Identify web interface binaries (httpd, lighttpd, uhttpd)
[ ] Check for debug interfaces (JTAG, UART, SSH enabled)
[ ] Identify update mechanism and signing verification
[ ] Search for private keys, certificates, API keys
[ ] Check for command injection in shell scripts and CGI handlers
[ ] Map memory layout from linker scripts or binary headers

4. プロトコルのリバースエンジニアリング

ユーザーがプロトコルをリバースエンジニアリングしたい場合：

キャプチャした通信またはバイナリデータがある場合：

1. フレーム構造の分析 — 次の点を確認します。

   • マジックバイトまたは同期パターン（先頭にある固定バイト列）
   • 長さフィールド（2 バイトまたは 4 バイト。多くの場合、オフセット 2〜4 にあります）
   • メッセージタイプ／コマンド識別子（1〜2 バイト）
   • チェックサム／CRC（最後の 1〜4 バイト）
   • パディングパターン（0x00 または 0xFF で埋められた領域）

2. フィールド型の識別：

   Common field patterns:
   - 4 bytes, big-endian, values 0-65535 → likely length or port
   - 16 bytes uniform random → UUID or AES key
   - Null-terminated variable sequence → ASCII string
   - Fixed 4 bytes: 0xDEADBEEF, 0xCAFEBABE → magic number
   

3. コマンドと応答の対応付け — ペアを分析して、次の点を特定します。

   • リクエスト：特定のタイプバイト → 応答：対応する確認応答
   • エラー応答：よくあるエラーコードのパターン

4. 状態機械の構築：

   [INIT] → send magic handshake → [AUTH] → send credentials →
   [CONNECTED] → send commands → [DATA] → receive data → [IDLE]
   

5. パーサーコードの生成：

   import struct
   
   MAGIC = b"\xDE\xAD\xBE\xEF"
   
   def parse_packet(data: bytes) -> dict:
       if not data.startswith(MAGIC):
           raise ValueError("Invalid magic bytes")
       
       msg_type, length = struct.unpack(">HH", data[4:8])
       payload = data[8:8 + length]
       checksum = struct.unpack(">H", data[8 + length:8 + length + 2])[0]
       
       return {
           "type": msg_type,
           "length": length,
           "payload": payload,
           "checksum": checksum
       }
   

5. アンチリバース技法の識別と回避

ユーザーが解析対策に遭遇した場合：

技法	指標	回避方法
UPX パッキング	UPX! 文字列、高いエントロピー	upx -d binary
アンチデバッグ：IsDebuggerPresent	インポートに API 呼び出しがある	パッチ：NOP を挿入するか、戻り値を 0 に固定
アンチデバッグ：ptrace チェック	ptrace(PTRACE_TRACEME)	GDB：catch syscall ptrace + 戻り値を 1 に設定
タイミングチェック	RDTSC、GetTickCount のループ	ジャンプをパッチするか、タイミングチェックに NOP を挿入
VM 検出	VMware のレジストリ／ファイルをチェック	ベアメタルで実行するか、パッチを適用
文字列の暗号化	読み取り可能な文字列がなく、XOR ループがある	復号ルーチンを見つけ、その後にブレークポイントを設定
制御フローの平坦化	状態機械による switch ディスパッチ	実行をトレースして実際の CFG をマッピング
コードの仮想化	独自の VM インタープリター	VM バイトコードのセマンティクスを分析
自己書き換えコード	WriteProcessMemory、VirtualProtect	書き込み先にブレークポイントを設定

自動化のための Ghidra スクリプト：

// Ghidra script: find all XOR loops (common string decryption)
FunctionManager fm = currentProgram.getFunctionManager();
for (Function f : fm.getFunctions(true)) {
    // Analyze function for XOR instructions
    // Flag functions with XOR + loop patterns
}

6. CTF バイナリチャレンジ

ユーザーが CTF チャレンジ（pwn／rev カテゴリー）に取り組んでいる場合：

CTF の初期トリアージ：

# Check protections
checksec --file=./challenge

# Find win functions, hidden strings
strings ./challenge | grep -i "flag\|win\|cat\|/bin"
objdump -d ./challenge | grep -A2 "win\|backdoor\|system"

# Run with strace to see syscalls
strace ./challenge < /dev/null 2>&1 | head -50

# Dynamic analysis with pwndbg
gdb ./challenge
# In GDB:
# info functions       → list all functions
# disas main           → disassemble main
# b *0x401234          → breakpoint at address
# r < input.txt        → run with input

よくある CTF のパターン：

• gets() ／境界チェックのない scanf("%s") → スタックバッファオーバーフロー
• フォーマット文字列を指定しない printf(user_input) → フォーマット文字列脆弱性
• strcmp(input, flag) → タイミング攻撃または直接比較
• 鍵を使った独自の暗号 → 鍵を見つけ、XOR で復号
• VM ベースのチャレンジ → バイトコードの実行をトレースしてフラグのチェック箇所を特定

---

出力基準

バイナリを分析する際、Claude は次の内容を出力します。

• ファイルの概要：種類、アーキテクチャ、セキュリティ機能
• 関数一覧：主要な関数とその目的
• 注釈付き逆アセンブリ：行ごとの説明
• 脆弱性評価：コード内で見つかったセキュリティ上の問題
• 疑似コードの再構成：アセンブリに相当する高水準のコード

---

スクリプトリファレンス

binary_analyzer.py

# Full static analysis
python scripts/binary_analyzer.py --file suspicious.elf --output analysis.json

# Extract strings and imports only
python scripts/binary_analyzer.py --file malware.exe --strings --imports

# Entropy analysis (detect packing/encryption)
python scripts/binary_analyzer.py --file firmware.bin --entropy

---

スキル連携

条件	関連スキル
サンプルに動的な振る舞いの分析が必要	→ スキル 05（マルウェア分析）
脆弱性を発見 → エクスプロイトを開発	→ スキル 03（エクスプロイト開発）
分析から IOC を抽出	→ スキル 06（脅威ハンティング）
発見事項から検出機能を作成	→ スキル 15（ブルーチーム防御）

---

参考資料

• Ghidra 公式ドキュメント
• radare2 ブック
• Intel x86-64 ソフトウェア開発者マニュアル
• ARM アーキテクチャリファレンスマニュアル
• ELF 仕様（Linux Foundation）
• PE フォーマットリファレンス（Microsoft）
• Binwalk ドキュメント
• pwndbg ドキュメント

---

v3.0 の強化点（2026年アップデート）

より高速で高機能なリバースエンジニアリングのワークフロー：

• AI 支援による逆コンパイル — Claude を使って Ghidra／IDA の逆コンパイラー出力に注釈を付けます。変数名の変更、構造体の復元、関数の目的の推定、制御フローの要約が可能です。AI による命名は確定事項ではなく、検証すべき仮説として扱ってください。
• Ghidra のヘッドレス自動化 — 後処理スクリプトを使って一括解析（analyzeHeadless）をスクリプト化し、バイナリ間の IOC や文字列を抽出します。
• エミュレーション優先のトリアージ — Qiling／Unicorn でスニペットを実行し、フルデバッガーを使わずに動的な文字列や設定を解決します。CTF 形式のロジックを記号的に探索するには angr を使います。
• Go／Rust／Nim のバイナリ — ストリップ済みの最新バイナリが主流であるため、言語固有の復元手法を適用します（Go：gopclntab による関数／文字列の復元、Rust：名前のデマングル、panic 文字列を手掛かりとした分析）。
• eBPF とカーネルオブジェクト — ステルス用途で使われる eBPF バイトコードとカーネルモジュールを識別します。
• ファームウェア — binwalk で抽出し、ファイルシステムをマウントしてから、FirmAE／QEMU でエミュレートします。ハードコードされた認証情報、アップデートの仕組み、暗号鍵を特定します。

精度に関するルール： オフセットを再現できるように、すべての解析でロードアドレス／ベースアドレス、アーキテクチャ、呼び出し規約、コンパイラー／ツールチェーンを記録してください。