reverse-engineering-firmware-analysis

---

ライブラリ優先プロトコル（必須）

コードを書く前に、必ず次の項目を確認してください。

ステップ 1：ライブラリカタログ

• 場所：.claude/library/catalog.json
• 一致率が 70% を超える場合：再利用または適用してください

ステップ 2：パターンガイド

• 場所：.claude/docs/inventories/LIBRARY-PATTERNS-GUIDE.md
• パターンが存在する場合：記載された方法に従ってください

ステップ 3：既存のプロジェクト

• 場所：D:\Projects\*
• 見つかった場合：抽出して適用してください

判断基準

一致度	対応
ライブラリが 90% 超	そのまま再利用
ライブラリが 70～90%	最小限の変更で適用
パターンが存在する	パターンに従う
プロジェクト内に存在する	抽出する
一致するものがない	構築する（後からライブラリに追加）

---

このスキルを使用する場合

マルウェアサンプルを分析する場合、セキュリティ研究のためにバイナリをリバースエンジニアリングする場合、脆弱性評価を実施する場合、不審なファイルから IOC を抽出する場合、サプライチェーンセキュリティのためにソフトウェアを検証する場合、または CTF の課題やバイナリ悪用の研究を行う場合に、このスキルを使用してください。

このスキルを使用しない場合

商用ソフトウェアを許可なくリバースエンジニアリングする場合、本番システム上のバイナリを分析する場合、法的な許可なくソフトウェアをリバースエンジニアリングする場合、利用規約や EULA に違反する場合、または隔離環境の外でマルウェアを分析する場合には、このスキルを使用しないでください。単純な文字列抽出には使用せず、基本的なツールを使用してください。

成功基準

• セキュリティ上重要な挙動（ネットワーク、ファイル、レジストリ、プロセスのアクティビティ）がすべて特定されている
• 悪意のある指標（IOC、C2 ドメイン、暗号鍵）が信頼度スコア付きで抽出されている
• 該当する場合、CVE とのマッピングを含めて脆弱性が記録されている
• サンドボックス環境（スナップショットを取得した VM／コンテナ）内で分析が完了している
• 複数の分析手法（静的＋動的＋シンボリック）で調査結果が検証されている
• 完全な IOC レポート（脅威インテリジェンス共有用の STIX／MISP 形式）が生成されている
• 脆弱性評価における誤検知がゼロである
• 脆弱性研究の場合、エクスプロイトの概念実証が作成されている

エッジケースと課題

• 解析妨害技術（デバッガー検出、VM 検出、タイミングチェック）
• 展開が必要な難読化またはパックされたバイナリ
• 暗号化されたペイロードを持つ多段階マルウェア
• 専門的な分析が必要なカーネルモードのルートキット
• シンボリック実行における状態爆発（10,000 パス超）
• 複雑なプログラムでのバイナリ分析のタイムアウト（24 時間超）
• 正規のソフトウェアの挙動による誤検知
• SSL インターセプトが必要な暗号化ネットワークトラフィック

ガードレール（重要なセキュリティルール）

• ホストシステム上で未知のバイナリを実行しないでください（隔離された VM／サンドボックス内でのみ実行してください）
• 適切な封じ込めなしにマルウェアを分析しないでください（エアギャップされたラボを推奨）
• 法的な許可なくソフトウェアをリバースエンジニアリングしないでください
• 抽出した認証情報や暗号鍵を公開しないでください
• 許可のない使用を目的としてライセンス機構を回避しないでください
• ネットワーク監視を備えたサンドボックス環境を必ず使用してください
• 不審なバイナリを実行する前に、必ず VM のスナップショットを取得してください
• 複数の分析手法で必ず調査結果を検証してください
• タイムスタンプ付きで分析手法を必ず記録してください
• 安全であることが証明されるまで、バイナリは悪意があるものと必ず想定してください
• マルウェアの通信を防ぐため、必ずネットワークを隔離してください
• IOC を共有する前に必ずサニタイズしてください（内部 IP アドレスを伏せてください）

エビデンスに基づく検証

リバースエンジニアリングで得られたすべての調査結果は、次の方法で必ず検証してください。

1. 複数手法による分析 - 静的解析＋動的解析＋シンボリック実行で同じ挙動を確認する
2. サンドボックスでの検証 - 隔離された環境で実行し、すべてのアクティビティを記録する
3. ネットワーク監視 - パケットキャプチャでネットワークに基づく調査結果を検証する
4. メモリフォレンジック - メモリダンプを通じて実行時のシークレットを検証する
5. 挙動の相関分析 - 既知のマルウェアシグネチャ（YARA、ClamAV）と照合する
6. 再現性 - 2人目のアナリストが分析成果物から調査結果を再現できる

リバースエンジニアリング：ファームウェア分析

このスキルでできること

IoT デバイス、ルーター、組み込みシステムからファームウェアを抽出して分析します。

• 抽出（30 分～2 時間）：binwalk を使用して SquashFS/JFFS2/CramFS ファイルシステムを抽出します
• サービス分析（1～3 時間）：init スクリプト、デーモン、ネットワークリスナーを特定します
• 脆弱性評価（1～3 時間）：ハードコードされた認証情報、CVE、インジェクションポイントを見つけます
• バイナリ分析（1～2 時間）：抽出したバイナリにレベル 1～4 を適用します

所要時間の目安：合計 2～8 時間

---

前提条件

ツール

• binwalk - ファームウェアの抽出（binwalk -Me firmware.bin）
• unsquashfs - SquashFS の抽出
• file - ファイルの種類の特定
• QEMU（任意）- 抽出したバイナリのエミュレーション
• Jefferson（任意）- JFFS2 の抽出
• strings - ファームウェアの文字列分析

MCP サーバー

• filesystem - 抽出したファームウェア内を移動
• security-manager - CVE スキャン
• connascence-analyzer - コード品質分析
• memory-mcp - 調査結果の保存
• sequential-thinking - バイナリ分析の判断ゲート

---

⚠️ 重大なセキュリティ警告

ホストシステム上でファームウェアのバイナリや抽出したファイルを絶対に実行しないでください！

ファームウェアの抽出、バイナリの実行、エミュレーションはすべて、以下の環境で実施する必要があります。

• 隔離された VM（ネットワークを隔離し、スナップショットを設定した VMware/VirtualBox）
• 厳格なセキュリティポリシーを適用し、ホストのファイルシステムにアクセスできない Docker コンテナー
• E2B サンドボックス（sandbox-configurator スキルを使用し、実行を監視）
• ファームウェア分析環境（-snapshot を指定した QEMU、firmadyne サンドボックス）

安全でない実行による影響：

• バックドアのインストールと永続的なネットワークアクセス
• 関連デバイスを危険にさらす、ハードコードされた認証情報の抽出
• 開発インフラへのマルウェアの拡散
• IoT ボットネットへの取り込み（Mirai、Hajime の亜種）
• クラウド API キーやサービスの侵害

安全な運用方法：

• ネットワークアクセスのない隔離されたコンテナー内でファームウェアを抽出します
• スナップショットモード（-snapshot フラグ）で QEMU エミュレーションを使用します
• エミュレートしたデバイスを本番ネットワークに絶対に接続しないでください
• 抽出した認証情報の検証は、隔離された環境内でのみ行います
• ファームウェアのエミュレーション中は、すべてのネットワーク接続を監視します
• すべての IoT ファームウェアを、侵害されている可能性があるものとして扱います
• 抽出したファイルシステムは読み取り専用でマウントします

---

クイックスタート

# 1. Full firmware analysis
/re:firmware router-firmware.bin

# 2. Extract filesystem only
/re:firmware iot-device.img --extract-only

# 3. Analyze extracted services
/re:firmware camera-fw.bin --analyze-services true

# 4. Extract + analyze specific binary
/re:firmware router.bin --analyze-binary /usr/sbin/httpd

---

フェーズ 1：ファームウェアの特定（5～10 分）

ステップ 1：基本的なファイル分析

# Identify file type
file firmware.bin

# Expected output examples:
# - "firmware.bin: u-boot legacy uImage, MIPS OpenWrt Linux-4.14.63"
# - "firmware.bin: data" (encrypted or compressed)
# - "firmware.bin: Flattened device tree blob (DTB)"

ステップ 2：エントロピー分析

ファームウェアが暗号化または圧縮されているか確認します。

# Entropy analysis
binwalk --entropy firmware.bin

# Output visualization:
# High entropy throughout (> 0.9): Likely encrypted
# Low entropy with peaks: Normal firmware with compressed sections
# Uniform low entropy (< 0.5): Uncompressed firmware

判定：

• エントロピー 0.9～1.0：暗号化されたファームウェア（復号キーが必要）
• エントロピー 0.6～0.8：圧縮されたセクション（通常）
• エントロピー 0.3～0.5：非圧縮データ

ステップ 3：コンポーネントの特定

# Identify firmware components
binwalk --signature firmware.bin

# Expected output:
# DECIMAL       HEXADECIMAL     DESCRIPTION
# --------------------------------------------------------------------------------
# 0             0x0             uImage header, header size: 64 bytes
# 64            0x40            LZMA compressed data
# 1048576       0x100000        Squashfs filesystem, little endian
# 15728640      0xF00000        JFFS2 filesystem, little endian

コンポーネント：

• ブートローダー：u-boot、Das U-Boot
• カーネル：Linux カーネル（LZMA/gzip で圧縮）
• ルートファイルシステム：SquashFS、JFFS2、CramFS、UBIFS
• 設定：永続データ用の JFFS2 パーティション

---

フェーズ 2：ファイルシステムの抽出（30 分～2 時間）

ステップ 1：自動抽出

# Extract all filesystem components automatically
binwalk --extract --matryoshka firmware.bin

# --extract (-e): Extract identified components
# --matryoshka (-M): Recursively scan extracted files

# Output directory structure:
# _firmware.bin.extracted/
# ├── 0.lzma              # Compressed kernel
# ├── 100000.squashfs     # Root filesystem
# ├── squashfs-root/      # Extracted root filesystem
# └── jffs2-root/         # Extracted configuration partition

ステップ 2：抽出結果の確認

# Navigate to extracted filesystem
cd _firmware.bin.extracted/squashfs-root/

# Verify critical directories exist
ls -la

# Expected structure:
# drwxr-xr-x  bin/        # Binaries
# drwxr-xr-x  etc/        # Configuration files
# drwxr-xr-x  lib/        # Shared libraries
# drwxr-xr-x  usr/        # User programs
# drwxr-xr-x  www/        # Web interface
# drwxr-xr-x  sbin/       # System binaries

ステップ 3：手動抽出（自動抽出に失敗した場合）

SquashFS の場合：

# Find SquashFS offset from binwalk
binwalk firmware.bin | grep -i squashfs
# Output: 1048576       0x100000        Squashfs filesystem

# Extract from offset
dd if=firmware.bin bs=1 skip=1048576 of=squashfs.img

# Unsquash manually
unsquashfs -dest ./squashfs-root squashfs.img

# Verify
ls ./squashfs-root/

JFFS2 の場合：

# Install jefferson (JFFS2 extractor)
pip install jefferson

# Extract JFFS2
jefferson jffs2.img --dest ./jffs2-root

# Or use firmware-mod-kit
extract-firmware.sh firmware.bin

CramFS の場合：

# Install cramfs tools
sudo apt install cramfsprogs

# Mount (requires root)
sudo mount -t cramfs -o loop cramfs.img /mnt/cramfs

# Or extract
cramfsck -x ./cramfs-root cramfs.img

ステップ 4：暗号化されたファームウェアへの対処

# Check entropy
binwalk --entropy firmware.bin

# If high entropy (encrypted):
# 1. Search for decryption keys in vendor documentation
# 2. Check for known encryption schemes (AES, 3DES, RSA)
# 3. Use firmware-mod-kit or binwalk plugins for known devices

# Example: TP-Link firmware decryption
tplink-safeloader -d firmware.bin -o decrypted.bin

# Example: D-Link firmware decryption
binwalk -e --dd='.*' firmware.bin

---

フェーズ 3：サービスの特定（1～3 時間）

ステップ 1：init システムの特定

# Check for init scripts
ls ./squashfs-root/etc/init.d/

# Common init systems:
# - init.d/ scripts (SysVinit)
# - rc.d/ scripts (BSD-style init)
# - systemd/ units (systemd)
# - procd/ configs (OpenWrt procd)

ステップ 2：起動サービスの分析

# OpenWrt/procd example
cat ./squashfs-root/etc/rc.d/*

# SysVinit example
cat ./squashfs-root/etc/init.d/rcS

# Example output:
# #!/bin/sh
# /usr/sbin/telnetd -l /bin/sh
# /usr/sbin/httpd -p 80 -h /www
# /usr/sbin/dropbear -p 22

特定する主なサービス：

• telnetd：Telnet サーバー（ポート 23）
• httpd：ウェブサーバー（ポート 80/443）
• dropbear/sshd：SSH サーバー（ポート 22）
• ftpd：FTP サーバー（ポート 21）
• upnpd：UPnP デーモン
• dnsmasq：DNS/DHCP サーバー

ステップ 3：ネットワークリスナーの特定

# Search for network binding code
grep -r "0.0.0.0" ./squashfs-root/etc/
grep -r "bind(" ./squashfs-root/usr/sbin/ 2>/dev/null
grep -r "listen(" ./squashfs-root/usr/sbin/ 2>/dev/null

# Search for port numbers
grep -rE ":[0-9]{2,5}" ./squashfs-root/etc/ | grep -E "(80|443|23|22|21)"

# Example findings:
# ./squashfs-root/etc/config/uhttpd:  option listen_http '0.0.0.0:80'
# ./squashfs-root/etc/config/dropbear: option Port '22'
# ./squashfs-root/etc/inetd.conf:telnet stream tcp nowait root /usr/sbin/telnetd

ステップ 4：CGI スクリプトとウェブインターフェースの特定

# Find web root
ls ./squashfs-root/www/
ls ./squashfs-root/usr/www/

# Find CGI scripts (potential injection points)
find ./squashfs-root/www/ -name "*.cgi" -o -name "*.sh"

# Example CGI scripts:
# ./squashfs-root/www/cgi-bin/login.cgi
# ./squashfs-root/www/cgi-bin/admin.cgi
# ./squashfs-root/www/cgi-bin/status.sh

# Analyze for command injection
grep -E "(system|popen|exec)" ./squashfs-root/www/cgi-bin/*.cgi

出力の概要：

Network Services Detected:
- telnetd on 0.0.0.0:23 (CRITICAL: Unauthenticated shell access)
- httpd on 0.0.0.0:80 (Web interface)
- dropbear on 0.0.0.0:22 (SSH with password auth)
- upnpd on 0.0.0.0:1900 (UPnP potential SSRF)

CGI Scripts Found:
- /cgi-bin/admin.cgi (Command injection vulnerable)
- /cgi-bin/login.cgi (Credential check)
- /cgi-bin/upgrade.cgi (Firmware upload)

---

フェーズ 4：認証情報の探索（30 分～1 時間）

ステップ 1：Shadow ファイルと Passwd ファイルを確認する

# Unix password files
cat ./squashfs-root/etc/passwd
cat ./squashfs-root/etc/shadow

# Example vulnerable shadow file:
# root:$1$12345678$abcdefghijklmnopqrstuv:0:0:root:/root:/bin/sh
# admin:admin:0:0:admin:/root:/bin/sh  # CRITICAL: Plaintext password!

よくある問題：

• 空のパスワードハッシュ（パスワードなしでログイン可能）
• 弱いパスワード／デフォルトのパスワード（admin/admin）
• ハードコードされたハッシュ（解読可能）

ステップ 2：設定ファイルを検索する

# Search for common password keywords
grep -ri "password" ./squashfs-root/etc/ 2>/dev/null
grep -ri "passwd" ./squashfs-root/etc/ 2>/dev/null
grep -ri "pwd" ./squashfs-root/etc/ 2>/dev/null
grep -ri "secret" ./squashfs-root/etc/ 2>/dev/null

# Example findings:
# ./etc/config/wireless: option key 'default_wifi_password_12345'
# ./etc/shadow: root:5up:0:0:root:/root:/bin/sh
# ./etc/config/system: option admin_password 'admin'

ステップ 3：API キーとトークンを探す

# Search for long alphanumeric strings (API keys)
grep -rE "[A-Za-z0-9]{32,}" ./squashfs-root/etc/config/

# Search for common API key patterns
grep -ri "api_key\|token\|secret_key" ./squashfs-root/etc/

# Search for cloud service credentials
grep -ri "aws\|azure\|gcp\|s3" ./squashfs-root/etc/

# Example findings:
# ./etc/cloud-config.json: "api_key": "sk_live_abcdef1234567890"
# ./etc/mqtt.conf: mqtt_token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."

ステップ 4：SSL 証明書と秘密鍵を抽出する

# Find SSL certificates
find ./squashfs-root/ -name "*.pem" -o -name "*.key" -o -name "*.crt"

# Example findings:
# ./etc/ssl/private/server.key (CRITICAL: Private key embedded)
# ./etc/ssl/certs/ca.crt

# Check for weak/default keys
openssl rsa -in ./etc/ssl/private/server.key -text -noout

# If key is weak (512-bit RSA), flag as critical

認証情報の概要：

Hardcoded Credentials Found:
- Root password: "5up" (plaintext in /etc/shadow)
- Admin password: "admin" (default credentials)
- WiFi password: "default_wifi_password_12345" (weak)
- API key: "sk_live_abcdef..." (exposed in /etc/cloud-config.json)
- SSL private key: /etc/ssl/private/server.key (512-bit RSA, weak)

---

フェーズ 5：脆弱性スキャン（1～3 時間）

ステップ 1：ライブラリのバージョンを特定する

# Find shared libraries
ls ./squashfs-root/lib/
ls ./squashfs-root/usr/lib/

# Check library versions
strings ./squashfs-root/lib/libc.so.0 | grep -i version

# Example output:
# OpenSSL 1.0.1e (VULNERABLE: Heartbleed CVE-2014-0160)
# BusyBox v1.24.1 (CHECK: Known CVEs)
# Dropbear 2014.63 (CHECK: Known CVEs)

ステップ 2：MCP による CVE スキャン

# Use security-manager MCP for automated CVE scanning
/re:firmware router.bin --cve-scan true

内部の仕組み：

// Automatically invoked by skill
const cveResults = await mcp__security-manager__scan_vulnerabilities({
  filesystem_root: "./squashfs-root/",
  library_scan: true,
  cve_database: "nvd",  // National Vulnerability Database
  check_versions: true
})

// Example output:
// {
//   "vulnerabilities": [
//     {
//       "cve": "CVE-2014-0160",
//       "severity": "CRITICAL",
//       "component": "OpenSSL 1.0.1e",
//       "description": "Heartbleed vulnerability allows memory disclosure",
//       "cvss": 7.5
//     },
//     {
//       "cve": "CVE-2019-12345",
//       "severity": "HIGH",
//       "component": "httpd CGI handler",
//       "description": "Command injection via admin.cgi parameter",
//       "cvss": 8.8
//     }
//   ]
// }

ステップ 3：手動で脆弱性を評価する

コマンドインジェクションを確認する：

# Analyze CGI scripts for command injection
grep -E "(system|exec|popen|shell_exec)" ./squashfs-root/www/cgi-bin/*.cgi

# Example vulnerable code in admin.cgi:
# system("ping -c 1 " . $QUERY_STRING);  # CRITICAL: Command injection!

SQL インジェクションを確認する：

# Find database queries
grep -rE "(SELECT|INSERT|UPDATE|DELETE)" ./squashfs-root/www/

# Example vulnerable query:
# $query = "SELECT * FROM users WHERE username='" . $_GET['user'] . "'";

パストラバーサルを確認する：

# Find file operations
grep -rE "(fopen|readfile|include)" ./squashfs-root/www/

# Example vulnerable code:
# readfile("/www/" . $_GET['file']);  # Path traversal: ?file=../etc/shadow

ステップ 4：バックドアを確認する

# Search for suspicious listening ports
grep -rE "port.*[0-9]{4,5}" ./squashfs-root/etc/

# Search for reverse shell code
grep -rE "(nc.*-e|bash.*>&|/dev/tcp)" ./squashfs-root/

# Search for hidden services
find ./squashfs-root/ -name ".*" -type f

# Check for suspicious cron jobs
cat ./squashfs-root/etc/crontabs/*

脆弱性レポート：

CRITICAL Vulnerabilities:
1. CVE-2014-0160 (Heartbleed) - OpenSSL 1.0.1e
2. Command Injection - admin.cgi (unauthenticated)
3. Hardcoded credentials - root:5up

HIGH Vulnerabilities:
4. Path Traversal - download.cgi
5. Weak SSL certificate - 512-bit RSA key
6. Telnet enabled on 0.0.0.0:23 (no authentication)

MEDIUM Vulnerabilities:
7. Default credentials - admin:admin
8. UPnP enabled (SSRF potential)
9. SQL Injection - login.cgi

---

フェーズ 6：バイナリ解析（1～2 時間）

ファームウェアを抽出した後、注目すべきバイナリにレベル 1～4 を適用します。

ステップ 1：対象のバイナリを特定する

# Web server binary
ls ./squashfs-root/usr/sbin/httpd

# Telnet daemon
ls ./squashfs-root/usr/sbin/telnetd

# Custom binaries
find ./squashfs-root/usr/bin/ -type f -executable

ステップ 2：レベル 1（文字列解析）を適用する

# Analyze web server strings
/re:strings ./squashfs-root/usr/sbin/httpd

# Look for:
# - Hardcoded URLs (C2 servers, update servers)
# - Debug messages revealing logic
# - Version strings
# - Hardcoded credentials

出力例：

Strings Found in httpd:
- "admin:5up" (hardcoded credential)
- "http://firmware-updates.vendor.com/check" (update URL)
- "DEBUG: Command executed: %s" (command injection point)
- "OpenSSL/1.0.1e" (vulnerable version)

ステップ 3：レベル 2（静的解析）を適用する

# Disassemble httpd binary
/re:static ./squashfs-root/usr/sbin/httpd --tool ghidra

# Find critical functions:
# - handle_cgi_request()
# - authenticate_user()
# - execute_command()

逆コンパイルされたコードの例（Ghidra の出力）：

// Function: handle_admin_cgi
void handle_admin_cgi(char *query_string) {
  char command[256];
  char *cmd_param;

  // VULNERABILITY: No input validation!
  cmd_param = get_param(query_string, "cmd");
  sprintf(command, "sh -c '%s'", cmd_param);
  system(command);  // CRITICAL: Command injection!
}

ステップ 4：レベル 3（動的解析）を適用する - 任意

# Emulate binary with QEMU
qemu-mipsel-static ./squashfs-root/usr/sbin/httpd

# Or use full system emulation with firmadyne
firmadyne.sh router-firmware.bin

# Debug with GDB
gdb-multiarch ./squashfs-root/usr/sbin/httpd
(gdb) set architecture mips
(gdb) break handle_admin_cgi
(gdb) run

ステップ 5：レベル 4（シンボリック実行）を適用する - 上級

# Use Angr for symbolic analysis
/re:symbolic ./squashfs-root/usr/sbin/httpd \
  --target-addr 0x401234 \  # execute_command function
  --input-symbolic cmd_param \
  --find-exploits true

---

包括的なワークフローの例

ワークフロー 1：ルーターのファームウェアを完全に解析する

シナリオ：TP-Link ルーターのファームウェアを解析して脆弱性を探します

ステップ 1：抽出（30 分）

# Download firmware
wget http://vendor.com/TL-WR841N-v14-firmware.bin

# Identify and extract
binwalk -E TL-WR841N-v14-firmware.bin  # Check entropy
binwalk -Me TL-WR841N-v14-firmware.bin # Extract

# Navigate to filesystem
cd _TL-WR841N-v14-firmware.bin.extracted/squashfs-root/

ステップ 2：サービスの検出（1 時間）

# Find init scripts
cat etc/rc.d/S*

# Services found:
# - telnetd on 0.0.0.0:23 (CRITICAL)
# - httpd on 0.0.0.0:80
# - dnsmasq on 0.0.0.0:53

# Map CGI scripts
find www/ -name "*.cgi"

# CGI scripts found:
# - www/cgi-bin/admin.cgi (admin interface)
# - www/cgi-bin/upgrade.cgi (firmware upload)

ステップ 3：認証情報の探索（15 分）

# Check shadow file
cat etc/shadow
# Output: admin:5up:0:0:admin:/root:/bin/sh

# Check config files
grep -ri "password" etc/config/
# Output: option admin_password 'admin'

# CRITICAL: Default credentials admin:5up

ステップ 4：CVE スキャン（30 分）

# Check library versions
strings lib/libc.so.0 | grep version
# OpenSSL 1.0.1e (CVE-2014-0160 Heartbleed)

# Automated CVE scan
/re:firmware TL-WR841N-v14-firmware.bin --cve-scan true

# Results:
# - CVE-2014-0160 (CRITICAL): Heartbleed
# - CVE-2019-12345 (HIGH): Command injection in admin.cgi

ステップ 5：バイナリ解析（1 時間）

# Analyze admin CGI
/re:strings www/cgi-bin/admin.cgi
# Found: "system(sh -c %s)" - command injection

# Static analysis
/re:static www/cgi-bin/admin.cgi --tool ghidra

# Decompiled code shows:
# char *cmd = getenv("QUERY_STRING");
# system(cmd);  # CRITICAL: No sanitization!

最終レポート：

TP-Link TL-WR841N Firmware Analysis
====================================

CRITICAL Vulnerabilities:
1. Hardcoded credentials: admin:5up
2. Unauthenticated telnet on port 23
3. Command injection in admin.cgi
4. Heartbleed (CVE-2014-0160) in OpenSSL 1.0.1e

HIGH Vulnerabilities:
5. Weak default WiFi password
6. No CSRF protection on admin interface

Attack Scenario:
1. Telnet to router (no password required)
2. Or exploit command injection: http://router/cgi-bin/admin.cgi?cmd=reboot
3. Gain root shell access

Recommendation: Update to patched firmware version

所要時間：合計 3.25 時間

---

ワークフロー 2：IoT カメラのファームウェアセキュリティ監査

シナリオ：Wyze カメラのファームウェアを監査してクラウド API のセキュリティを確認します

ステップ 1：抽出（45 分）

# Extract firmware
binwalk --extract --matryoshka wyze-cam-v3-firmware.bin

# Filesystem type: UBIFS (NAND flash filesystem)
# Manual extraction required
jefferson ubifs.img --dest ./wyze-root/

ステップ 2：サービスの検出（1.5 時間）

# Find cloud service configuration
grep -ri "api\|cloud\|server" ./wyze-root/etc/

# Found:
# ./etc/cloud-config.json:
# {
#   "api_endpoint": "https://api.wyze.com/v1",
#   "device_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
#   "api_key": "sk_live_abcdef1234567890"
# }

# CRITICAL: Hardcoded API credentials!

ステップ 3：クラウド通信を解析する（1 時間）

# Find MQTT broker configuration
cat ./wyze-root/etc/mqtt.conf

# Broker: mqtt.wyze.com:8883
# Username: camera-12345
# Password: hardcoded_mqtt_pass

# Analyze cloud binary
/re:strings ./wyze-root/usr/bin/cloud-agent

# Found:
# - "Bearer eyJhbGci..." (hardcoded auth token)
# - "https://firmware-updates.wyze.com/" (update URL)

ステップ 4：CVE スキャン（30 分）

# Check libraries
ls ./wyze-root/lib/

# Found vulnerable libraries:
# - libssl.so.1.0.0 (CVE-2014-0160 Heartbleed)
# - libcurl.so.4 (CVE-2020-8231 Remote code execution)

ステップ 5：クラウドエージェントのバイナリ解析（1 時間）

# Static analysis
/re:static ./wyze-root/usr/bin/cloud-agent --tool ghidra

# Decompiled authentication function:
void cloud_authenticate() {
  char *token = "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
  char *api_key = "sk_live_abcdef1234567890";

  http_request("POST", "https://api.wyze.com/v1/auth",
               headers=["Authorization: Bearer " + token]);
}

# CRITICAL: All cameras use same API key!

最終レポート：

Wyze Cam v3 Firmware Security Audit
====================================

CRITICAL Vulnerabilities:
1. Hardcoded API credentials shared across all devices
2. Hardcoded JWT token for cloud authentication
3. MQTT credentials in plaintext
4. CVE-2014-0160 (Heartbleed)
5. CVE-2020-8231 (libcurl RCE)

Attack Scenario:
1. Extract API key from firmware
2. Authenticate to Wyze cloud API
3. Access all cameras using same API key
4. Stream/download video from any camera

Impact: Complete compromise of all Wyze cameras using this firmware

Recommendation:
- Implement per-device API keys
- Remove hardcoded credentials
- Update vulnerable libraries

所要時間：合計 4.75 時間

---

ワークフロー 3：スマートサーモスタットのファームウェア - デバッグインターフェースを探す

シナリオ：Nest に似たサーモスタットを解析し、隠されたデバッグインターフェースを探します

ステップ 1：抽出（1 時間）

# Encrypted firmware (high entropy)
binwalk --entropy thermostat-firmware.bin
# Entropy: 0.95 (encrypted)

# Search for decryption keys in vendor SDK
find ./vendor-sdk/ -name "*.key" -o -name "*aes*"

# Found: encryption_key.bin
# Decrypt firmware
openssl enc -d -aes-256-cbc -in thermostat-firmware.bin \
  -out decrypted.bin -K $(cat encryption_key.bin)

# Extract decrypted firmware
binwalk --extract --matryoshka decrypted.bin

ステップ 2：デバッグインターフェースを探す（30 分）

# Search for UART/serial references
grep -ri "uart\|serial\|console" ./squashfs-root/etc/

# Found:
# ./etc/inittab: ttyS0::respawn:/bin/sh  # UART console!

# Search for debug commands
grep -ri "debug\|test\|diag" ./squashfs-root/usr/bin/

# Found debug binary
ls ./squashfs-root/usr/bin/debug-shell

ステップ 3：デバッグシェルを解析する（1 時間）

# String analysis of debug shell
/re:strings ./squashfs-root/usr/bin/debug-shell

# Found:
# - "Enter admin password:" (authentication required)
# - "Debug mode enabled"
# - "dump_nvram" (NVRAM dumping command)
# - "factory_reset"

# Static analysis
/re:static ./squashfs-root/usr/bin/debug-shell --tool ghidra

# Decompiled password check:
bool check_debug_password(char *input) {
  char *correct_password = "DebugMode2023";  // Hardcoded!
  return strcmp(input, correct_password) == 0;
}

ステップ 4：デバッグインターフェースをテストする（30 分）

# Emulate debug shell
qemu-arm-static ./squashfs-root/usr/bin/debug-shell

# Connect to UART console
screen /dev/ttyUSB0 115200

# Enter debug password: DebugMode2023
# Access granted!

# Available debug commands:
# - dump_nvram (dumps all settings including WiFi password)
# - factory_reset (wipes device)
# - enable_telnet (enables telnet on port 23)

最終レポート：

Smart Thermostat Debug Interface Analysis
==========================================

CRITICAL Findings:
1. UART console enabled with debug shell access
2. Hardcoded debug password: "DebugMode2023"
3. Debug commands allow full device control
4. NVRAM dump reveals WiFi credentials

Attack Scenario:
1. Open device and connect to UART pins
2. Boot device and access serial console
3. Launch debug-shell
4. Enter password "DebugMode2023"
5. Execute dump_nvram to extract WiFi password
6. Execute enable_telnet for remote access

Impact: Physical access to device = full compromise

Recommendation:
- Disable debug interfaces in production firmware
- Use unique per-device debug passwords
- Implement secure boot to prevent firmware modifications

所要時間：合計 3 時間

---

高度なオプション

カスタム抽出対象

# Extract specific filesystem only
/re:firmware router.bin --extract-filesystem squashfs --skip-analysis

# Extract and analyze specific binary
/re:firmware router.bin --analyze-binary /usr/sbin/httpd --level 2

# Extract configuration partition only
/re:firmware router.bin --extract-jffs2-only

複数ファームウェアの解析

# Compare multiple firmware versions
/re:firmware router-v1.bin --output ./v1-analysis/
/re:firmware router-v2.bin --output ./v2-analysis/

# Diff analysis
diff -r ./v1-analysis/squashfs-root/ ./v2-analysis/squashfs-root/

# Find newly introduced binaries
diff <(ls ./v1-analysis/squashfs-root/usr/bin/) \
     <(ls ./v2-analysis/squashfs-root/usr/bin/)

ファームウェアの自動エミュレーション

# Use firmadyne for full system emulation
git clone https://github.com/firmadyne/firmadyne
cd firmadyne

# Setup database
./download.sh

# Emulate firmware
./scripts/inferNetwork.sh router-firmware.bin
./scripts/makeImage.sh router-firmware.bin

# Access emulated device
http://192.168.1.1  # Default gateway
telnet 192.168.1.1 23  # Telnet access

---

トラブルシューティング

問題 1：暗号化されたファームウェア

症状：エントロピーが高い（>0.9）。binwalk でファイルシステムが見つからない

原因：ファームウェアが暗号化されています

解決策 1：復号鍵を探す

# Search vendor SDK for keys
find ./vendor-sdk/ -name "*.key" -o -name "*aes*" -o -name "*decrypt*"

# Common key locations:
# - vendor-sdk/tools/encryption_key.bin
# - vendor-docs/firmware-encryption.txt
# - GPL source code archives

解決策 2：既知の暗号化方式を確認する

# TP-Link uses custom encryption
tplink-safeloader -d firmware.bin -o decrypted.bin

# D-Link uses AES-256-CBC with known IV
openssl enc -d -aes-256-cbc -in firmware.bin -out decrypted.bin \
  -K <known_key> -iv <known_iv>

解決策 3：ブートローダーをリバースエンジニアリングする

# Extract bootloader (usually at offset 0)
dd if=firmware.bin bs=1 count=65536 of=bootloader.bin

# Analyze bootloader for decryption routine
/re:static bootloader.bin --tool ghidra

# Look for AES/DES crypto initialization

---

問題 2：ファイルシステムを抽出できない

症状：binwalk による抽出が失敗する、またはファイルが破損する

原因：標準以外のファイルシステム形式または圧縮方式が使われています

解決策 1：別のツールを使って手動で抽出する

# SquashFS variants
unsquashfs -d ./output squashfs.img                # Standard
unsquashfs-lzma -d ./output squashfs.img          # LZMA compressed
jefferson ./output squashfs.img                    # Alternative tool

# JFFS2
jefferson jffs2.img -d ./output

# UBIFS
ubireader_extract_images -o ./output firmware.bin

# CramFS
cramfsck -x ./output cramfs.img

解決策 2：firmware-mod-kit を使う

# Firmware mod kit supports many formats
git clone https://github.com/rampageX/firmware-mod-kit
cd firmware-mod-kit/src
./configure && make

# Extract
./extract-firmware.sh ../firmware.bin

# Filesystem extracted to ./fmk/rootfs/

解決策 3：手動でカービングする

# Find filesystem magic bytes
binwalk firmware.bin

# Example: SquashFS at offset 0x100000 (1048576)
# Magic: 68 73 71 73 (hsqs)

# Extract from offset to end
dd if=firmware.bin bs=1 skip=1048576 of=filesystem.img

# Try unsquash
unsquashfs filesystem.img

---

問題 3：バイナリを実行できない（アーキテクチャの不一致）

症状：抽出したバイナリを実行すると「Exec format error」が発生する

原因：バイナリが別のアーキテクチャ（MIPS、ARM など）向けにコンパイルされています

解決策 1：アーキテクチャを特定し、適切な QEMU を使う

# Identify architecture
file ./squashfs-root/usr/sbin/httpd

# Example outputs:
# - "ELF 32-bit LSB executable, MIPS" → Use qemu-mipsel-static
# - "ELF 32-bit LSB executable, ARM" → Use qemu-arm-static
# - "ELF 64-bit LSB executable, ARM aarch64" → Use qemu-aarch64-static

# Run with appropriate QEMU
qemu-mipsel-static ./squashfs-root/usr/sbin/httpd

# Or with chroot
sudo chroot ./squashfs-root qemu-mipsel-static /usr/sbin/httpd

解決策 2：QEMU でシステム全体をエミュレートする

# Create QEMU disk image
qemu-img create -f qcow2 firmware.qcow2 1G

# Boot with QEMU
qemu-system-mips -M malta -kernel vmlinux -hda firmware.qcow2 \
  -append "root=/dev/sda1 console=ttyS0" -nographic

# Or use firmadyne (automated)
firmadyne.sh firmware.bin

解決策 3：QEMU のユーザーモードエミュレーションを使って Docker を利用する

# Docker with multi-arch support
docker run --rm -it --platform linux/arm/v7 \
  -v $(pwd)/squashfs-root:/firmware \
  arm32v7/ubuntu:20.04 bash

# Inside container
cd /firmware
./usr/sbin/httpd

---

課題 4：CVE スキャンで脆弱性が見つからない

症状：自動スキャンで既知の脆弱性が検出されません

原因：バージョン文字列が CVE データベースの形式と一致していません

解決策 1：バージョンを手動で確認する

# Extract version strings
strings ./squashfs-root/lib/libssl.so.1.0.0 | grep -i version

# Output: "OpenSSL 1.0.1e 11 Feb 2013"

# Manually check CVE database
# CVE-2014-0160 affects OpenSSL 1.0.1 - 1.0.1f
# Result: VULNERABLE

解決策 2：複数の CVE スキャナーを使用する

# Use cve-bin-tool
cve-bin-tool ./squashfs-root/

# Use grype
grype dir:./squashfs-root/

# Use trivy
trivy fs ./squashfs-root/

解決策 3：カスタムシグネチャの照合

# Create custom CVE rules
cat > custom-cve-rules.txt <<EOF
OpenSSL 1.0.1[a-f]: CVE-2014-0160 (Heartbleed)
BusyBox 1.2[0-4]: CVE-2021-28831 (Command injection)
Dropbear 201[0-6]: CVE-2016-7406 (Format string)
EOF

# Scan with custom rules
grep -f custom-cve-rules.txt <(find ./squashfs-root/ -exec strings {} \; 2>/dev/null)

---

課題 5：ハードコードされた認証情報が見つからない

症状：認証情報が存在するはずなのに、grep 検索でパスワードが見つかりません

原因：認証情報がエンコードまたは暗号化されているか、バイナリ形式で保存されています

解決策 1：エンコードされた文字列を検索する

# Base64 encoded credentials
find ./squashfs-root/ -type f -exec grep -l "YWRtaW46YWRtaW4=" {} \;
# (base64 decode: admin:admin)

# Hex encoded
grep -rE "61646d696e" ./squashfs-root/etc/
# (hex decode: admin)

# URL encoded
grep -rE "%61%64%6d%69%6e" ./squashfs-root/

解決策 2：バイナリとデータベースを検索する

# SQLite databases
find ./squashfs-root/ -name "*.db" -o -name "*.sqlite"
sqlite3 ./etc/config.db "SELECT * FROM users;"

# Binary config files
strings ./squashfs-root/etc/config.bin | grep -i "password\|admin"

解決策 3：認証用バイナリをリバースエンジニアリングする

# Analyze login binary
/re:static ./squashfs-root/usr/bin/login --tool ghidra

# Decompiled code often reveals credential check:
# if (strcmp(input, "hardcoded_password") == 0) { ... }

---

パフォーマンスの最適化

抽出を高速化する

# Parallel extraction (if multiple partitions)
binwalk -e partition1.bin &
binwalk -e partition2.bin &
wait

# Use faster decompression
unsquashfs -p 4 squashfs.img  # 4 parallel threads

サービスの検出を高速化する

# Parallel grep searches
grep -r "telnetd" ./squashfs-root/etc/ &
grep -r "httpd" ./squashfs-root/etc/ &
grep -r "sshd" ./squashfs-root/etc/ &
wait

CVE スキャンを最適化する

# Skip common false positives
mcp__security-manager__scan_vulnerabilities({
  filesystem_root: "./squashfs-root/",
  skip_binaries: ["busybox", "dropbear"],  # Manually verified
  only_critical: true  # Only report CRITICAL and HIGH
})

---

Memory-MCP との統合

ファームウェア分析の保存

// After firmware extraction completes
mcp__memory-mcp__memory_store({
  content: {
    firmware_hash: "sha256:abc123...",
    device_info: {
      vendor: "TP-Link",
      model: "TL-WR841N",
      version: "v14",
      arch: "MIPS"
    },
    filesystem: {
      type: "squashfs",
      extracted_files: 1247,
      total_size_mb: 8.5
    },
    services: [
      {name: "telnetd", port: 23, auth: false, severity: "CRITICAL"},
      {name: "httpd", port: 80, auth: true, severity: "MEDIUM"},
      {name: "dropbear", port: 22, auth: true, severity: "LOW"}
    ],
    credentials: [
      {type: "root", user: "root", pass: "5up", location: "/etc/shadow"},
      {type: "admin", user: "admin", pass: "admin", location: "/etc/config/system"}
    ],
    vulnerabilities: [
      {cve: "CVE-2014-0160", severity: "CRITICAL", component: "OpenSSL 1.0.1e"},
      {cve: "CVE-2019-12345", severity: "HIGH", component: "httpd command injection"}
    ],
    attack_surface: [
      "Unauthenticated telnet on 0.0.0.0:23",
      "Command injection in /cgi-bin/admin.cgi",
      "Path traversal in /cgi-bin/download.cgi"
    ],
    binary_analysis: {
      analyzed: ["/usr/sbin/httpd", "/www/cgi-bin/admin.cgi"],
      findings: "Command injection confirmed in admin.cgi"
    }
  },
  metadata: {
    agent: "RE-Firmware-Analyst",
    category: "reverse-engineering",
    intent: "firmware-analysis",
    layer: "long_term",
    project: `firmware-analysis-${date}`,
    keywords: ["firmware", "iot", "router", "embedded"],
    re_level: 5,
    firmware_hash: "sha256:abc123...",
    timestamp: new Date().toISOString()
  }
})

---

エージェントとコマンド

呼び出されるエージェント

1. RE-Firmware-Analyst（レベル 5）

   • 専門分野：ファームウェアの抽出と IoT セキュリティ分析
   • ツール：binwalk、unsquashfs、jefferson、firmadyne、QEMU
   • 出力：抽出したファイルシステム、サービスマップ、認証情報リスト、CVE レポート

2. RE-String-Analyst（レベル 1、抽出したバイナリ向け）

   • IOC 抽出のため、抽出したバイナリに適用します

3. RE-Disassembly-Expert（レベル 2、抽出したバイナリ向け）

   • 脆弱性分析のため、抽出したバイナリに適用します

4. security-manager（自動）

   • 抽出したライブラリの CVE スキャンを実行します

スラッシュコマンド

• /re:firmware <firmware> - レベル 5 の完全な分析（このスキルの主要コマンド）
• /re:strings <binary> - 抽出したバイナリに適用します
• /re:static <binary> - 抽出したバイナリに適用します

MCP サーバー

• filesystem：抽出したファームウェアのディレクトリを操作します
• security-manager：CVE スキャンを自動で実行します
• connascence-analyzer：抽出したコードのコード品質を分析します
• memory-mcp：ファームウェア分析情報をセッション間で保持します
• sequential-thinking：バイナリ分析を段階的に進めるための判断ゲート

---

関連スキル

• リバースエンジニアリング：クイックトリアージ - レベル 1～2（抽出したバイナリに適用）
• リバースエンジニアリング：詳細分析 - レベル 3～4（抽出したバイナリに適用）
• コードレビューアシスタント - 抽出したソースコードをレビューします
• Security Manager - 包括的な脆弱性スキャン

---

リソース

外部ツール

• binwalk - ファームウェアの抽出
• firmware-mod-kit - ファームウェアの変更ツールキット
• firmadyne - ファームウェアのエミュレーション
• QEMU - CPU エミュレーター
• jefferson - JFFS2 ファイルシステムの抽出ツール

学習リソース

• ファームウェア分析ガイド - 包括的なガイド
• IoT セキュリティハンドブック - IoT セキュリティのベストプラクティス
• binwalk 使用ガイド - binwalk のドキュメント

コミュニティ

• r/ReverseEngineering - サブレディット
• IoT Village - DEF CON の IoT セキュリティ研究
• ファームウェアセキュリティ研究 - ブログとリソース

---

作成日：2025-11-01 RE レベル：5（ファームウェア分析） 所要時間：2～8 時間 カテゴリ：IoT セキュリティ、組み込みシステム、ファームウェアのリバースエンジニアリング 難易度：上級

基本原則

リバースエンジニアリング：ファームウェア分析は、3 つの基本原則に基づいています。

原則 1：階層的な抽出戦略

ファームウェアには、段階的な抽出が必要となる複数の入れ子状のコンポーネント（ブートローダー、カーネル、ファイルシステム、設定）が含まれています。

実践方法：

• 抽出を試みる前に、binwalk のエントロピー解析を使用して暗号化を検出します
• ファイルシステムを再帰的に抽出し（matryoshka モード）、入れ子になったアーカイブに対応します
• シグネチャスキャン（SquashFS、JFFS2、UBIFS のマジックバイト）でコンポーネントの境界を特定します
• 自動抽出に失敗した場合は、dd を使用して手動でデータを切り出します

原則 2：攻撃対象領域のマッピング

IoT デバイスは、ネットワークサービス、ウェブインターフェース、ハードコードされた認証情報を通じて攻撃対象領域を露出します。

実践方法：

• init スクリプトからすべてのネットワークリスナー（telnetd、httpd、UPnP デーモン）をマッピングします
• CGI スクリプトを解析し、コマンドインジェクションやパストラバーサルの脆弱性を探します
• shadow ファイル、設定データベース、バイナリ文字列から認証情報を抽出します
• サプライチェーン攻撃のベクトルとなり得るファームウェア更新の仕組みを文書化します

原則 3：コンポーネント間の相関分析

脆弱性は、複数のファームウェアコンポーネント（ウェブインターフェース＋バイナリデーモン＋カーネルモジュール）にまたがることがよくあります。

実践方法：

• CGI スクリプトの脆弱性とバックエンドのバイナリ解析結果を相関させます
• ハードコードされた認証情報をサービスの認証メカニズムに関連付けます
• 共有ライブラリ（OpenSSL、BusyBox、Dropbear）全体で CVE を検証します
• 抽出した実行ファイルに Level 1-4 のバイナリ解析を適用します

---

よくあるアンチパターン

アンチパターン	問題	解決策
ホスト上でファームウェアのバイナリを実行する	アーキテクチャの不一致（MIPS/ARM）、潜在的なバックドア、システムの侵害	QEMU のユーザーモードエミュレーション、または firmadyne を使用したフルシステムエミュレーションを使用します
暗号化されたファームウェアを無視する	解析が不完全になり、脆弱性を見落とし、誤った安心感を招きます	ベンダー SDK から復号鍵を探し、ブートローダーの暗号ルーチンをリバースエンジニアリングし、既知のデバイス復号方式を確認します
サービスの検出を省略する	ネットワークに露出した攻撃対象領域（認証不要の telnet、脆弱な CGI）を見落とします	init スクリプトを解析し、bind/listen 呼び出しを grep で検索し、ネットワークリスナーをバイナリに対応付けます
抽出結果を検証しない	ファイルシステムの破損、ファイルの欠落、解析の不完全さにつながります	重要なディレクトリ（/bin、/etc、/lib、/www）が存在することを確認し、ファイル数が想定と一致するか確認します
認証情報をそのまま公開する	法的責任、関連デバイスの侵害、顧客のプライバシー侵害につながります	内部 IP を伏せ、IOC を公開する前に認証情報をサニタイズし、安全な情報開示チャネルを使用します

---

結論

リバースエンジニアリング：ファームウェア解析は、世界中に展開されている数十億台の IoT デバイスや組み込みデバイスのセキュリティ態勢を理解するための入り口です。ファイルシステムを体系的に抽出し、ネットワークサービスをマッピングし、ハードコードされた認証情報を探し、CVE をスキャンすることで、このスキルは IoT デバイスがボットネットへの取り込みやサプライチェーン攻撃の格好の標的となる原因である重大な脆弱性を明らかにします。

このスキルの価値は、個々のデバイスの解析にとどまりません。同じファームウェアベースを共有する製品ライン全体に調査結果を適用できます。デフォルトパスワードやコマンドインジェクションの脆弱性を一つ抽出するだけで、数千台のデバイスが侵害される可能性があります。抽出した実行ファイルへの Level 1-4 のバイナリ解析と組み合わせることで、このスキルはブートローダーからアプリケーション層まで、包括的なセキュリティ評価を可能にします。

導入前のルーターファームウェアの解析、プライバシー上の懸念に関するスマートホームデバイスの監査、組み込みシステムの脆弱性調査を行う際に、このスキルを使用してください。所要時間を 2-8 時間に区切ることで、対象を絞ったセキュリティ監査にも、大規模な IoT セキュリティ研究プログラムにも適しています。memory-mcp との連携により、ファームウェアを横断した相関分析を行い、ベンダー間に共通する脆弱性を特定できるため、大規模な IoT セキュリティ研究を加速できます。