(AndroidV1,V2,V3签名原理详解)
签名校验流程
==基础知识==： 1.数字签名 2.数字证书 3.对称加密和非对称加密
==背景介绍：==
一般开发者会指定使用自己创建的证书，如果没有指定，则会默认使用系统的证书，该默认的证书存储在C:\Users\admin.android\debug.keystore，不同的电脑可能安装不同路径。一个签名证书文件中，是包含一对公私钥，用私钥对apk进行签名，在安装到android手机时，系统会使用证书中对应签名私钥的公钥来验证，查看apk是否被更改过，如果没有则可以安装在手机上。任何的app store都不允许使用默认的debug.keystore打包的apk发布上去，因为debug.keystore的密码是默认的，不安全。
==一，没有签名的APK无法安装==
Android的APK要进行签名才能够安装到手机上，这是因为在安装的时候系统会进行检测，平时我们直接点AS里面那个绿色的运行按钮也能够直接安装到手机上，这是因为其实它也进行了签名，只不过AS自动帮我们做了这个操作有个默认的签名
（==在.android目录中有个debug.keystore默认的签名==）。
==二，校验流程== 9.0以上的系统会判断apk是否使用到V3版本的签名，如果有，那么按照V3版本签名校验方式进行校验校验成功直接安装，校验失败拒绝安装；如果apk不是使用V3签名，判断是不是使用V2,如果没有使用V2那么再判断是不是使用V1的签名。
==三，进行V3签名== Android不支持V3版本的签名，所以在AS里面看不到V3。但是在SDK中有个签名工具apksigner.jar。只有9.0以上这个签名工具才能签V3版本的签名。
（如果想要签V3版本的签名，那么只能自己去使用这个签名工具在命令行中进行签名）
==接下来详细介绍的就是不同的签名版本之间的区别。==
不同的签名版本之间的区别
V1签名保护机制
==保护APK中已有文件==
基于JAR的签名。在打包后的apk中会多三个文件：
==一.MANIFEST.MF==
APK当中的所有文件都会列出来用Name表示，除此之外每个文件都有SHA-256==签名摘要记录==
签名摘要记录：校验码对我们的数据内容进行验证，防止别人会修改你的文件。如果文件改动那么对应的检验码就会不一致
==二.CERT.SF== 这里面存放的和上面MANIFEST.MF的内容一样，只不过多了一个文件就是MANIFEST.MF文件，并对它进行了和其他文件一样的操作：生成校验码。
目的：上面说过修改了文件后，如果只是和之前文件的校验码对比是可以检测到修改的。但是如果我把文件和校验码都进行修改，那么他就检测不出来，这样的安全性就太低了。所以我们把上面的MANIFEST.MF文件也给他进行一次校验。
==但是如果你把SF文件和校验码也改了呢？接下来看最后一个文件CERT.RSA==
==三.CERT.RSA== 在签名的时候会给一个证书，里面有公钥和私钥； ==这个RSA文件使用私钥计算SF文件的数字签名+包含公钥的证书信息保存到RSA文件中。==
第三层防护：理论上没有私钥是无法伪装数字签名的。
==总结：== RSA文件保护SF文件，SF文件保护MF文件，MF文件保护apk中已有的所有文件
注意：V1签名保护的是APK中已有文件不被修改，但是新加的文件并不会受影响。
==下面我们来分析一下，如果apk文件被篡改后会发生什么。==
首先，如果你改变了apk包中的任何文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是验证失败，程序就不能成功安装。
其次，如果你对更改的过的文件相应的算出新的摘要值，然后更改MANIFEST.MF文件里面对应的属性值，那么必定与CERT.SF文件中算出的摘要值不一样，照样验证失败。
最后，如果你还不死心，继续计算MANIFEST.MF的摘要值，相应的更改CERT.SF里面的值，那么数字签名值必定与CERT.RSA文件中记录的不一样，还是失败。 那么能不能继续伪造数字签名呢？不可能，因为没有数字证书对应的私钥。
所以，如果要重新打包后的应用程序能再Android设备上安装，必须对其进行重签名。 从上面的分析可以得出，只要修改了Apk中的任何内容，就必须重新签名，不然会提示安装失败。
V2签名保护机制
==保护的是整个APK的字节数据==
原理：apk文件本身就是一个zip文件，按照ZIP文件格式插入APK Signing Block分块去记录签名信息
==APK Signing Block格式：==
size of block: APK分块总长度-8 id-value paris: id与value数据总长度 id:id数据 value:value数据 size of block:与第一个字段相同 magic:魔数（标记文件格式，目的为了快速识别文件格式）
举例： 假如APK签名分块数据总长度为108
size of block：100（108-8） id-value paris：X（id和value总长度） id：(4个字节) value：签名信息（X-4） size of block：100（108-8） magic:ZIP文件的魔数
==其中可以有多个id-value paris,id和value==
那么前面说过V2签名保护的是整个ZIP文件的字节数据，那么具体是保护哪些呢：
==可以看到保护的是1,3，4部分和刚才图里面的APK中V2签名存储的其中一个ID值对，但是"刚刚说了可以有多个id-value paris,id和value值对，所以我们可以添加这些东西而且不会影响签名机制"==
V3签名保护机制
==V3签名和V2签名类似，区别：== 一，V3签名多了一个判断机制："APK签名数据块大小必须是4096的倍数" 二，V3签名分块采用V2相同的签名分块格式，只不过改了V2签名分块中的那个ID 三，增添了有关受支持的SDK版本和prof-of-rotation结构的信息
怎样判断使用的是哪种签名
V1直接看APK的目录就可以分辨
另外两个涉及到了EOCD格式中有一个值代表Central Directory到Contents of Zip Entries的位移，
这里就用图去表示了。。
由此也可以得出：==偏移量-APK签名分块长度=签名分块从第几个字节开始== 偏移量：上面提到过在EOCD格式中存储着 APK签名分块长度：偏移量-16个字节（magic魔数）-8个字节（size of block）
参考链接：
==https://www.2cto.com/kf/201512/455388.html==
