宜博 / pixelphone

第二次尝试（spawn 后立即 resume，隔 0.8s 再 attach）连 hook 都没装成功
（frida 自身 JVMTI attach 报 access violation），但微信依然被搞挂（这次
表现为界面卡死而非"无法连接服务器"）。两次事故一次 hook 装成功一次没装成功，
排除了"hook 代码本身有 bug"，说明是"往微信主进程冷启动过程里做 frida
attach"这个动作本身在这台设备这个微信版本上就不安全，不是时序调参能解决的。

建议：不再对主进程做任何 frida spawn/attach 变体；appbrand 子进程的
spawn-gating hook 依然安全可复用；退回半自动方案（人工点发布）性价比
明显更高。

多轮真机验证过程：
- frida -W 三开会撞车崩溃目标进程（一次只开一个）
- frida -W 只逮第一个匹配 spawn，改写 multi_spawn_hook.py 用
  enable_spawn_gating()+on('spawn-added') 逐个处理
- session.create_script() 原生 Python binding 不像 CLI 自动 bundle
  frida-java-bridge，需 frida-compile 预编译（*_bundled.js）
- 反编译代码确认 k2/y7（小程序侧）和 webview/luggage/jsapi（WebView 侧）
  都汇聚到同一个 sink：Ljs1/m;->c(TransferRequestInfo, callback)，大概率
  跑在微信主进程而非 appbrand 子进程
- spawn_mm_and_hook.py 尝试 force-stop+spawn 主进程挂钩子，导致微信"无法
  连接服务器"，force-stop 后手动重开恢复正常——确认主进程冷启动期间注入
  有风险，不同于此前 appbrand 子进程的安全操作

详细过程记录见 BRANDSERVICE_PUBLISH_RESEARCH.md §3。