Android 他山之石，可以攻玉！一篇文章看懂 v1/v2/v3 签名机制

Posted 2023-03-25

参考技术A

这篇文章的内容会涉及以下前置 / 相关知识，贴心的我都帮你准备好了，请享用~

数字签名（Digital Signature）也叫作数字指纹（Digital Fingerprint），它是消息摘要算法和非对称加密算法的结合体，能够验证数据的完整性，并且认证数据的来源 。

数据签名算法的模型分为两个主要阶段：

需要注意的是，android 目前不对应用证书进行 CA 认证，应用可以由第三方（OEM、运营商、其他应用市场）签名，也可以自行签名。

应用 APK 其实是一种特殊的 Zip 压缩包，无法避免恶意破解者解压 / 反编译修改内容，针对这个问题有何解决方案呢？他山之石，可以攻玉 ——数字签名算法。应用签名正是数字签名算法的应用场景之一，与其他应用场景类似，目的无非是：

Android 平台上运行的每个应用都必须有开发者的签名。在安装应用时，软件包管理器会验证 APK 是否已经过适当签名，安装程序会拒绝没有获得签名就尝试安装的应用。

软件包管理器在安装应用前会验证应用摘要，如果破解者修改了 apk 里的内容，那么摘要就不再匹配，验证失败（验证流程见下文方案）。

截止至 Android 11，Android 支持以下三种应用签名方案：

为了提高兼容性，必须按照 v1、v2、v3 的先后顺序采用签名方案，低版本平台会忽略高版本的签名方案在 APK 中添加的额外数据。

v1 签名方案是基于 Jar 的签名。

首先，我们先来分析其签名产物。 v1 签名后会增加 META-INF 文件夹 ，其中会有如下三个文件。考虑到使用不同的证书和签名方式，得到的文件名可能不同，因此你只要留意文件的后缀即可：

v1 签名流程如下：

MANIFEST.MF（Message Digest File，摘要文件）

\\*.SF（Signature File，签名文件）

验证流程可以分为验证签名和验证完整性两个步骤：

验证签名步骤：

如果上述签名验证结果正确，才会验证完整性：

以上任何步骤验证失败，则整个 APK 验证失败。

为了解决这些问题，Android 7.0 中引入了 APK 签名方案 v2。

v2 签名方案是一种 全文件签名方案 ，该方案能够发现对 APK 的受保护部分进行的所有更改，相对于 v1 签名方案验证速度更快，完整性覆盖范围更广。

在分析 v2 签名方案之前，我们先简单了解一下 Zip 文件格式：

首先，我们先来分析其签名产物。v2 签名后会在 「条目内容区」和「中央目录区」之间插入「APK 签名分块（APK Signing Block）」 。

从左到右边，我们定义为区块 1~4。

相对与 v1 签名方案，v2 签名方案不再以文件为单位计算摘要了，而是以 1 MB 为单位将文件拆分为多个连续的块（chunk），每个分区的最后一个块可能会小于 1 MB。

v2 签名流程如下：

验证流程可以分为验证签名和验证完整性两个步骤：

签名方案 v3 支持密钥轮换，应用能够在 APK 更新过程中更改其签名密钥。

【累了，后面先不写了...】

这一节，我们介绍基于 Android 应用签名机制的衍生应用场景。

在 v1 方案中， MANIFEST.MF 和 *.SF 这两个文件会记录大量的文件名和文件摘要。如果 apk 中文件数很多，而且文件名很长，那么这两个文件会变得很大。使用 AndResGuard 工具，可以将文件名转换为短路径文件名，从而减少这两个文件的大小。

在实际生产中，往往需要生成多个渠道的 APK 包，传统的方法是使用 APKTool 逆向工具、Flavor + BuildType 等方案，这一类多渠道打包方案的缺点是耗时严重。随着 Android 应用签名方案的演进，演变出了不同的多渠道打包方案：

在 v1 方案中，我们提到了完整性校验不覆盖到 META-INF 文件夹的问题。有些多渠道打包方案就是利用了这个问题，在 META-INF 文件夹下添加空文件， 用空文件的名称来作为渠道的唯一标识 ，就可以节省打包的时间，提高打渠道包的速度。

除了添加空文件的方法，还可以向 APK 添加 Zip Comment 来生成多渠道包（APK 本身就是特殊的 Zip 包）。

在 v2 签名方案中，几乎整个 APK 都纳入保护范围，如果向 APK 添加空文件或 Zip Comment 的话，在安装时会报以下错误：

新背景下的多渠道打包方案，则是利用了 APK 签名分块（区块 2）不受保护 & 字段可扩展的特点 ，向区块中添加多渠道信息（ID-Value），例如 美团多渠道打包方案 Walle 。