前言
最初的需求很简单：想要破解平时自己使用的健身app的会员pro
谁能想到，修改字段本身十分钟搞定，结果因为这个 App 唯一的登录方式是 wx 登录，把我拽进了一场对 wx 跨进程验签机制的深度探索。
一、第一步：改 vipds 很容易
1.1 定位
用 jadx 反编译 APK，按关键字搜索，很快定位到关键类 VIPAuthModule 里的 aesDecrypt 方法。这是一个解密函数，返回的 JSON 字符串里就包含 vipds 字段。
解密返回的 JSON
↓
{ "vipds": 0, "其他字段": "..." }
↓
App 根据 vipds 判定 VIP 状态
1.2 hook 验证
用 frida hook 这个方法，做三件事：
- 拦截返回值
- JSON 解析后把
vipds 改成 9999
- 再序列化回去返回
跑起来一切正常，VIP 功能解锁。
1.3 转向重打包
frida 每次手机启动都要手动注入，根本不能日常用。自然想到：把这个 hook 写死进 APK 里，重打包后永久生效。
于是开始走重打包路线。看似一个朴素的想法，结果就此入坑。
二、重打包后撞上拦路虎：wx 登录
把修改后的 APK 重新签名安装，打开一看——登录页只有一个按钮：wx 登录。
点下去，wx 直接弹窗：
签名校验失败，请检查与开放平台是否一致
2.1 找其他登录方式
App 是 RN 写的，bundle 是普通 JS 没加密，直接搜源码。意外发现登录代码里其实写了好几种登录方式：
- wx 登录
- Apple 登录
- 邮箱密码登录
- 游客登录
- 二维码扫码登录
- 用户名注册
但 UI 上只有 wx 登录的按钮。其他方式要么 iOS 才显示，要么根本没接入按钮。
试着改 bundle 解锁这些隐藏入口：
- 解锁游客登录按钮 → 点击调用
/anonymous_v2，服务端返回错误，接口被禁了
- 解锁注册页面 → 点击调用
/app/username_register，返回 404
- 邮箱登录 → 没账号
结论：这个 App 实际上只接受 wx 登录，其他渠道服务端都关闭了。
2.2 问题升级
要继续往下走，必须解决一个问题：
如何让重签后的 APK 也能通过 wx 的签名校验？
接下来的所有研究都围绕这个问题展开。
三、wx 验签到底发生在哪里
要骗过 wx，先得搞清楚它在哪一步、用什么方式读你 App 的签名。
判断标准很关键：校验发生在哪个进程，决定能不能 hook。
- 在你 App 进程里读 → 可以 hook 替换返回值
- 在 wx 进程里读 → 你 App 里的 hook 完全无效
- 在 system_server 里读 → 连 wx 都管不了
所以下面顺着调用链一层层往下挖。
四、第一层：App 进程内的 SDK 预校验
frida hook Signature.toCharsString 看谁在读签名，调用栈很清晰：
WeChatModule.isWXAppInstalled
→ BaseWXApiImplV10.isWXAppInstalled
→ WXApiImplComm.validateAppSignature
→ Signature.toCharsString()
这是 wx SDK 在你 App 进程里做的。走的是标准的 PackageManager.getPackageInfo 路径。
处理思路
hook IPackageManager$Stub$Proxy.getPackageInfo，对查询自己包名的请求，把返回结果里的 signatures 字段替换成原始签名。
验证
validateAppSignature 返回值变成 true 了。但 wx 登录还是失败。
结论：这层只是 SDK 内部的"预热"校验，不是 wx 真正用来判定身份的环节。继续往下找。
App 调 sendAuthRequest 的时候，会通过 startActivity 启动 wx 的 WXEntryActivity。这个 Intent 里带了一堆 extras：
_mmessage_appPackage = com.xxx.xxx ← 你的包名
_mmessage_content = weixin://sendreq?appid=...
_mmessage_checksum = byte[] ← 看起来是关键
_mmessage_sdkVersion = 638058496
_message_token = ...
_mmessage_checksum 字段很可疑，是不是用签名算的？能不能伪造？
验证 checksum 算法
hook MessageDigest.update，过滤 wx SDK 调用栈，看 MD5 算法的输入到底是什么：
MD5.update 输入: weixin://sendreq?appid=...
MD5.update 输入: 638058496
关键观察：MD5 输入里只有 url 和 sdkVersion 之类的内容，完全没有签名信息。
结论
这个 checksum 是消息完整性校验，防止 Intent 在传递过程中被篡改，跟签名验证毫无关系。伪造它没意义。
继续往下找。
六、第三层：wx 客户端在自己进程里读签名
排除了前两层，唯一的可能就是：wx 客户端拿到 Intent 后，在自己进程里主动去读你 App 的签名。
完整链路推测：
你 App
↓ startActivity 启动 wx 的 WXEntryActivity
↓ Intent 携带 _mmessage_appPackage = "com.xxx.xxx"
wx 客户端进程
↓ 从 Intent 拿到包名
↓ 调 PackageManager.getPackageInfo("com.xxx.xxx")
binder
system_server
↓ 读 /data/app/com.xxx.xxx/base.apk 的签名块
↓ 用 ApkSignatureVerifier 解析
↓ 返回真实签名给 wx
wx 客户端
↓ 计算签名 MD5
↓ 跟开放平台注册的 MD5 对比
↓ 不一致 → 弹窗"签名校验失败"
验证猜想
把 frida 注入 com.tencent.mm 进程，hook 它进程里的 IPackageManager.getPackageInfo，对目标包名的查询结果替换为伪造签名。
登录成功。
证实了真正的验签确实发生在 wx 进程里，跟你 App 进程半毛钱关系没有。
七、那 LSPatch 行不行？
LSPatch 是个无 root 的方案，可以把 hook 模块直接打包进 APK。看起来很诱人。
但本质上 LSPatch 也要重打包重签名。
签名一变，wx 一样拒绝。死循环。
八、整理一下：
整个验签链路，所有可能的干预点：
| 干预点 |
所在进程 |
能否 hook |
实际效果 |
| frida |
健身app |
改vip字段 |
可行 |
| frida |
wx |
篡改读签名内容 |
可行 |
| lsposed |
健身app |
改vip字段 |
可行 |
核心结论： App 进程里做的一切对 wx 验签都无效。要解决签名问题，必须从 wx 进程或系统层面入手。
十、踩坑总结
关键认知：进程边界比想象中重要
跨进程的信任不是从对方那里"问"来的，而是各自独立向系统拿。
- wx 不会问你 App "你签名是啥"，它直接绕过你去问系统
- 改 Intent 内容没用，对方读自己的信任源
只在自己进程里能改的东西，对跨进程信任完全无效。
本文是个人逆向研究笔记，仅用于学习和理解 Android 系统的跨进程信任机制。请勿用于侵犯他人权益的用途。
发表于 2026-5-4 09:12
|
发表于 2026-5-4 13:05
|楼主
分享到朋友圈
