Android签名机制原理

前言

本文主要是分析V1签名流程，文章结尾会对V2签名进行简要概述

本文主要用通俗易懂的语言讲解签名流程和签名验证流程，从而理解Android签名机制原理相关内容，并回答以下三个问题。

如何判断证书是否有效

如何判断APK是否被更改

如何防范被重新签名

签名流程

对APK中所有文件内容分别进行Hash计算，并将结果以BASE64编码格式保存在

MANIFEST.MF

。使用开发者的私钥对

MANIFEST.MF

进行加密，将加密结果保存在

CERT.SF

。最后

CERT.RSA

(证书信息包括公钥）和上面的两个文件，放入APK的

META-INF

目录下。

签名验证流程

验证APK完整性不包括META-INF里的文件，V2签名支持

安装应用时PackageManagerService会对APK进行签名检查，具体分为以下几步。

读取

CERT.RSA

(证书信息包括公钥）、

MANIFEST.MF

、

CERT.SF

使用获取的公钥对

CERT.SF

解密，将解密结果和

MANIFEST.MF

进行比较，如果相同说明证书有效、

MANIFEST.MF

未被更改

对APK中所有文件内容分别进行Hash计算，将结果的BASE64编码和

MANIFEST.MF

里的相应内容进行比较，全部相同则APK的内容未被更改

如何判断证书是否有效

因为签名的时候是使用私钥对

MANIFEST.MF

进行加密保存在

CERT.SF

中，之后只需要用证书中的公钥对

CERT.SF

进行解密，将结果和

MANIFEST.MF

进行比较即可

注意，在证书正确的情况下如果更改的APK里面文件内容，此时以上判断还是不会通过。因为

MANIFEST.MF

保存的是APK里面所有文件的Hash值，只要改变了APK里文件内容，Hash值就会变化

如何判断APK是否被更改

在签名保证

MANIFEST.MF

有效的前提下，只要对当前APK所有文件的内容的Hash值的BASE64编码和

MANIFEST.MF

相应文件存的值进行比较即可

如何防范被重新签名

通过反编译工具（apktool）可以轻易的对APK进行重新签名，针对这种情况可以通过以下几个方法加强被成功重新签名的难度

对APK进行加壳处理，增加反编译难度

程序中对签名自行验证，可配合服务端进行

不过个人觉得没有什么是绝对安全的，只是破解的成本和收益的博弈。比如方法一可以通过出壳进行破解，只是增加了出壳的成本。方法二可以在反编译的时候通过更改相关smali代码绕过签名验证的地方，只是增加了反编译成本。

V2签名

前面所说的都是V1签名，在Android7.0及其以上支持V2签名，V2签名的出现主要是为了解决V1签名存在的几个问题。如因解压原始数据造成的耗时以及完整性校验不够严格（META-INF目录下的内容未检查以及其他注释）。

首先V1和V2可以同时存在，如果支持V2走V2签名，否则降级走V1签名。v2签名直接对APK的二进制内容进行签名，因而APK中任何文件改变了都会导致完整性校验失败（这里就有一个坑，使用V2签名打包后，不能使用一些压缩优化算法进行优化APK了）。