签名冲突：为什么修补后的微信/支付 App 用不了

为什么 LSPatch 一定会改签名

APK 签名机制（V1/V2/V3/V4）保证 APK 文件自发布后未被修改。LSPatch 改了 Manifest、加了 dex、加了 so——文件肯定变了。所以它自动生成一个新签名，替换原签名块。

这不是 bug，这是补丁方案的天生属性。任何补丁工具（Xpatch、NPatch 等）都一定会改签名。

四种典型的签名相关故障

故障 1：应用商店更新被拒

表现：应用商店提示"签名不匹配，无法安装更新"。

解法：这是 Android 系统机制，无解。只能手动下载新版 APK → 卸载旧修补版 → 修补新版 → 安装。详见 更新后重新修补。

故障 2：应用间通信被拒

表现：修补后的微信无法拉起修补后的 X、修补后的网易云无法分享到修补后的微信。应用之间用签名互相校验，不同签名 = 不信任，直接拒绝。

解法：

• 如果两个 App 都要修补，用同一个签名（CLI 可以指定自定义签名文件）
• 或者只修补其中一个，另一个用原版——这样原版和修补版之间的通信会有问题吗？大概率还是有，因为原版的签名校验可能也卡修补版的签名
• 这类签名是系统级的校验，没有 Root 情况下无解。如果有 Root，可用 CorePatch N 等模块绕过签名校验

故障 3：启动秒退 + 签名校验失败弹窗

表现：应用刚打开就弹一个简短提示（"应用签名异常"、"安全检测未通过"、"检测到应用被修改"）然后退出。

原因：应用自己在代码里做了运行时签名校验（PackageManager.getPackageInfo 取签名摘要和硬编码值比对）。微信、支付宝、招商银行、很多主流游戏都有这个机制。

解法：

1. LSPatch 修补时开「先清除原签名再加新签名」（去签模式 → 清签后再签）
2. 某些魔改应用（比如微信某些破解版）本身就加了绕过签名校验的代码，用那个作为修补起点
3. 没有 Root 的情况下绝大多数场景无解。LSPatch 是在应用进程内 hook，理论上可以 hook PackageManager.getPackageInfo 来篡改返回的签名摘要——但 LSPatch 原版没有内置这个，opatch 某些版本可能有相关设置项

故障 4：应用功能受限

表现：应用能正常打开，但某些功能用不了——比如微信支付、朋友圈、直播、登录等。

原因：应用服务端在运行时校验客户端签名（应用内 ApplicationSigningInfo 上报 + 服务端比对）。这类校验比客户端签名校验更难绕过——因为校验的最终裁决者在服务器那边。

解法：服务端签名校验 → 完全无解。这是应用开发者为了反修改刻意设计的，没有 Root 也没有办法绕过。

CorePatch N 可能的帮助（需要 Root）

如果有 Root 并跑 LSPosed，可以装 CorePatch N 模块——它能绕过：

• 应用降级安装限制
• APK 签名校验
• 某些系统级的完整性检查

但 CorePatch N 本身也有签名，它在 LSPatch 里不一定能用（取决于它的实现方式）。有 Root 的话直接 LSPosed 路线更完整。

务实的边界

以下场景 LSPatch 路线目前（2026 年初）无解，需要换方案或放弃：

签名校验是补丁式框架的天生缺陷，不是 bug。太极·阴（商业版）有专门的防检测机制，对签名校验严格的应用兼容性更好，但需要付费。