二、APK Signature Scheme v1

2.1 签名工具

Android 应用的签名工具有两种：jarsigner 和 signAPK。它们的签名算法没什么区别，主要是签名使用的文件不同。

jarsigner：jdk 自带的签名工具，可以对 jar 进行签名。使用 keystore 文件进行签名。生成的签名文件默认使用 keystore 的别名命名。
signAPK：Android sdk 提供的专门用于 Android 应用的签名工具。使用 pk8、x509.pem 文件进行签名。其中 pk8 是私钥文件，x509.pem 是含有公钥的文件。生成的签名文件统一使用“CERT”命名。
既然这两个工具都是给 APK 签名的，那么 keystore 文件和 pk8，x509.pem 他们之间是不是有什么联系呢？答案是肯定的，他们之间是可以转化的，这里就不再分析如何进行转化，网上的例子很多。

还有一个需要注意的知识点，如果我们查看一个keystore 文件的内容，会发现里面包含有一个 MD5 和 SHA1 摘要，这个就是 keystore 文件中私钥的数据摘要，这个信息也是我们在申请很多开发平台账号时需要填入的信息。

2.2 签名过程

首先我们任意选取一个签名后的 APK（Sample-release.APK）解压：

在 META-INF 文件夹下有三个文件：MANIFEST.MF、CERT.SF、CERT.RSA。它们就是签名过程中生成的文件，姑且叫他们“签名三兄弟”吧，把它们搞清楚了，你就精通签名了。

2.2.1 MANIFEST.MF

该文件中保存的内容其实就是逐一遍历 APK 中的所有条目，如果是目录就跳过，如果是一个文件，就用 SHA1（或者 SHA256）消息摘要算法提取出该文件的摘要然后进行 BASE64 编码后，作为“SHA1-Digest”属性的值写入到 MANIFEST.MF 文件中的一个块中。该块有一个“Name”属性， 其值就是该文件在 APK 包中的路径。

2.2.2 CERT.SF

SHA1-Digest-Manifest-Main-Attributes：对 MANIFEST.MF 头部的块做 SHA1（或者SHA256）后再用 Base64 编码

SHA1-Digest-Manifest：对整个 MANIFEST.MF 文件做 SHA1（或者 SHA256）后再用 Base64 编码

SHA1-Digest：对 MANIFEST.MF 的各个条目做 SHA1（或者 SHA256）后再用 Base64 编码

对于 SHA1-Digest 值的验证可以手动进行，将 MANIFEST.MF 中任意一个块的内容复制并保存在一个新的文档中，注意文末需要加两个换行（这是由 signAPK 的源码决定的）

2.2.3 CERT.RSA

这里会把之前生成的 CERT.SF 文件，用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。这里要注意的是，Android APK 中的 CERT.RSA 证书是自签名的，并不需要这个证书是第三方权威机构发布或者认证的，用户可以在本地机器自行生成这个自签名证书。Android 目前不对应用证书进行 CA 认证。

2.2.3.1 什么是自签名证书？

所谓自签名证书是指自己给自己颁发的证书，即公钥证书中 Issuer（发布者）和 Subject（所有者）是相同的。当然，APK 也可以采用由 CA 颁发私钥证书进行签名。采用非自签名时，最终 APK 的公钥证书中就会包含证书链，并且会存在多余一个证书，证书间通过 Issuer 与 Subject进行关联，Issuer 负责对 Subject 进行认证。当安装 APK 时，系统只会用位于证书链 中最底层的证书对 APK 进行校验，但并不会验证证书链的有效性。

在 HTTPS 通信中使用自签名证书时浏览器的显示效果：

CERT.RSA 文件中的内容：

这里我们看到的都是二进制文件，因为RSA文件加密了，所以我们需要用openssl命令才能查看其内容：

$ openssl pkcs7 -inform DER -in /<文件存放路径>/Sample-release_new/original/META-INF/CERT.RSA -text -noout -print_certs

综上所述，一个完整的签名过程如下所示：

2.3 签名校验过程

签名验证是发生在APK的安装过程中，一共分为三步：

检查 APK 中包含的所有文件，对应的摘要值与 MANIFEST.MF 文件中记录的值一致。

使用证书文件（RSA 文件）检验签名文件（SF 文件）没有被修改过。

使用签名文件（SF 文件）检验 MF 文件没有被修改过。

综上所述，一个完整的签名验证过程如下所示：

为什么使用这样的签名流程呢？

我们假设一下，首先，如果你改变了 APK 包中的任何文件，那么在 APK 安装校验时，改变后的文件摘要信息与 MANIFEST.MF 的检验信息不同，于是验证失败，程序就不能成功安装。

其次，如果你对更改过的文件相应的算出新的摘要值，然后更改 MANIFEST.MF 文件里面对应的属性值，那么必定与 CERT.SF 文件中算出的摘要值不一样，照样验证失败。

最后，如果你还不死心，继续计算 MANIFEST.MF 的摘要值，相应的更改 CERT.SF 里面的值，那么数字签名值必定与 CERT.RSA 文件中记录的不一样，还是失败。

那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。

三、APK Signature Scheme v2

APK 签名方案 v2 是一种全文件签名方案，该方案能够发现对 APK 的受保护部分进行的所有更改，从而有助于加快验证速度并增强完整性保证。

3.1 v1 签名机制的劣势

从 Android 7.0 开始，Android 支持了一套全新的 V2 签名机制，为什么要推出新的签名机制呢？通过前面的分析，可以发现 v1 签名有两个地方可以改进：

签名校验速度慢
校验过程中需要对apk中所有文件进行摘要计算，在 APK 资源很多、性能较差的机器上签名校验会花费较长时间，导致安装速度慢。

完整性保障不够
META-INF 目录用来存放签名，自然此目录本身是不计入签名校验过程的，可以随意在这个目录中添加文件，比如一些快速批量打包方案就选择在这个目录中添加渠道文件。

为了解决这两个问题，在 Android 7.0 Nougat 中引入了全新的 APK Signature Scheme v2。

3.2 v2 带来了什么变化？

由于在 v1 仅针对单个 ZIP 条目进行验证，因此，在 APK 签署后可进行许多修改 — 可以移动甚至重新压缩文件。事实上，编译过程中要用到的 ZIPalign 工具就是这么做的，它用于根据正确的字节限制调整 ZIP 条目，以改进运行时性能。而且我们也可以利用这个东西，在打包之后修改 META-INF 目录下面的内容，或者修改 ZIP 的注释来实现多渠道的打包，在 v1 签名中都可以校验通过。

v2 签名将验证归档中的所有字节，而不是单个 ZIP 条目，因此，在签署后无法再运行 ZIPalign（必须在签名之前执行）。正因如此，现在，在编译过程中，Google 将压缩、调整和签署合并成一步完成。

3.3 v2 签名模式

简单来说，v2 签名模式在原先 APK 块中增加了一个新的块（签名块），新的块存储了签名，摘要，签名算法，证书链，额外属性等信息，这个块有特定的格式，具体格式分析见后文，先看下现在 APK 成什么样子了。

为了保护 APK 内容，整个 APK（ZIP文件格式）被分为以下 4 个区块：

ZIP 条目的内容（从偏移量 0 处开始一直到“APK 签名分块”的起始位置）
APK 签名分块
ZIP 中央目录
ZIP 中央目录结尾

其中，应用签名方案的签名信息会被保存在 区块 2（APK Signing Block）中，而区块 1（Contents of ZIP entries）、区块 3（ZIP Central Directory）、区块 4（ZIP End of Central Directory）是受保护的，在签名后任何对区块 1、3、4 的修改都逃不过新的应用签名方案的检查。

3.4 签名过程

从上面我们可以看到 v2 模式块有点类似于我们 META-INF 文件夹下的信息内容。那么对于上述当中摘要的信息又是怎么计算出来的呢。

首先，说一下 APK 摘要计算规则，对于每个摘要算法，计算结果如下:

将 APK 中文件 ZIP 条目的内容、ZIP 中央目录、ZIP 中央目录结尾按照 1MB 大小分割成一些小块。
计算每个小块的数据摘要，数据内容是 0xa5 + 块字节长度 + 块内容。
计算整体的数据摘要，数据内容是 0x5a + 数据块的数量 + 每个数据块的摘要内容
总之，就是把 APK 按照 1M 大小分割，分别计算这些分段的摘要，最后把这些分段的摘要在进行计算得到最终的摘要也就是 APK 的摘要。然后将 APK 的摘要 + 数字证书 + 其他属性生成签名数据写入到 APK Signing Block 区块。

3.5 签名校验过程

接下来我们来看v2签名的校验过程，整体大概流程如下图所示：

其中 v2 签名机制是在 Android 7.0 以及以上版本才支持。因此对于 Android 7.0 以及以上版本，在安装过程中，如果发现有 v2 签名块，则必须走 v2 签名机制，不能绕过。否则降级走 v1 签名机制。
v1 和 v2 签名机制是可以同时存在的，其中对于 v1 和 v2 版本同时存在的时候，v1 版本的 META_INF 的 .SF 文件属性当中有一个 X-Android-APK-Signed 属性：

X-Android-APK-Signed: 2

因此如果想绕过 v2 走 v1 校验是不行的。

3.6 v2 对多渠道打包的影响

之前的渠道包生成方案是通过在 META-INF 目录下添加空文件，用空文件的名称来作为渠道的唯一标识。但在新的应用签名方案下 META-INF 已经被列入了保护区了，向 META-INF 添加空文件的方案会对区块 1、3、4 都会有影响。
————————————————

参考原文链接：https://blog.csdn.net/freekiteyu/article/details/84849651