-
验证了当前真机 Tinker 补丁（patch-83069b25，2026-07-12，含 libapp.so 确认贴图号 Flutter 功能是热更新下发的）里的 BizPublishApi/lx.m5 跟 base.apk 反编译内容完全一致，排除"反编译资产过期"这个猜测。 用 jadx 读了 BizPublishApi$Companion.setUp() 完整分发逻辑：11 个 Pigeon BasicMessageChannel 直接调用对应方法，无代理/反射，hook 位置 技术上完全正确。两轮真机验证零触发的唯一合理解释：Dart 侧压根没为 "贴图号+单图+短文字"这个简化流程发送这条消息——这套 Pigeon 桥接更 可能服务于另一个更复杂的发布场景（完整公众号图文），跟当前测的路径 无关，这条线大概率是死胡同。 记录了三个待选的下一步方向（精确时间线比对 js1.m.c() 洪流 / hook WCDB 写库回溯调用栈 / 接受半自动方案），留待下次接手。
-
用户提议直接读源码而非继续 hook 排除法，引出两条新调查线： 1. 小程序运行时 JS 缓存（jscache 目录，非加密 wxapkg，已解出但是微信 自己的编译字节码）——strings 扫出完整模块树，确认 utils/massSend/ massSend.js 是实际提交逻辑所在，但字节码格式读不出具体调用参数。 2. 按"类名含 Publish"批量搜索，发现 com.tencent.pigeon.biz.BizPublishApi ——Pigeon 是 Flutter 官方 native↔Dart 桥接代码生成器，证实"我的作品" 入口（BizMyWorksFlutterViewActivity）是真 Flutter 页面，跟原生通信 走一条完全独立于此前四条候选的 IPC 机制，解释了为什么 js1.m/m11.l0/ wxartrappsvr/v70.w 全部落空。 找到实现类 Llx/m5，hook 了 notifyBizPublishResult()/openUrl()（含新观察 到的独立进程 com.tencent.mm:hotpot..，疑似"我的作品"专用 Flutter 隔离进程）。两轮真机验证：hook 全部安装成功，但零触发，发布依旧真实 成功。这是今天第二次"反编译读到的类看起来对，装上却零触发"（第一次是 JsApiOpenBizPublishImage 主类被 R8 优化到连文件都找不到）。 关键教训：~/wechat_apk/decompiled 是历史某个时间点的 dump，可能已经 跟当前真机在跑的版本对不上（Kotlin/R8 生成的短类名对小版本更新敏感）。 下次要精确 hook 前应重新 dump 当前 base.apk，而不是复用旧反编译资产。
-
加了 hookGenericImgCdnSubmit 被动观察 v70.w.oj()（普通消息发图真正 CDN 上传入口，已在 wechat-image-send-internals.md 逆向过），测试贴图号 提交是否复用这条通道。真机确认：全程零触发，发布依旧真实成功 （chksm 变化），第四个假说证伪。 至此 js1.m.c()/bizh5webtransfer、m11.l0.d1()、wxartrappsvr/route、 v70.w.oj() 四条最合理候选全部用真机数据排除。hookAnyCgiCapture 已是 全局通用观察点，纯靠猜类名排除法收益递减，建议下次改查小程序沙箱 自身 JS bridge 层（wx.uploadFile/wx.request 的 native 实现，appbrand 包下，全新方向）。 顺带记录一个流程坑：设备中途自己息屏落锁，wm dismiss-keyguard 对有 密码锁的设备无效，需要用户物理解锁，不能也不该尝试绕过。
-
改用 adb input tap + screencap 自主驱动"我的作品→贴图号→发表"全流程， 不再需要用户手动操作，缩短每轮迭代成本。真机验证坑：可折叠机 screencap 默认拿错屏幕，需显式 -d <display-id>。 给 hookAnyCgiCapture 加了 r45.zt5（wxartrappsvr/route）专属 dump—— 之前通用扁平字段扫描器看不到它的 LinkedList<re7> payload，误判成 "无内容"。真机确认这条路全是小程序 SDK 埋点上报（页面性能/console log 转发/事件上报），跟提交发布无关，第三个候选证伪。 意外发现：图片编辑步骤本身是个独立小程序（appid wx0b2ec076ec39c786， page_path pages/image_editor/image_editor），此前一直当作纯 H5 webview——这是下次调查该跟进的新方向。核心提交调用仍未定位。
-
改用文字/图片/语音发送同一套 LSPosed 机制（Zygote fork 时挂钩，非 Frida spawn/attach），彻底避开了此前两次搞坏微信主进程的问题——全程真机验证零 故障。 追踪链路 js1.m.c()(brandservice/webview transfer 汇聚点) → wire cgi bizh5webtransfer，真机确认全程只有只读态 mp.weixin.qq.com 调用，没有 提交语义。进一步反编译 LuggageUploadMediaFileManager 追出图片走独立 CDN 服务 m11.l0.d1()，同样零触发。两个最有希望的候选均被真机数据证伪，真正 的提交调用点仍未定位，可能是完全独立的第三条路径。 三个新增 hook（hookBrandservicePublishTransfer/hookAnyCgiCapture/ hookBrandserviceCdnUpload）均已装进 WeChatHook.java，base+Tinker CL 全覆盖，可复用于下一轮排查。
-
第二次尝试（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 抓包日志（调试用，跟本次逆向工作 共用同一台设备）。