• 改用 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——这是下次调查该跟进的新方向。核心提交调用仍未定位。
    yibo authored
     
    Browse File »
  • 改用文字/图片/语音发送同一套 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
    全覆盖,可复用于下一轮排查。
    yibo authored
     
    Browse File »
  • 第二次尝试(spawn 后立即 resume,隔 0.8s 再 attach)连 hook 都没装成功
    (frida 自身 JVMTI attach 报 access violation),但微信依然被搞挂(这次
    表现为界面卡死而非"无法连接服务器")。两次事故一次 hook 装成功一次没装成功,
    排除了"hook 代码本身有 bug",说明是"往微信主进程冷启动过程里做 frida
    attach"这个动作本身在这台设备这个微信版本上就不安全,不是时序调参能解决的。
    
    建议:不再对主进程做任何 frida spawn/attach 变体;appbrand 子进程的
    spawn-gating hook 依然安全可复用;退回半自动方案(人工点发布)性价比
    明显更高。
    yibo authored
     
    Browse File »
  • 多轮真机验证过程:
    - 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。
    yibo authored
     
    Browse File »
  • MITM 网络层拦截确认死路(贴图号走 MMTLS,跟 IM 消息一样不可读),
    改从 LiteAppJsApiExtTransfer/WebTransfer 的 k2.a()/y7.a() hook 拿明文
    reqUrl/reqBody,绕开 MMTLS。hook 脚本验证过能跑,Frida attach 存量
    appbrand 进程会超时,只有 -W 等全新 spawn 能抓到。
    
    mitm_proxy.py 顺手加了本地 jsonl 抓包日志(调试用,跟本次逆向工作
    共用同一台设备)。
    yibo authored
     
    Browse File »