安卓签名文件研究

（艾玛，图片都没了，懒得一张张加了，蛋疼）

1.     Apk签名之后变化(多出来个meta-inf文件夹)。文件夹包括cert.rsa,cert.sf,manifest.mf三个文件。

2.     Manifest.mf文件保存了。apk里的所有文件逐个生成sha1签名在base64编码的信息。

这地方我做了一个实验。

第一次试验：在解压后的文件夹里随便找了一个文件，打开之后随便加了个字母。这时候我用HaseTab查看该文件的crc32,md5,sha-1值都变了，这时候呢我把文件夹再整成apk文件。结果就安装失败了。

第二次试验：我把修改之后文件的sha1再base64的结果填到manifest.mf文件里，再次制作apk。结果还是安装失败。

 

没有结论。估计是还有别的地方在做校验。

3.     cert.sf文件。该文件保存了manifest.mf文件内容的二次加密结果。具体没仔细验证。

cert.rsa文件(重点)

网上能搜索到

openssl req-new -x509 -key testkey.pem-out testkey.x509.pem -days 10000

 

signapk.jar testkey.x509.pem  testkey.pk8HelloJni_test.apk HelloJni_test_signed.apk

 

这样指令能手动给apk文件进行签名。

可以看出这个文件和pkcs7有莫大的关系。

用hex打开此文件

看到头部的30立马联想到x.509数字证书结构。

         以30作为开始标志，82代表后面两个字节代表长度，034b（16进制），即长度为843。

后面的就。。。asn。1用TLV方式来，就往下推就行。

仔细一对比，还真像。那就用程序来解析一下吧。

 

郭军让我把该文件后缀改为p7b试试。打开之后竟然是这样

这应该就是当时申请签名用的那些信息吧。据说这个文件里头包含公钥。

难道签名用的key文件就是私钥？百度之后得知

Keystore是一个密码保护的文件，存放私钥和证书。

 

FILE* fp;

         fp =fopen("CERT.RSA","rb");

         if (!fp)

         {

                  cout<<"cert.rsa文件读取失败!"<<endl;

         }

 

         PKCS7* p7 = PKCS7_new();

         p7 = d2i_PKCS7_fp(fp,NULL);

         X509* cert =sk_X509_pop(p7->d.sign->cert);

         string strSubjectName =to_string(X509_get_subject_name(cert));

         string strIssuerName = to_string(X509_get_issuer_name(cert));

         char* modulus =BN_bn2dec(X509_get_pubkey(cert)->pkey.rsa->n);

运行结果：

用简单的几个函数就把这个CERT.RSA文件给读出来了。

诸多事实证明,这个CERT.RSA文件就是个p7包。

最后一点就是防止被篡改了，经我上网查阅大量文章博客，基本可以确定只要包里的文件，包括资源，包括代码有改动的话。想二次打包，必须重新签名，签名之后必须改包名。这样在手机上运行的apk和原版apk无论是签名和包名都和原版的不会一样的。如果应用市场能检验这个，或者说和银行或者咱们的服务器进行通信的时候进行个签名比对。经过篡改的应用应该是马上会现出原形的。

不过，我看如果这个签名比对过程如果放在java层的话，是很容易在smali文件里修改，屏蔽这个校验过程的。如果放在ndk层的话，能加大破解难度。

安卓签名文件CERT.RSA文件研究报告

                                                                                                                                   Bydongqing

今天我们拿工行的cert文件下手

打开之后可以看到公钥部分：

既然是打开CERT.p7b(改后缀了)之后的结果，那也就是说公钥肯定在这个文件里。

事实证明，猜测是正确的。也就是说整个cert.p7b文件由

（前段）+ 公钥 + （后段）构成。

 

然后把cert.p7b文件通过系统自带导出成icbc.cer文件。大小是641字节。而cert.p7b文件大小为1006字节。这时候，又一个事实就更清晰了

cert.rsa文件 = 证书（内含公钥） + 其他

 

这时候，突然在网上找到一个专门解析证书的工具asn1view。分析这事情，立马轻松多了。

这是cer文件的前段。

这是cert.p7b文件的相应位置。

好吧，让我们从头开始吧

蓝色部分就是证书之前的部分了

30 表示SEQUENCE类型,长度由2个字节构成，即03 ea(1002),好吧，太长了，往下一量，到cert.p7b文件的结尾正好1002字节，1002+4 = 1006.正好是查看文件信息得出的大小。没骗人，呵呵。

中间这一段呢06指的是OBJECTIDENTIFIER,长度为09,值呢就是

2A 86 48 86 F7 0D 01 07 02

这段代表什么意思呢，在asn1view里头可以看到

这种类型都是OID编码，如果掌握该编码，手动也可以算出他代表的什么东西。

 

接下来看第二个30，大小是03 d7（983），好吧，还是到文件尾的，原来是一个SEQUENCE嵌套。

以下分析就掠过了，都快受不了了。。。

 

中间证书我们先跳过，看看后面一段都有些什么。

首先，发现这么一段

还是OID编码，意思是country name，后面应该就是中行自己填的cn或者china之类的东西了，没意思。

一堆set，别好奇了，我都点开过了，就是国家啊，地区啊，公司啊，之类的信息。

后面就没有什么实际内容了。

接下来，我们来研究一下中间剩下的那一段：咱们证书部分，可能没什么研究价值，权当学习了。

 

其中第一段内容竟然又是国家啊，地区啊，公司啊，之类的信息。

随便扫了几眼，红线圈出来的两部分应该都是一样的

要是记得前面分析的话。整个cert文件的后面一段，就是中间证书后面的一段中就包含这么一段，有图有真相：(对比三张图的左边地址，是三个位置，可这三段内容是一样的。)

谁能告诉我这到底是怎么回事？信息太冗余了吧。。。。还是另有深意。

 

好了，言归正传。

 

现在基本上分析完了，整个cert.rsa文件是这样的，

有几个这样的算法标识：

中间夹个证书，证书里有公钥，还有一些签名时候申请者提供的可以标识开发者信息的信息数据（国家，地区，有效期等等）。

 

感觉没什么价值呢。就当一个证书分析学习范例吧。