android打包绕过签名,实战android打包和签名

小编在之前给大家介绍过很多android项目打包的经验,本篇内容我们通过一个项目实例来给大家讲解android每一步打包和签名的过程。

android打包

以下是原理图:

android打包绕过签名,实战android打包和签名_第1张图片

由android的项目经过编译和打包,形成了:

.dex 文件

resources.arsc

uncompiled resources

AndroidManifest.xml

解压了一个普通的apk文件,解压出来的文件如下:

android打包绕过签名,实战android打包和签名_第2张图片

classes.dex 是.dex文件。resources.arsc是resources resources文件。AndroidManifest.xml是AndroidManifest.xml文件。res是uncompiled resources。META-INF是签名文件夹。

其中resources.arsc相等于是资源文件的索引,方便查找资源文件

具体打包流程图:

android打包绕过签名,实战android打包和签名_第3张图片

android签名

android签名后文件中多了个META-INF其中有三个文件:

android打包绕过签名,实战android打包和签名_第4张图片

下面分析一下3个文件的具体如何生成的apksinger:

1、MANIFEST.MF

逐一遍历里面的所有条目,如果是目录或者三个文件(MANIFEST.MF,CERT.RSA,CERT.SF)就跳过,如果是一个文件,就用SHA1(或者SHA256)消息摘要算法提取出该文件的摘要然后进行BASE64编码后,作为“SHA1-Digest”属性的值写入到MANIFEST.MF文件中的一个块中。该块有一个“Name”属性,其值就是该文件在apk包中的路径。

2、CERT.SF:

1》计算这个MANIFEST.MF文件的整体SHA1值,再经过BASE64编码后,记录在CERT.SF主属性块(在文件头上)的“SHA1-Digest-Manifest”属性值值下

2》逐条计算MANIFEST.MF文件中每一个块的SHA1,并经过BASE64编码后,记录在CERT.SF中的同名块中,属性的名字是“SHA1-Digest

3、CERT.RSA

这里会把之前生成的 CERT.SF文件, 用私钥计算出签名, 然后将签名以及包含公钥信息的数字证书一同写入 CERT.RSA 中保存。CERT.RSA是一个满足PKCS7格式的文件。

为何要这么来签名

上面我们就介绍了签名apk之后的三个文件的详细内容,那么下面来总结一下,Android中为何要用这种方式进行加密签名,这种方加密是不是最安全的呢?下面我们来分析一下,如果apk文件被篡改后会发生什么。

首先,如果你改变了apk包中的任何文件,那么在apk安装校验时,改变后的文件摘要信息与MANIFEST.MF的检验信息不同,于是验证失败,程序就不能成功安装。

其次,如果你对更改的过的文件相应的算出新的摘要值,然后更改MANIFEST.MF文件里面对应的属性值,那么必定与CERT.SF文件中算出的摘要值不一样,照样验证失败。

最后,如果你还不死心,继续计算MANIFEST.MF的摘要值,相应的更改CERT.SF里面的值,那么数字签名值必定与CERT.RSA文件中记录的不一样,还是失败。

那么能不能继续伪造数字签名呢?不可能,因为没有数字证书对应的私钥。

所以,如果要重新打包后的应用程序能再Android设备上安装,必须对其进行重签名。

从上面的分析可以得出,只要修改了Apk中的任何内容,就必须重新签名,不然会提示安装失败,当然这里不会分析,后面一篇文章会注重分析为何会提示安装失败。

你可能感兴趣的:(android打包绕过签名)