re-lldb

lldb による動的デバッグ（macOS/iOS）

使用する場合／使用しない場合

• 使用：macOS/iOS ターゲットの動的デバッグ（attach／起動／ブレークポイント／式の評価／シンボル検索）
• 使用：Linux 上で DWARF 付きのデバッグビルドをデバッグする場合（lldb は clang ツールチェーンと同じソースから構築され、DWARF の処理が成熟しています）
• 使用しない：Linux ターゲット（[[re-gdb]]）、Windows ターゲット（[[re-x64dbg]]）
• 使用しない：iOS の脱獄／証明書環境の問題（[[re-mobile]] の領域）；メモリの読み取りのみ（[[re-memdump]] はデフォルトでダンプを優先）
• 使用しない：スクリプトによる大規模なメモリダンプ／フォレンジック（[[re-memdump]]／[[re-mem-forensics]] のほうが適しています）

ツールの準備

[[re-analyze/platform-tips]] の macOS の項を参照してください。SIP と TCC の制限により attach が制限されるため、Developer Tools の許可が必要です。

lldb

• macOS：標準搭載（Xcode Command Line Tools：xcode-select --install）
• Linux：apt install lldb／dnf install lldb／pacman -S lldb
• macOS でより完全な環境：brew install llvm（新しい lldb を含みます）
• 確認：lldb --version
• バージョンの違い：Xcode に付属する lldb、llvm.org の lldb、Swift ツールチェーンの lldb は機能がほぼ同じですが、バージョン番号は異なります（lldb --version で確認してください）。スクリプトが lldb.SBDebugger API に依存する場合、バージョン間の互換性を確認する必要があります（[[gotchas]] を参照）

SIP の無効化または許可（attach の前提条件）

• システム設定 > プライバシーとセキュリティ > デベロッパーツール > lldb を使用するターミナルを許可（TCC の許可）
• 旧システム：sudo DevToolsSecurity -enable
• 説明：通常は SIP を無効にしないでください（デバッグ上の必要に応じて一時的に対処できます）。iOS のカーネルレベルのデバッグには KDK／開発用カーネルが必要で、[[re-mobile]] の領域です

操作手順

1. Developer Tools の権限を確認：

   lldb -p <测试进程pid>   # 若报 "please check the developer mode" / 权限拒绝 → 去系统设置授权终端
   

   許可した後、ターミナルを再起動してください。それでも失敗する場合は、SIP の状態を確認します：csrutil status。 注意：TCC の許可ダイアログはシステム設定で手動確認する必要があり、コマンドラインから回避することはできません。

2. attach／起動：

   (lldb) process attach --pid <pid>     # 附加
   (lldb) process attach --name Safari   # 按名字附加（需唯一）
   (lldb) target create ./sample         # 或直接启动
   (lldb) run --args arg1
   (lldb) continue / c
   

   iOS デバイス：platform select remote-ios + process connect connect://<device>（デバッグサービスとの併用が必要です。脱獄／証明書の要件は [[re-mobile]] を参照）

   • attach のタイミングに注意してください：ターゲットですでに初期化処理が実行されていると、エントリーポイント前の動作は確認できません。エントリーポイントから確認するには、target create + run で起動してください
   • エントリーポイントで起動を停止：process launch --stop-at-entry（-s と同等）

3. image lookup でシンボルを検索：

   (lldb) image lookup -n main            # 按名字查符号
   (lldb) image lookup -a $pc             # 按地址查当前所在函数/源行
   (lldb) image list                      # 已加载镜像（dylib 基址表）
   (lldb) image lookup -rn dispatch       # 正则匹配符号
   

   stripped バイナリでは image lookup -a でアドレスが属するモジュールを逆引きし、image dump symtab と組み合わせます

   • モジュールのベースアドレス：image list -o のオフセット列を確認します。ASLR により実行のたびにベースアドレスが変わるため、スクリプトでは先にベースアドレスを取得してから絶対アドレスを計算します（[[gotchas]] を参照）

4. メモリ式 expr：

   (lldb) expr $rax
   (lldb) expr $rax = 0                   # 写寄存器
   (lldb) expr (char*)0x100000000         # 类型化读地址
   (lldb) expr -O -- @"hello"             # Objective-C 求值（objc 运行时）
   (lldb) memory read -c 20 -s 4 -f x $rsp     # 读内存（缺 -f x 会报格式冲突错误）
   (lldb) memory write -s 1 0x100000000 0x90  # 写字节（绕过校验）
   

   • 式の評価には副作用があります（コードが実行されます）。機密性の高い経路でむやみに評価しないでください。[[gotchas]] を参照

5. ブレークポイントとスクリプト：

   (lldb) breakpoint set -n main
   (lldb) breakpoint set -a 0x100004000 -c '*(int*)($rsp) == 0x1234'   # 条件断点
   (lldb) breakpoint command add 1
   > frame variable
   > expr $rax
   > continue
   > DONE
   

   Python による自動化：lldb には Python が組み込まれています。script import lldb を実行するか、lldb -s script.lldb でバッチ処理を行います。

   • シンボルブレークポイント：breakpoint set -n objc_msgSend（シンボル名で指定し、モジュールの読み込み後に自動的に有効になります）；正規表現：-r '^check_'
   • ブレークポイントの管理：breakpoint list／breakpoint delete／breakpoint disable 1

6. ステップ実行／スタック／スレッド：

   (lldb) thread step-over / step-into / step-out   # 步过/步入/出函数（别名 next/step/finish）
   (lldb) thread backtrace                          # 当前线程栈（别名 bt）
   (lldb) thread list                               # 全部线程
   (lldb) frame select 1                            # 切栈帧
   (lldb) frame variable                            # 当前帧局部变量
   (lldb) register read                             # 全部寄存器
   

   • 呼び出し後の step-out でステップを飛ばし、戻り値レジスターを確認するのが、「関数の戻り値を検証する」最速の方法です

7. メモリ検索と領域：

   (lldb) memory find 0x100000000 0x101000000 -e 0xdeadbeef   # 区间内搜值/字节串
   (lldb) memory find -s "password" 0x100000000 0x101000000   # 搜字符串
   (lldb) memory region 0x100004000                           # 该地址所属区域权限/边界
   

   • キー／定数を探す場合：まず memory find で位置を特定し、次に書き込み箇所を追跡します。領域の権限（RWX）に異常があるセグメントを優先して確認してください（パッカー／復号セグメント）

8. 証拠の照合（仕上げ）：ブレークポイントのヒット記録、frame variable／expr の出力、memory read のダンプ（memory read --force -o 文件 でエクスポート）を [[re-triage]] の初期調査値と照合して記録し、結論を [[re-analyze/analysis-contract]] に記載します

分野横断の連携

• [[re-binary-core]]：ワークフローの第 6 ステップ（macOS/iOS デバッガー）
• [[re-mobile]]：iOS アプリ／脱獄環境での動的デバッグに使う基盤ツール
• [[re-format-macho]]：構造を解析してからデバッグします（エントリーポイント／LC_MAIN と署名状態）
• attach に失敗した場合は、[[re-analyze/platform-tips]] に従って [[re-memdump]] に切り替えます

よくある落とし穴と注意点

• SIP/TCC による attach の拒否：許可されていないターミナルからの attach は拒否されます（permission denied または無言で失敗）。システム設定のデベロッパーツールで許可してください。SIP の無効化は極端な場合に限ってください
• 許可ダイアログは手動確認が必要：TCC は新しいデバッグ対象ごとにダイアログを表示するため、スクリプトによる attach が停止します。対象プログラムを事前に許可してください
• カーネルデバッグには追加設定が必要：macOS のカーネルデバッグには、バージョンに一致する KDK と開発用カーネルでの起動が必要です。通常のリバースエンジニアリングでは不要なので、ユーザー空間のデバッグに時間を費やさないでください
• 署名状態：変更された Mach-O は再署名しないと実行できません（[[re-format-macho]] を参照）。デバッグの前に codesign -f -s - で再署名してください
• task_for_pid entitlement／SIP／Hardened Runtime の 3 層の制限：症状——Developer Tools を許可しても attach に失敗する、またはターゲットの起動直後にクラッシュする；原因——TCC 以外に 3 層の制限があります。デバッガーには task_for_pid entitlement が必要で、ターゲットで Hardened Runtime が有効な場合はデバッグ API が制限され、SIP はシステムプロセスへの attach を制限します；対策——各層を順に確認します（csrutil status、ターゲットの署名と entitlement を確認）。テスト対象では、まず署名を解除するか再署名して（[[re-format-macho]]）からデバッグしてください。[[re-analyze/platform-tips]] の macOS の項を参照してください
• ASLR によるベースアドレスの変動：起動のたびに dylib のベースアドレスが異なります。スクリプトでアドレスをハードコードすると機能しなくなります。image list -o でベースアドレスを取得して換算し、ブレークポイントはできるだけシンボル名（-n／-s）で設定してください
• 式の評価による副作用：expr は実際にコードを実行します（関数呼び出し／メモリ変更）。フックポイントで評価するとターゲットの動作が変わる可能性があるため、検証では読み取り専用の frame variable を優先してください
• バージョンの違い、デバッグサーバー、境界については [[gotchas]] を参照してください