实战android打包和签名

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

android打包

以下是原理图：

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

.dex 文件

resources.arsc

uncompiled resources

AndroidManifest.xml

解压了一个普通的apk文件，解压出来的文件如下：

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

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

具体打包流程图：

android签名

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

下面分析一下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中的任何内容，就必须重新签名，不然会提示安装失败，当然这里不会分析，后面一篇文章会注重分析为何会提示安装失败。