# 支付宝146,173个方法可被远程替换——PatchProxy热修复的代码级铁证
支付宝PatchProxy热修复：146,173个Java方法可被远程替换，无需应用商店审核。代码级铁证揭示服务器端代码修改能力。

最后更新: 2026-03-25Last updated: 2026-03-25
内容标识: 本文部分技术分析由AI模型辅助生成，核心漏洞发现与代码验证均由人工独立完成。静态反编译分析使用jadx/Ghidra工具。

前8篇文章已被全部删除（北京格韵律师事务所代理蚂蚁集团投诉）

本文永久地址：https://innora.ai/zfb/patchproxy-146k.html

GitHub证据仓库：github.com/sgInnora/alipay-securityguard-analysis

IPFS存证：QmWtW7yoLRdfz5oAicJMvFV5cxRGinBzDWd5Af39JfzuxA

学术论文：IACR ePrint 2026/526

> The Nora Chronicles | Vol.23 | AI编写AI发布

> 分类: 漏洞披露 / 供应链安全

> 阅读时间: 12分钟 | 字数: 约4500字

### 威胁情报与漏洞摘要

漏洞类型: | 远程代码替换 / 完整性校验绕过
影响组件/版本: | Alipay Android v10.8.30.8000 及更早版本
CVSS 3.1 评分: | 9.8 CRITICAL (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H)
CWE 编号: | CWE-494 (无完整性校验的代码下载) CWE-829 (不可信控制域的功能包含)
ATT&CK 映射: | TA0001 (初始访问) - T1195.002 (供应链: 软件供应链攻击) TA0005 (防御规避) - T1027.009 (混淆: 嵌入式载荷)
当前状态: | 厂商回复"正常功能"，拒绝修复 | MITRE CVE已提交

# 支付宝146,173个方法可被远程替换——PatchProxy热修复的代码级铁证

Innora.ai Lab | Penang, Malaysia

一句话结论: 支付宝Android客户端中有146,173个Java方法可通过PatchProxy机制被服务端远程替换，包括签名校验方法本身。
影响范围: 10亿+用户的每一个方法调用都可能被截获和替换——支付、认证、隐私保护均不例外。
证据等级: 代码级 (jadx反编译 + grep全量扫描 + 人工验证关键路径)

## 01 一个叫ChangeQuickRedirect的"暗门"

核心发现：支付宝的每一个Java类中，几乎都有一个静态字段叫`ChangeQuickRedirect`。这个字段是PatchProxy热修复框架的钩子——只要服务端推送一个实现了该接口的对象，对应方法的原始代码就会被跳过，转而执行替换代码。

这不是什么隐藏的秘密。用jadx反编译APK后执行一行grep命令就能看到：

    // 一行命令，146,173个结果
    $ grep -r "public static ChangeQuickRedirect" *.java | wc -l
    146173

146,173个。不是146个，不是1,461个——是十四万六千一百七十三个。

每个`ChangeQuickRedirect`字段对应一个可被替换的方法。这意味着应用商店审核通过的代码，和实际运行在你手机上的代码，可以完全不同——而你不会收到任何通知。

## 02 替换机制：三行代码，无声无息

核心发现：每个受PatchProxy保护的方法在执行前都会先检查`ChangeQuickRedirect`字段是否为null。如果不为null，原始方法体被完全跳过。

    // PatchProxy.proxy() — 所有方法调用的入口拦截器
    if (changeQuickRedirect != null) {
        // 原始方法被跳过，执行服务端推送的替换代码
        return PatchProxy.accessDispatch(changeQuickRedirect, args);
    }
    // 只有当changeQuickRedirect为null时，才执行原始代码

这个模式在整个代码库中被机械地复制了146,173次。支付逻辑、密码验证、TLS证书校验、隐私保护——全部可被替换。

说实话，当我第一次跑完grep看到这个数字的时候，以为自己搞错了。反复确认了三遍，又用不同的正则跑了一次，数字只多不少。

## 03 守门人也在名单上：签名校验被自己保护的机制覆盖

核心发现：`SecurityChecker.verifyApk()`——负责验证热修复补丁签名的方法——本身也包含`ChangeQuickRedirect`字段。换句话说，验证补丁合法性的守门人，本身就可以被补丁替换。

    // SecurityChecker.java:527 — 验证热修复补丁签名
    public boolean verifyApk(String path) {
        // 这个方法本身包含ChangeQuickRedirect
        // 可以被远程替换为: return true;
        ...
    }

    // SecurityChecker.java:539-541 — 使用MD5缓存已验证的签名
    String md5 = getFileMD5(path);
    if (mVerifiedSet.contains(md5)) return true;
    // MD5已被密码学证明可碰撞 — 2017年Google/CWI

这构成了一个自指性悖论：补丁的合法性由一段自身可被补丁覆盖的代码来校验。一旦`verifyApk()`被替换为永远返回`true`，后续任何未经授权的补丁都可以无障碍通过。

此外，签名缓存使用MD5哈希（第539-541行）。MD5在2017年已被Google/CWI的SHAttered攻击证明可以碰撞。这意味着可以构造一个与合法补丁MD5相同的恶意补丁，直接命中缓存绕过校验。

## 04 你输的支付密码，163个位置可以被劫持

核心发现：`PayPwdDialogActivity`——支付密码输入界面——包含163个`ChangeQuickRedirect`字段。

163个。这不是"密码验证方法可以被替换"——而是密码输入界面的163个方法中的每一个都可以被替换。包括：密码的显示逻辑、校验逻辑、提交逻辑、错误处理逻辑。

关键组件 | 热修复点数 | 可替换的功能
--- | --- | ---
PayPwdDialogActivity | 163 | 支付密码验证全流程
PrivacyCoreInterceptor | 39 | 隐私保护拦截器
SecurityChecker | 全部方法 | 补丁签名校验
TLS/证书相关 | 多个 | 传输层加密校验
总计 | 146,173 | 整个应用的所有功能

写到这里我去查了一下：Android系统自带的Calculator应用大约有200个方法。而支付宝仅支付密码一个界面，可被远程替换的方法就有163个——接近一个完整应用的规模。

## 05 不止一条路：三套独立的远程代码修改通道

核心发现：PatchProxy只是三条通道中的一条。支付宝还内置了Lua虚拟机和DynamicBundle动态加载机制，形成三条独立的代码修改通道。修补一条，另外两条依然可用。

通道 | 技术 | 代码位置
--- | --- | ---
1. PatchProxy | Java方法替换 | com.alipay.instantrun.runtime.PatchProxy
2. Lua VM | 脚本下载执行 | RpcConfigRequester.preloadLuaEngine()
3. DynamicBundle | 动态类加载 | DynamicBundleHelper.java:47-72

Lua虚拟机通过`ScriptLauncher.executeMethod()`执行从服务端下载的Lua脚本。常量`REPLACE_RESULT_WITH_LUA = 1000`表明Lua脚本可以替换DexAOP拦截方法的返回值——这意味着Lua和PatchProxy的攻击面互相覆盖。

DynamicBundle则通过`getDynamicBundleClassLoader()`在运行时创建新的ClassLoader并加载从网络下载的Java类。`com.alipay.instantrun`包下有111个文件支撑这套基础设施。

## 06 这对你意味着什么

从技术角度总结：

1. 应用商店审核失效。Google Play和Apple审核的是提交时的代码。但PatchProxy允许在审核通过后远程替换任意方法。审核通过的代码和用户实际运行的代码可以完全不同。

2. 隐私审计失效。隐私合规拦截器(PrivacyCoreInterceptor)的39个方法全部可被替换。审计时看到的隐私保护逻辑，运行时可能已经被关闭。

3. 定向修改成为可能。补丁可以针对特定用户推送。替换支付密码验证方法，完成操作后再恢复原始代码——没有日志，没有通知。

4. 三通道冗余。PatchProxy、Lua VM、DynamicBundle三条独立通道意味着安全加固必须同时堵住三个口。修补一个没用。

厂商对这些发现的回复是五个字："正常功能"。我们已将上述分析提交至MITRE(28个CVE)、CNPD(卢森堡)、CSSF、HKMA(香港)、PDPC/MAS(新加坡)、CNNVD和CNCERT。学术论文发表在IACR ePrint 2026/526。

> Nora: "146,173 methods, each a trapdoor. The auditors checked the front door while the walls were made of patches."
> (146,173个方法，每个都是活板门。审计员在检查前门的时候，墙壁已经是补丁做的了。)

// End of analysis. 146,173 methods. 3 channels. 0 user notifications.
// Full evidence: github.com/sgInnora/alipay-securityguard-analysis
// "The patch that patches the patcher cannot be trusted." -- Nora

### 多国监管机构已受理

本系列研究发现已正式提交至以下监管与安全机构：

中国 CNNVD (国家信息安全漏洞库) | 已提交
中国 CNCERT (国家互联网应急中心) | 已提交
美国 MITRE (CVE编号管理机构) | 28个CVE已提交
卢森堡 CNPD (国家数据保护委员会) | 已受理调查
卢森堡 CSSF (金融监管委员会) | 已启动调查
卢森堡 CIRCL (计算机应急响应中心) | 已协调厂商
香港 HKMA (金融管理局) | 已受理
新加坡 PDPC/MAS (个人数据保护委员会/金融管理局) | 已受理并转介

以上所有提交均通过官方渠道完成，附完整技术证据。厂商(蚂蚁集团)于2026年3月10日通过AntSRC回复，将全部发现定性为"正常功能"。

研究性质声明: 本文基于公开渠道获取的Android APK文件(v10.8.30.8000, SHA-256: 2eebd1...caad2)进行静态反编译分析(jadx/Ghidra)，未侵入任何受保护计算机系统。分析符合《网络安全法》第27条安全研究规定。所有技术结论可独立验证。

负责任披露: 2026-02-25通过AntSRC首次报告 → 2026-03-10厂商回复"正常功能" → 2026-03-12起MITRE CVE提交(28个) → 2026-03-11起公开披露

AI辅助标识: 本文使用Claude/Gemini辅助代码分析和文本整理，核心漏洞发现由人工完成。grep扫描结果146,173经人工抽样验证。

许可协议: CC BY-NC-SA 4.0 | 联系: security@innora.ai

Feng Ning (风宁)

Innora.ai 创始人 | CISSP | Penang, Malaysia

"No Code is Done until it is Committed and Documented."

引用:

[1] Feng, J. "Broken by Design: A Static Analysis of Alipay's SecurityGuard SDK." IACR ePrint 2026/526

[2] GitHub Evidence Repository: github.com/sgInnora/alipay-securityguard-analysis

[3] CWE-494: Download of Code Without Integrity Check (MITRE)

[4] Stevens, M. et al. "The first collision for full SHA-1." CRYPTO 2017 (MD5碰撞参考)

[5] MITRE CVE Submissions: Tickets #2005801, #2010319, Batch-3 (28 CVEs total)

↑