Android v1、v2、v3签名详解

一、Android v1、v2、v3签名详解

了解 HTTPS通信的同学都知道，在消息通信时，必须解决确保消息来源的真实性与消息完整性的问题。同理，在安装 APK时，也需要验证 APK来源的真实性，并确保 APK未被第三方篡改。为此，Android官方要求开发者进行签名，即对 APK进行加密。签名涉及基本概念：消息摘要、数字签名和数字证书。

消息摘要（Message Digest）是将消息数据通过单向哈希函数生成固定长度的哈希值，通常用于验证数据完整性。SHA-256是 SHA-1的升级版，现在 Android使用的默认算法为 SHA-256。

数字签名的作用包括：保证信息传输完整性、发送者身份认证与防止抵赖。它通过使用发送者的私钥加密消息摘要，接收者则用对应公钥解密并验证消息完整性。RSA是常见数字签名方案，其流程为：使用私钥加密消息摘要生成签体，接收者用公钥解密并验证。

然而，数字签名仅确保消息完整性，不保证保密性，且在消息长度较大时效率较低。因此，它通常与快速摘要算法结合使用，构成有效的签名方案。

数字证书用于保护公钥安全可信，它包含公钥拥有者信息及公钥，遵循 X.509标准。数字证书通过 CA机构的签名确保其可信度。数字证书结合数字签名技术，用于确保公钥的完整性与认证性。

Android的打包流程包括：资源文件打包、aidl文件处理、Java代码编译、类文件转换与 APK打包等步骤。签名发生在倒数第二步，针对已存在的 APK文件，使用开发者自定义的 keystore签名。

Android的应用签名方案经历了三代：v1（基于 JAR签名）、v2（APK签名方案，Android 7.0引入）、v3（APK签名方案升级版，Android 9.0引入）。v1到 v2是颠覆性的升级，主要解决 JAR签名方案的安全性问题。v3为 v2的升级版，结构上未做重大调整。

v1到 v2的升级引入了渠道签署问题，为不同渠道安装包提供区别。各大厂提供了开源签渠道方案，如 Walle（美团）和 VasDolly（腾讯）。签名工具有 jarsigner和 apksigner，它们用于 APK签名，使用 keystore文件和 pk8、x509.pem文件。

签名过程包括：选取签名后的 APK，解压后分析 MANIFEST.MF、CERT.SF、CERT.RSA文件内容。MANIFEST.MF文件记录 APK内容摘要，CERT.SF文件记录摘要的摘要，CERT.RSA文件则记录签名信息。签名验证发生在安装过程中，涉及三个步骤。

APK签名方案 v2（Android 7.0引入）改进了 v1的签名校验速度慢与可修改性问题。它全文件签名，验证所有字节，确保 APK的完整性与保护性。v3（Android 9.0引入）在 v2的基础上新增新证书块，记录所有签名信息，支持签名的替换与升级。

总之，Android签名机制通过消息摘要、数字签名与数字证书确保了消息与 APK的完整性和安全性，同时引入了签名验证机制来保护用户免受篡改与欺骗。签名方案的升级逐渐改进了性能与安全性，确保了向下兼容性，为开发者提供了强大的安全框架。

二、android mvp是什么意思

1、MVP模式是MVC模式在Android上的一种变体，要介绍MVP就得先介绍MVC。在MVC模式中，Activity应该是属于View这一层。而实质上，它既承担了View，同时也包含一些Controller的东西在里面。这对于开发与维护来说不太友好，耦合度大高了。把Activity的View和Controller抽离出来就变成了View和Presenter，这就是MVP模式。

2、在Android项目中，Activity和Fragment占据了大部分的开发工作。如果有一种设计模式（或者说代码结构）专门是为优化Activity和Fragment的代码而产生的，你说这种模式重要不？这就是MVP设计模式。

3、按照MVC的分层，Activity和Fragment（后面只说Activity）应该属于View层，用于展示UI界面，以及接收用户的输入，此外还要承担一些生命周期的工作。Activity是在Android开发中充当非常重要的角色，特别是TA的生命周期的功能，所以开发的时候我们经常把一些业务逻辑直接写在Activity里面，这非常直观方便，代价就是Activity会越来越臃肿，超过1000行代码是常有的事，而且如果是一些可以通用的业务逻辑（比如用户登录），写在具体的Activity里就意味着这个逻辑不能复用了。如果有进行代码重构经验的人，看到1000+行的类肯定会有所顾虑。因此，Activity不仅承担了View的角色，还承担了一部分的Controller角色，这样一来V和C就耦合在一起了，虽然这样写方便，但是如果业务调整的话，要维护起来就难了，而且在一个臃肿的Activity类查找业务逻辑的代码也会非常蛋疼，所以看起来有必要在Activity中，把View和Controller抽离开来，而这就是MVP模式的工作了。

三、Android基础『V1V2V3签名』

签名：在 APK中写入一个「指纹」。指纹写入以后，APK中有任何修改，都会导致这个指纹无效，Android系统在安装 APK进行签名校验时就会不通过，从而保证了安全性。

摘要算法：使用一段简单的看上去随机的不可逆向的固定长度的字符串来表示一个文件的唯一性。常见的摘要算法如MD5(128个比特位)、SHA-1算法(160/192/256个比特位)。

公钥密码体制：也称非对称算法，特点是公钥是公开的，私钥是保密的。常见的如：RSA。

V1：基于jarsigner(JDK自带工具，使用keystore文件进行签名)或 apksigner(Android专门提供的，使用pk8、x509.pem进行签名)。keystore和pk8/x509.pem可以相互转换。

签名原理：首先keystore文件包含一个MD5和一个SHA1摘要。这也是很多开放平台需要我们上传的摘要数据。

签名APK后会在META-INF文件夹下生产CERT.RSA、CERT.SF、MANIFEST.MF三个文件。

在apk中，/META-INF文件夹中保存着apk的签名信息，一般至少包含三个文件，[CERT].RSA，[CERT].SF和MANIFEIST.MF文件。这三个文件就是对apk的签名信息。

MANIFEST.MF中包含对apk中除了/META-INF文件夹外所有文件的签名值，签名方法是先SHA1()(或其他hash方法)在base64()。存储形式是：Name加[SHA1]-Digest。

[CERT].SF是对MANIFEST.MF文件整体签名以及其中各个条目的签名。一般地，如果是使用工具签名，还多包括一项。就是对MANIFEST.MF头部信息的签名，关于这一点前面源码分析中已经提到。

[CERT].RSA包含用私钥对[CERT].SF的签名以及包含公钥信息的数字证书。

  是否存在签名伪造可能：

修改(含增删改)了apk中的文件，则：校验时计算出的文件的摘要值与MANIFEST.MF文件中的条目不匹配，失败。

修改apk中的文件+MANIFEST.MF,则：MANIFEST.MF修改过的条目的摘要与[CERT].SF对应的条目不匹配，失败。

修改apk中的文件+MANIFEST.MF+[CERT].SF，则：计算出的[CERT].SF签名与[CERT].RSA中记录的签名值不匹配，失败。

修改apk中的文件+MANIFEST.MF+[CERT].SF+[CERT].RSA，则：由于证书不可伪造，[CERT].RSA无法伪造。

1. Contents of ZIP entries（from offset 0 until the start of APK Signing Block）

4. ZIP End of Central Directory

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

格式大体和 v2类似，在 v2插入的签名块（Apk Signature Block v2）中，又添加了一个新快（Attr块）。

在这个新块中，会记录我们之前的签名信息以及新的签名信息，以密钥转轮的方案，来做签名的替换和升级。这意味着，只要旧签名证书在手，我们就可以通过它在新的 APK文件中，更改签名。

v3签名新增的新块（attr）存储了所有的签名信息，由更小的 Level块，以链表的形式存储。

其中每个节点都包含用于为之前版本的应用签名的签名证书，最旧的签名证书对应根节点，系统会让每个节点中的证书为列表中下一个证书签名，从而为每个新密钥提供证据来证明它应该像旧密钥一样可信。

这个过程有点类似 CA证书的证明过程，已安装的 App的旧签名，确保覆盖安装的 APK的新签名正确，将信任传递下去。

注意：签名方式只支持升级不支持降级，如安装了V2的包，不能覆盖替换为V1的包。

Android App签名(证书)校验过程源码分析

新一代开源Android渠道包生成工具Walle