Spawn 与 Attach
Frida 注入目标进程有两个时机：Spawn（进程创建前） 和 Attach（进程已运行后）。选错时机会导致抓不到启动阶段的流量，或注入失败。
两种时机的本质区别
对比
| 维度 | Spawn (-f) | Attach (默认) |
|---|---|---|
| 时机 | App 启动前 | App 已运行 |
| 能否抓启动期流量 | ✅ 能 | ❌ 不能 |
| 目标参数 | 包名 (com.x.y) | 进程名 或 PID |
| 注入稳定性 | 有时启动太快 hook 没就位 | 更稳，进程已稳定 |
| 客户端证书导出 | 必须用 Spawn | 不支持 |
| 适用场景 | 抓初始化/登录流量 | 抓特定操作流量（推荐） |
Spawn 的坑
Spawn 看起来美好，但实战中常遇到问题：
更麻烦的是，有些 App（如 F-Droid）的联网走 WorkManager 后台任务，Spawn 后并不立即联网，而是排进任务队列延迟执行——这时 Spawn 抓包窗口内可能 0 包。
推荐姿势：Attach + 主动触发
绝大多数逆向场景，Attach 更可控：
对于不主动联网的 App，抓包运行中用 adb input 模拟操作触发流量：
bash
# attach 抓包(后台)
python3 r0capture.py -H 127.0.0.1:27042 7033 -p out.pcap &
# 触发 App 刷新
adb -s 192.168.1.90:5555 shell input swipe 360 500 360 1300 300 # 下拉刷新
adb -s 192.168.1.90:5555 shell input tap 660 90 # 点菜单什么时候必须 Spawn
只有 客户端证书导出 功能必须用 Spawn——因为它要 hook KeyStore 的初始化，那只在 App 启动早期发生一次。详见 客户端证书导出。
下一步：pcap 导出 →