feat: global navigation bar + verification badge across all 9 pages

- Unified nav bar with links to all research articles
- Verification badge: Docker 37/37, Zenodo DOI, IACR 2026/526, Packet Storm
- Mobile responsive hamburger menu
- PoC payloads and evidence screenshots added
- Draft articles and planning files included

Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
feng
2026-03-25 05:31:19 +08:00
parent a3825c939f
commit cae3c54867
42 changed files with 3665 additions and 9 deletions

View File

@@ -0,0 +1,242 @@
# 支付宝需要监控你的截屏、蓝牙和通话吗?一次完整的逆向工程分析
> 对支付宝APK (v10.8.30) 208个API拦截点、22个行为监控事件和97%无保护内部接口的代码级分析
**本文永久地址**: https://innora.ai/zfb/privacy-analysis.html
**如果本文被删除,请访问上述地址阅读完整版。**
---
## 引言
当你打开支付宝扫码付款时,你可能不会想到:在你看不到的地方,支付宝正在监控你的截屏行为、剪贴板内容、蓝牙连接、通话状态,甚至你每一次切换页面的精确时间戳。
这不是猜测。这是对支付宝APK文件进行完整逆向工程后从代码中直接提取的事实。
本文所有结论均来自对APK文件的静态反编译分析工具jadx、radare2、Ghidra任何人都可以独立验证。完整分析代码已开源在GitHub。
---
## 一、208个API拦截点
支付宝内部存在一个名为**DexAOP**的字节码级拦截框架(代码路径:`com.alipay.dexaop`包含1606个Java文件。它在编译阶段就将拦截代码注入到Android系统API的调用链中。
我们统计了全部拦截点——**976个代理类 + 180个回调桩 = 覆盖208个API类别**
| 拦截类别 | API数量 | 隐私影响 |
|----------|---------|----------|
| **蓝牙** | 17 | BLE/GATT/A2DP/HID全覆盖 |
| **电话** | 17 | 通话状态、SIM卡、IMEI |
| **网络/HTTP** | 15 | 拦截所有网络请求 |
| **通讯录** | 12 | 完整通讯录访问 |
| **传感器** | 10 | 加速度计、陀螺仪、生物识别 |
| **录音** | 9 | 麦克风全链路拦截 |
| **存储/文件** | 8 | 文件系统读写 |
| **WiFi** | 5 | SSID、BSSID、WiFi扫描 |
| **摄像头** | 5 | Camera + Camera2全部API |
| **剪贴板** | 4 | 你复制的每一段文字 |
| **GPS定位** | 3 | 精确地理位置 |
| **NFC** | 6 | 非接触式支付+卡模拟 |
| **加密操作** | 3 | Cipher/Signature/MAC |
| **其他** | 92 | WebView、存储等 |
| **合计** | **208** | |
### 超出支付安全范畴的拦截
我们理解支付APP需要一些权限来保障交易安全。但以下拦截远远超出了"支付安全"的边界:
- **Camera2 PreviewCallback** — 拦截摄像头的每一帧预览画面。扫码只需要识别结果,为什么要拦截预览帧?
- **RingtoneManager** — 支付APP为什么关心你的铃声设置
- **所有加密操作** — 拦截Java层的`Cipher`(加密)、`Signature`(签名)和`MAC`消息认证意味着APP内任何组件的加密行为都在监控之下
- **14个录音拦截点** — 覆盖麦克风访问的每一个环节,精确记录"录音开始"和"录音结束"时间戳
---
## 二、22个行为监控事件
除了208个API拦截代码中还有一个独立的**行为监控系统**(代码路径:`com.taobao.wireless.security.adapter.datacollection`通过BroadcastReceiver注册了22个监控事件。
**工作机制**APP启动后3秒延迟激活。每个事件被记录为`(事件编号, 时间戳)`格式每积攒10条批量上报服务器事件ID `100184`)。
| 编号 | 监控什么 | 你可能想知道 |
|------|---------|------------|
| 0-1 | 屏幕亮/灭 | 知道你什么时候看手机 |
| 2-3 | APP前/后台 | 知道你什么时候离开支付宝 |
| 4 | 飞行模式 | 检测你是否断网 |
| 5 | 系统时间修改 | 检测你是否改时间 |
| **6** | **截屏** | **知道你截了支付页面的屏** |
| **7** | **录屏** | **知道你是否在录屏** |
| 8-10 | 蓝牙开关/连接/断开 | 追踪你的蓝牙外设 |
| **11** | **通话状态** | **知道你什么时候接/打电话** |
| 12 | 耳机插拔 | 知道你是否戴耳机 |
| **13** | **剪贴板变化** | **你复制的内容被记录** |
| 14 | 网络切换 | WiFi/移动网络变化 |
| 15-21 | Activity生命周期×7 | 精确到每个页面的创建/暂停/销毁 |
### 远程开关
代码中有一个**OrangeConfig远程配置开关**namespace: `securityguard_orange_namespace`key: `132`),默认值`"0"`。服务器可以随时将其设为`"1"`来激活全部22个监控事件。
换句话说:**即使当前没开,服务器一个指令就能全部打开。**
### 截屏监控意味着什么?
当你截屏保存一个转账记录时——也许是为了留证据——支付宝会立即知道。当你打开录屏软件时,支付宝也会立即知道。
问一个直接的问题:**监控用户截屏和录屏,合理的业务场景是什么?** 如果答案是"防止敏感信息泄露",那反过来想:这不正是在阻止用户保留自己的交易证据吗?
---
## 三、29项设备超级指纹
支付宝代码中的`DeviceInfoCapturerFull`类包含一个29项`switch`语句已通过3-LLM交叉验证确认收集
**硬件标识**: IMEI、OAID、WiFi MAC地址、MediaDrm ID
**SIM卡**: 运营商信息、SIM序列号
**系统**: 音频路由、屏幕分辨率、时区、语言
**应用**: 已安装应用签名信息、已授予权限列表
这29项数据被组合生成一个叫**UMID**的跨安装持久化设备ID——你卸载支付宝重装它依然能识别出这是同一部手机。该ID存储在系统KeyStore中不会被常规清理删除。
**定期上报**:这些指纹数据不是一次性收集,而是定期上传服务器。
### 《个人信息保护法》怎么说?
第26条规定收集个人信息应当限于实现处理目的的**最小范围**。
29项设备信息 + 跨安装追踪 + 定期上传 = "最小必要"吗?
在欧盟GDPR框架下IMEI和MAC地址被明确归类为"个人数据"。新加坡PDPC已对此立案调查案号#00629724)。
---
## 四、97%的内部接口没有权限保护
这可能是最令人震惊的发现。
支付宝使用一个叫**Ariver**的框架管理JSBridge接口——小程序和H5页面通过这些接口调用原生功能支付、获取位置、读通讯录等
我们扫描了**全部408个BridgeExtension类**的`permit()`方法:
```
有权限检查的接口: 12个 (2.9%)
没有权限检查的接口: 396个 (97.1%)
```
在Ariver框架代码中`DefaultAccessController.java:132``permit()`返回`null`意味着**直接跳过所有权限检查**。
没有权限保护的高危接口包括:
- **6个支付类** — TradePayBridgeExtension、DCEPWalletBridgeExtension数字人民币钱包
- **5个认证类** — LoginExtension、VerifyIdentityBridgeExtension
- **3个NFC类** — NFCBridgeExtension、NfcPayExtension
- **6个文件类** — FileBridgeExtension、UploadFileBridgeExtension
- **6个硬件类** — ScanBridgeExtension摄像头、ClipboardBridgeExtension剪贴板、MakePhoneCallBridgeExtension拨打电话
396个无保护接口意味着**一旦攻击者找到入口,几乎可以调用支付宝的任何功能——包括支付、定位和通讯录。** 而入口确实存在详见我们提交的9个CVE漏洞
---
## 五、服务器可以远程修改你手机上的代码
在每一个安全关键方法中,我们都发现了一个`ChangeQuickRedirect`字段。这是一个叫**PatchProxy**的热修复框架——它允许服务器在**不经过应用商店审核、不需要用户同意**的情况下,远程修改支付宝在你手机上的运行行为。
被PatchProxy覆盖的方法包括
- TLS证书验证可远程关闭HTTPS安全检查
- 权限检查(可远程关闭接口保护)
- 签名验证(可远程关闭请求签名校验)
- 支付校验(可远程修改支付流程)
通俗理解:**你手机上支付宝的代码不是固定的——蚂蚁集团的服务器随时可以改。**
热修复是行业常见做法。但关键区别在于:支付宝的热修复**覆盖了安全验证方法**而非仅修复bug用户**不会收到任何通知**,修改可以在**毫秒级**生效。
---
## 六、"说了什么就推荐什么"——技术解释
很多用户反映:和朋友聊天提到某个商品,打开支付宝就看到了推荐。
### 我们的结论:有能力,但没有发现后台偷录证据
代码中确实存在完整的录音基础设施25+个录音相关Java文件、4种编码器WAV/AAC/PCM/MP3、14个麦克风API拦截点。但我们**没有找到后台静默录音的触发机制**——没有隐藏的后台Service没有独立的音频上传通道。
更合理的技术解释是:
1. **同一WiFi → 家庭画像**你和家人连同一个路由器路由器MAC地址被共享家人搜了什么你也会看到推荐
2. **跨APP设备指纹**UMID/OAID在多个阿里系APP间共享淘宝的搜索影响支付宝的推荐
3. **确认偏差**:你只记住了"准"的那几次,忘记了不准的几百次
---
## 七、行业对比
| 能力 | 支付宝 | 行业一般做法 |
|------|--------|-------------|
| API拦截 | 208个类别DexAOP | 30-50个支付相关 |
| 行为监控 | 22个事件含截屏/录屏/剪贴板) | 5-8个登录态/网络) |
| 设备指纹 | 29项跨安装追踪 | 10-15项 |
| 内部接口保护 | 97%无权限检查 | 安全框架通常默认拒绝 |
| 远程代码修改 | 覆盖安全验证方法 | 热修复通常不覆盖安全方法 |
---
## 八、如何自己验证
```bash
# 1. 下载APK (APKPure, 版本10.8.30.8000)
# 2. 反编译
jadx -d output --show-bad-code Alipay.apk
# 3. 统计DexAOP拦截点
grep -rn "proxy" output/sources/com/alipay/dexaop/ | wc -l
# 4. 搜索行为监控
grep -rn "SCREEN_SHOT\|SCREEN_RECORD\|PrimaryClipChanged\|PHONE_STATE" output/sources/
# 5. 统计permit()返回null
grep -A3 "public Permission permit()" output/sources/ | grep "return null" | wc -l
# 6. 查看远程开关
grep -rn "securityguard_orange_namespace" output/sources/
```
完整分析工具和结果https://github.com/sgInnora/alipay-securityguard-analysis
---
## 九、厂商回应与后续
- **2026-03-07**: 我们向蚂蚁集团报告了17个安全漏洞
- **2026-03-10**: 蚂蚁集团回复:**"正常功能"**
- **2026-03-11**: 我们公开披露研究成果。4小时后蚂蚁集团的律师事务所北京格韵律师事务所发出删除投诉
- **2026-03-15**: 微信公众号4篇相关文章**全部被删除**,无任何事前通知,依据"《网络安全法》"
- **2026-03-15**: 服务器端开始拦截我们的PoC验证请求API返回空白页
- **2026-03-17**: 9个漏洞已提交国际CVE数据库38个国家和地区的机构已回应
**厂商的应对模式**:口头否认 → 律师函 → 删除文章 → 服务器端封堵PoC → 平台全面审查
9个安全漏洞已提交国际CVE数据库编号待分配。研究成果已被Packet Storm Security收录发布Advisory #217089香港金管局、卢森堡CSSF、新加坡PDPC、英国FCA等机构已确认收到并启动处理程序。
---
## 我们的问题
1. **必要性**支付宝拦截208个系统API、监控22种行为、收集29项设备指纹——这些都符合"最小必要"原则吗?
2. **知情权**:用户是否被明确告知这些数据收集行为?隐私政策中是否逐项列明了截屏监控、剪贴板监控、通话状态监控?
3. **97%**97%的内部接口没有权限保护——这符合安全开发最佳实践吗?
4. **远程控制**:服务器可以远程修改安全验证逻辑——用户是否应该有知情权?
5. **全生态**这个安全SDK被阿里系多款APP共享淘宝、闲鱼、饿了么等——10亿+用户是否意识到这一点?
---
**作者**: Jiqiang Feng / Innora AI Security Research
**联系**: feng@innora.ai
**完整报告**: https://innora.ai/zfb/
**代码与工具**: https://github.com/sgInnora/alipay-securityguard-analysis
**Packet Storm Advisory**: #217089
*本文基于v10.8.30.8000版本静态分析。厂商可能已通过服务器端热修复修改了部分行为,但客户端代码中的架构和能力仍然存在。*
**本文永久地址**: https://innora.ai/zfb/privacy-analysis.html
**如果本文在任何平台被删除,请访问上述地址。这也是为什么我们需要一个不受单一平台审查的互联网。**