背景
最近在调研一个测试工具的使用，在使用中发现被测试工具处理过的apk文件经安装后打开就会崩溃，分析崩溃日志后原因是签名不一致导致的。
说到Android中的签名，可能大家都知道签名的目的就是为了保护apk文件的安全，如果apk被恶意篡改后经过安装校验的时候，就会出现校验失败，导致安装包安装失败的情况。但如果更深去问一下Android签名机制和原理，是不是就被问住了？接下来的就让我们去探究Android签名机制和原理。
Android 签名机制和原理
Android系统在安装APK的时候，首先会检验APK的签名，如果发现签名文件不存在或者校验签名失败，则会拒绝安装，所以应用程序在发布之前一定要进行签名。给APK签名可以带来以下好处：
签名的目的：
1. 对发送者的身份认证：
由于开发商可能通过使用相同的package name来混淆替换已经安装的程序，以此保证签名不同的包不被替换。
2. 保证信息传输的完成性：
签名对于包中的每个文件进行处理，以此确保包中内容不被替换。
3. 防止交易中的抵赖发生，market对软件的要求。
签名原理：
简单来说总体分为以下几个步骤：
1. 对Apk中的每个文件做一次算法（数据摘要+Base64编码），保存到MAINFEST.MF
2. 对MAINFEST.MF整个文件做一次算法（数据摘要+B阿瑟64编码），存放到CERT.SF文件的头属性中，在对MAINFEST.MF文件中各个属性块做一次算法（数据摘要+Base64编码），存放到一个属性块中。
3. 对CERT.SF文件做签名，内容存档到CERT.RSA中
对一个APK文件签名之后，APK文件根目录下会增加META-INF目录，该目录下增加三个文件，分别是：MANIFEST.MF、CERT.SF和CERT.RSA，以下是具体的流程：
MANIFEST.MF
这是摘要文件，文件中保存了APK里面所有文件的SHA1校验值的BASE64编码，格式如下（一个文件对应一条记录）。如果改变了APK包中的文件，在apk安装校验时，改变后的文件摘要信息与 MANIFEST.MF 的检验信息不同，程序就不会安装成功。假如攻击者修改了程序的内容，又重新生成了新的摘要，就可以通过验证。
Name: AndroidMainfest.xml SHA1-Digest: incCj47jcu56R8pKV8dLACZBKD8= Name: META-INF/android.arch.core_runtime.version SHA1-Digest: BeF7ZGqBckDCBhhvlPj0xwl01dw=
CERT.SF这是对摘要的签名文件，对前一步生成的MANIFEST.MF，使用SHA1-RSA算法，用开发者的私钥进行签名。在安装时只能使用公钥才能进行解密。解密之后，与未加密的MANIFEST.MF进行对比，如果相符，则表明内容没有被异常修改。如果在这一步，开发者修改了程序内容，并生成了新的摘要文件，但是攻击者没有开发者的私钥，所以不能生成正确的签名文件。系统在对程序进行验证的时候，用开发者公钥对不正确的签名文件进行解密，得到的结果和摘要文件对应不起来，导致不能通过检验，不能成功安装文件。文件格式如下：
Name: AndroidMainfest.xml SHA1-Digest: SyFsd2VUpCg4nq8jSOB7dBwuMyI= Name: META-INF/android.arch.core_runtime.version SHA1-Digest: OPQCkzMXJVPQryHeMowVNZmfRMw=
CERT.RSA
从上面的内容来看，Android系统就是根据这三个文件的内容对APK文件进行签名检验的。
