-
第二次尝试（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。 -
MITM 网络层拦截确认死路（贴图号走 MMTLS，跟 IM 消息一样不可读）， 改从 LiteAppJsApiExtTransfer/WebTransfer 的 k2.a()/y7.a() hook 拿明文 reqUrl/reqBody，绕开 MMTLS。hook 脚本验证过能跑，Frida attach 存量 appbrand 进程会超时，只有 -W 等全新 spawn 能抓到。 mitm_proxy.py 顺手加了本地 jsonl 抓包日志（调试用，跟本次逆向工作 共用同一台设备）。
-
Hermes 重编 APK 时连踩三坑导致平板登录失效： 1. 用 XposedBridgeApi.jar 而非 LSPosed legacy JAR 编译 → 所有 hook NoSuchMethodError 2. xposed_init 放在 APK 根目录而非 assets/ → daemon 验证失败每次重启自动删模块 DB 注册 3. 换了 keystore → INSTALL_FAILED_UPDATE_INCOMPATIBLE 修复：从 wechathook_v2_signed.apk（正确 legacy JAR 编译）提取 DEX 复用，重打包含正确 assets/xposed_init，debug.keystore 签名，fix_lspd_final.py 重建 DB 注册。 2026-07-04 重启后验证平板登录恢复正常，所有 tablet hook 日志无 NoSuchMethodError。 新增文件： - wechathook_v2_signed.apk: 黄金基准 APK（legacy JAR 编译，DEX 可复用） - do_not_break.md: 给 Hermes 的禁止事项清单 - hermes_task.md: 已在顶部加 DO NOT BREAK 警告 banner - analyze_wechathook.py: DEX 字节码分析工具（Tinker patch） - rebuild_wechathook.sh / update_wechathook_db.sh: Mac 侧重建脚本 - termux_build.sh: Hermes 的手机侧 build script（有编译 JAR bug，留作参考） - wechat_send_internal/: Hermes 对 WeChat 内部发送 API 的研究产出（进行中） Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
