Black Hat USA 2013 - Android: one root to own them all

最新推荐文章于 2021-10-17 15:16:28 发布

tangsilian

最新推荐文章于 2021-10-17 15:16:28 发布

阅读量269

点赞数

分类专栏： android安全

android安全专栏收录该内容

36 篇文章 4 订阅

订阅专栏

视频：
https://www.youtube.com/watch?v=mCF5kaCt4NI

漏洞挖掘过程
产生漏洞代码分析
漏洞利用

0x00 背景

最近看blackhat上各位大佬关于Android的议题，找到bluebox发现matser key的过程。记录下学习的过程。
在这里插入图片描述
（1）MANIFEST.MF：这是摘要文件。程序遍历Apk包中的所有文件(entry)，对非文件夹非签名文件的文件，逐个用SHA1生成摘要信息，再用Base64进行编码。如果你改变了apk包中的文件，那么在apk安装校验时，改变后的文件摘要信息与MANIFEST.MF的检验信息不同，于是程序就不能成功安装。

说明：这是Android签名验证过程的第一步，保证每个APK包内的每个文件与MANIFEST.MF中的摘要值一一对应，修改某个文件内容，必须修改MANFEST.MF文件中的摘要值，使他们对应起来。

（2）CERT.SF：这是对摘要的签名文件。对前一步生成的MANIFEST.MF，对MANIFEST.MF中的每一条内容分别进行SHA1计算，然后再用Base64编码转换。此外，把MANIFEST.MF的内容也进行SHA1计算，并且计算BASE64编码。将上述内容写入CERT.SF文件中。

说明：这是签名认证过程的第二步，这一步做的是多第一步得到的签名文件的摘要，比如第一步中对文件和MANIFEST.MF摘要都改了，这一步中MANIFEST.MF的摘要值也要修改，否则就对应不起来。

所以，前面这两步，做的都是摘要，是为第三步骤做准备的，第三步骤才是最重要的。

（3）CERT.RSA文件中保存了公钥、所采用的加密算法等信息，此外重要的，还包括对CERT.SF中的内容的用私钥进行加密之后的值。

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

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