@TOC

签名校验流程

==基础知识==:
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格式:==

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==