所有的Android应用程序都要求开发人员用一个证书进行数字签名，anroid系统不会安装没有进行签名的由于程序。平时我们的程序可以在模拟器上安装并运行，是因为在应用程序开发期间，由于是以Debug面试进行编译的，因此ADT根据会自动用默认的密钥和证书来进行签名，而在以发布模式编译时，apk文件就不会得到自动签名，这样就需要进行手工签名。
   给apk签名可以带来以下好处：
        1. 应用程序升级：如果你希望用户无缝升级到新的版本，那么你必须用同一个证书进行签名。这是由于只有以同一个证书签名，系统才会允许安装升级的应用程序。如果你采用了不同的证书，那么系统会要求你的应用程序采用不同的包名称，在这种情况下相当于安装了一个全新的应用程序。如果想升级应用程序，签名证书要相同，包名称要相同！
        2.应用程序模块化：Android系统可以允许同一个证书签名的多个应用程序在一个进程里运行，系统实际把他们作为一个单个的应用程序，此时就可以把我们的应用程序以模块的方式进行部署，而用户可以独立的升级其中的一个模块。
        3.代码或者数据共享：Android提供了基于签名的权限机制，那么一个应用程序就可以为另一个以相同证书签名的应用程序公开自己的功能。以同一个证书对多个应用程序进行签名，利用基于签名的权限检查，你就可以在应用程序间以安全的方式共享代码和数据了。

不同的应用程序之间，想共享数据，或者共享代码，那么要让他们运行在同一个进程中，而且要让他们用相同的证书签名。

 

    参考：签名的方法 ，这里就不详述签名的方法

 

 

 

消息摘要 -Message Digest
简称摘要，请看英文翻译，是摘要，不是签名，网上几乎所有APK签名分析的文章都混淆了这两个概念。简单的说消息摘要就是在消息数据上，执行一个单向的Hash函数，生成一个固定长度的Hash值，这个Hash值即是消息摘要也称为数字指纹，消息摘要有以下特点：
1. 通过摘要无法推算得出消息本身
2. 如果修改了消息，那么摘要一定会变化（实际上，由于长明文生成短摘要的Hash必然会产生碰撞），所以这句话并不准确，我们可以改为：很难找到一种模式，修改了消息，而它的摘要不会变化（抗冲突性）。

 

消息摘要的这种特性，很适合来验证数据的完整性，比如在网络传输过程中下载一个大文件BigFile，我们会同时从网络下载BigFile和BigFile.md5，BigFile.md5保存BigFile的摘要，我们在本地生成BigFile的消息摘要，和BigFile.md5比较，如果内容相同，则表示下载过程正确。
注意，消息摘要只能保证消息的完整性，并不能保证消息的不可篡改性。

MD5/SHA-0 SHA-1
这些都是摘要生成算法，和签名没有关系。如果非要说他们和签名有关系，那就是签名是要借助于摘要技术。

数字签名 - Signature
数字签名，百度百科对数字签名有非常清楚的介绍。数字签名就是信息的发送者用自己的私钥对消息摘要加密产生一个字符串，加密算法确保别人无法伪造生成这段字符串，这段数字串也是对信息的发送者发送信息真实性的一个有效证明。数字签名是 非对称密钥加密技术 + 数字摘要技术 的结合。

数字签名技术是将信息摘要用发送者的私钥加密，与原文一起传送给接收者。接收者只有用发送者的公钥才能解密被加密的信息摘要，然后接收者用相同的Hash函数对收到的原文产生一个信息摘要，与解密的信息摘要做比对。如果相同，则说明收到的信息是完整的，在传输过程中没有被修改；不同则说明信息被修改过，因此数字签名能保证信息的完整性。并且由于只有发送者才有加密摘要的私钥，所以我们可以确定信息一定是发送者发送的。

数字证书 - Certificate
数字证书是一个经证书授权 中心数字签名的包含公开密钥拥有者信息以及公开密钥的文件。CERT.RSA包含了一个数字签名以及一个数字证书。
需要注意的是Android APK中的CERT.RSA证书是自签名的，并不需要这个证书是第三方权威机构发布或者认证的，用户可以在本地机器自行生成这个自签名证书。

 

我们将DF_SDM_1008.apk（自己任选）文件改为DF_SDM_1008.zip文件，打开DF_SDM_1008.zip文件，如图1所示。

 

图1 DF_SDM_1008.zip文件

 

1. META-INF\ （注：签名后的信息）；
2. res\ (注：存放资源文件的目录) ；
3. AndroidManifest.xml (注：程序全局配置文件) ；
4. classes.dex （注：Dalvik字节码）；
5. resources.arsc (注：编译后的二进制资源文件)。

接下来针对META-INF\文件进行分析。

 

META-INF\文件中有三个文件，分别是MANIFEST.MF, CERT.SF, CERT.RSA，如图2所示。

现在有一个问题就是，三个文件怎么产生的的——签名产生的，第二个问题签名是怎么做的呢？这里Android提供了APK的签名工具signapk，通过xxx.keystore（java的密钥库、用来进行通信加密用的、比如数字签名。keystore就是用来保存密钥对的，比如公钥和私钥）提供的信息，对APK进行签名，生成的META-INF\文件，参考文章4。

 

先看一下源代码：

遍历APK包中的每一个文件，利用SHA1算法生成这些文件的摘要信息。

验证是所有文件使用的SHA1算法：

1.安装hashTab工具
2.打开MANIFEST.MF文件

举个例子：

其中找到文件中的AndroidManifest.xml文件，查看其对应的hash值，如图3所示。

    这里取出16进制的668BEAE0054C7028C59082D92E51E099E38BBE75，将16进制通过在线转码网站：hex to base64转化为对应的base64编码，看见“Zovq4AVMcCjFkILZLlHgmeOLvnU=”与记录信息相对的。

 

先看一下源码：

 

虽然writeSignatureFile字面上看起来是写签名文件，但是CERT.SF的生成和私钥没有一分钱的关系，实际上也不应该有一分钱的关系，这个文件自然不保存任何签名内容。CERT.SF中保存的是MANIFEST.MF的摘要值（第一项），

以及MANIFEST.MF中每一个摘要项的摘要值。我也没搞清楚为什么要引入CERT.SF，实际上我也觉得签名完全可以用MANIFEST.MF生成。
验证所有的摘要都是MANIFEST.MF条目：
首先：对应MANIFEST.MF文件，对应的消息摘要为SHA1-Digest-Manifest: nGpBbfOirA4fsY0pn0dBONop5bQ=，对应的实际消息摘要如图4所示。

图4 MANIFEST.MF消息摘要和对应的base64编码

 

其次：验证条目的消息摘要，根据条目消息摘要的算法知道内容格式为SHA1("Name: filename"+CR+LF+"SHA1-Digest: "+SHA1(file_content)+CR+LF+CR+LF)

我先把CERT.SF中的一项取出来，然后验证，取出

在将MANIFEST.MF条目取出，保存为“新建文本文档.txt”，查看对应的消息摘要，并将其转换为base64编码，如图5所示。

图5 新建文本文档.txt的消息摘要和对应的base64编码

这里完成了对CERT.SF的验证。

 

代码为：

这个文件保存了签名和公钥证书。签名的生成一定会有私钥参与，签名用到的信息摘要就是CERT.SF内容。
signature这个数据会作为签名用到的摘要，writeSignatureBlock函数用privateKey对signature加密生成签名，然后把签名和公钥证书一起保存到CERT.RSA中。
最终保存在CERT.RSA中的是CERT.SF的数字签名，签名使用privateKey生成的，签名算法会在publicKey中定义。同时还会把publicKey存放在CERT.RSA中，也就是说CERT.RSA包含了签名和签名用到的证书。并且要求这个证书是自签名的。
提取CERT.RSA信息：

参考有RSA公钥信息、subject信息、对应的签名信息。