在Android的apk包中含有一个叫做META-INF的文件夹，这个里边存储的是关于签名的一些信息。

其中将apk包解压出来，进入META-INF目录，发现会有3个文件：CERT.RSA，CERT.SF，MANIFEST.MF。

MAINFEST.MF

用记事本打开MANIFEST.MF文件，这是个可读的文本文件，大约内容如下：

1
2
3
4
5
6
7
8

Manifest-Version: 1.0
Created-By: 1.0 (Android)

Name: res/drawable-hdpi/shop_search_bg.png
SHA1-Digest: OgQ5gmKTFoxuZWAaKBBJKl1Oy24=

Name: res/drawable/merchant_btn_selector.xml
SHA1-Digest: AkxLT25+wtnL6DCN10rcSTpz6kM=

版本号以及对每一个文件的哈希值（BASE64）。包括资源文件。这个是对每个文件的整体进行SHA1 hash

（1）MANIFEST.MF：这是摘要文件。程序遍历Apk包中的所有文件(entry)，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码。如果你改变了apk包中的文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是程序就不能成功安装。

说明：如果攻击者修改了程序的内容，有重新生成了新的摘要，那么就可以通过验证，所以这是一个非常简单的验证。

看到跟manifest.mf中的很类似，也是BASE64编码的哈希值，这个是对每个文件的头3行进行SHA1 hash。
这两个文件中的内容仅仅是个摘要，也就是仅仅对文件做个hash。

CERT.SF

然后是CERT.SF文件，用记事本打开，内容如下：

1
2
3
4
5
6
7
8
9
10
11

Signature-Version: 1.0
Created-By: 1.0 (Android)
SHA1-Digest-Manifest: I2tqVFgbG+PZh6o8SWuDePSrTcQ=

Name: res/drawable-hdpi/shop_search_bg.png
SHA1-Digest: twMIUeZAdwmMBjIDlo/5EiSFWj0=

Name: res/drawable/merchant_btn_selector.xml
SHA1-Digest: GJqtJ+iUO4Xrjgzri8nzR+GDLVU=

（2）CERT.SF：这是对摘要的签名文件。对前一步生成的MANIFEST.MF，使用SHA1-RSA算法，用开发者的私钥进行签名。在安装时只能使用公钥才能解密它。解密之后，将它与未加密的摘要信息（即，MANIFEST.MF文件）进行对比，如果相符，则表明内容没有被异常修改。

说明：在这一步，即使开发者修改了程序内容，并生成了新的摘要文件，但是攻击者没有开发者的私钥，所以不能生成正确的签名文件（CERT.SF）。系统在对程序进行验证的时候，用开发者公钥对不正确的签名文件进行解密，得到的结果和摘要文件（MANIFEST.MF）对应不起来，所以不能通过检验，不能成功安装文件。

CERT.RSA

最后一个文件是CERT.RSA，这个文件中放的是apk包的签名，同时还有证书的公钥。

一般来说，证书的内容是：开发者信息+开发者公钥 +CA的签名（ CA对前两部分做hash值然后私钥加密之后的密文）

验证过程是：用CA公钥对括号里的内容解密，然后对前两部分hash，跟CA的签名进行对比，看是否相同。

暂时不知道Android中既然已经有了对整个文件的摘要，为什么还要弄个前3行的摘要。

（3）CERT.RSA文件中保存了公钥、所采用的加密算法等信息。

说明：系统对签名文件进行解密，所需要的公钥就是从这个文件里取出来的。

结论：从上面的总结可以看出，META-INFO里面的说那个文件环环相扣，从而保证Android程序的安全性。（只是防止开发者的程序不被攻击者修改，如果开发者的公私钥对对攻击者得到或者开发者开发出攻击程序，Android系统都无法检测出来。）

猜想：

cert.rsa这个文件中应该存放的是开发者信息+开发者公钥+开发者签名【自己就是CA】（对前两部分的hash用自己私钥做加密），

解密过程应该是：首先提取自己公钥，然后对自己加密的那部分解密，然后对前2部分做hash进行比对，模拟跟验证证书。然后再用公钥依次验证每一个文件的摘要看是否正确。

FROM :b0urne.top | Author:b0urne