APKPure 和酷安的下载安全性分析

APKPure 和酷安的下载安全性分析

去年十二月，我在整理一部 Pixel 7 的测试机环境，需要从外部渠道回退安装某个特定旧版本的 Firefox（org.mozilla.firefox，版本 120.1.0）。Google Play 已经强制更新到 121.x，而 Mozilla 官方的 FTP 存档虽然能找到历史 APK，但当时网络链路极不稳定。我顺手从 APKPure 拉了一个同名同版本的 APK，准备先用 apksigner 过一遍签名完整性，再继续后面的自动化测试。结果 build-tools 34.0.0 下的 apksigner verify --verbose 输出虽然显示 v2 scheme: true、v3 scheme: true，证书 Subject 也是 Mozilla Corporation，但用 keytool -printcert -jarfile 对比指纹时，SHA-256 指纹的最后四位与官方包不一致。同版本号、同包名，证书指纹却对不上，这说明 APKPure 分发的并不是 Mozilla 官方签名的那个构建产物。这个细节让我停下了手里的活，开始系统性地对比 APKPure 和酷安这两个国内开发者常用的第三方下载渠道，在安全完整性上到底能做到什么程度，又有哪些根本性的盲区。

证书指纹比对：apksigner 输出的微妙差异

Android 的 APK 签名机制从 v1（JAR 签名）演进到 v2/v3，核心变化在于 v2 之后签名信息被写入 ZIP 的 Central Directory 之前，形成一个独立的 APK Signing Block。这意味着任何对 ZIP 内部文件的改动，哪怕只是多塞了一个空文件，都会导致 v2 签名验证失败。所以当我看到 APKPure 的 Firefox 120.1.0 能够通过 v2/v3 验证时，第一反应是：它的签名块确实是用某一套私钥签过的，而且证书链完整。但证书链完整不等于证书与官方一致。

我随后用 apksigner verify --verbose --print-certs 对同一版本在三个来源的样本做了比对：Mozilla 官方 FTP（archive.mozilla.org）、APKPure、以及酷安。官方包与酷安上标称“官方”的条目，证书指纹完全一致，都是 9A 开头的那个 SHA-256 指纹。而 APKPure 的样本虽然包名、版本号、甚至 classes.dex 的 CRC32 都相同，证书却来自另一个 CA 路径下的 Mozilla 签发证书。进一步查资料发现，Mozilla 确实会为不同分发渠道提供不同的签名密钥（包括部分 OEM 预装包），但 APKPure 并未在下载页明确标注这是“渠道专用构建”。对于普通用户来说，这意味着你在 APKPure 下载的“官方版”，实际上是一个非全局通用的签名变体。如果你的手机之前通过 Google Play 安装过同一个应用，直接覆盖安装这个 APKPure 版本会因为签名冲突而失败，必须先卸载再重装，数据全丢。

酷安的情况稍好一些，至少在主流头部应用上，标有“官方”标签的包通常与 Play 商店证书一致。但酷安存在一个 APKPure 没有的问题：大量应用并没有“官方”标签，而是普通用户自行上传。这些上传包往往打着“去广告版”“纯净版”的旗号，签名显然与官方不同，有些甚至直接使用了 debug 证书（CN=Android Debug）。我在酷安翻到过一个号称“绿化”的某社交类应用 10.3