(艾玛,图片都没了,懒得一张张加了,蛋疼)
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文件是这样的,
有几个这样的算法标识:
中间夹个证书,证书里有公钥,还有一些签名时候申请者提供的可以标识开发者信息的信息数据(国家,地区,有效期等等)。
感觉没什么价值呢。就当一个证书分析学习范例吧。