切入正题,胡小毛在学习Android逆向的过程中又有所总结,先来看看apk文件结构:
首先拿一款普通app讲解,用zip压缩文件打开会出现以下文件夹:
看完了上面的apk的文件结构,我就要开始我们的正戏了,首先是“小二,上图~,上长图~”
放心,不是表情包
上图就是一个apk包的细化打包流程,包含了每个细化过程可能会用到的工具,各位看官可多注意橘色标注字体部分。然后我们再看一下应用安装涉及到的如下几个目录:
system/app ---------------系统自带的应用程序,获得adb root权限才能删除data/app ---------------用户程序安装的目录。安装时把apk文件复制到此目录data/data ---------------存放应用程序的数据data/dalvik-cache--------将apk中的dex文件安装到dalvik-cache目录下(dex文件是dalvik虚拟机的可执行文件,其大小约为原始apk文件大小的四分之一) |
---|
安装过程具体表现为:
复制APK安装包到data/app目录下,解压并扫描安装包,把dex文件(Dalvik字节码)保存到dalvik-cache目录,并在data/data目录下创建对应的应用数据目录。
对应的卸载过程为:
删除安装过程中在上述三个目录下创建的文件及目录。
有事好好说,没事干啥提虚拟机啊,胡小毛也是搞得我晕头转向,莫慌,仔细瞧瞧,发现小毛得学习思路还是可圈可点得。上面提到得dalvik虚拟机,可能并未引起各位看官的注意力,所以这边再多唠叨一遍。
首先是java虚拟机,我们知道java语言有一个很重要的特性就是“跨平台”可以做到“一次编译,到处运行”的效果。怎样才能有这样的特性呢?主要就是依靠的java虚拟机(JVM)。当我们编写好一个java程序之后如test.java。然后将其编译为一个字节码文件test.class。在java虚拟机上运行这个字节码文件,java虚拟机就可以把字节码文件解释成具体平台上的机器指令执行,而实现了java的跨平台特性。
然后我们需要知道的是Android是基于Dalvik虚拟机(DVM)或art虚拟机(aot机制)的。Dalvik虚拟机主要应用于Android5.0及以前,而ART(Android Runtime)虚拟机是 Android 4.4 发布的,用来替换 Dalvik 虚拟机,Android 4.4 默认采用 DVM,但是可以选择使用 ART。在 Android 5.0 版本中默认使用 ART,DVM 从此退出历史舞台。
具体可参考:https://www.jianshu.com/p/a37d3be0a341。
而JDM、DVM、ART之间的关系可参考下图:
2、对MANIFEST.MF整个文件做一次算法(数据SHA1摘要+Base64编码),存放到CERT.SF文件的头属性中,再对MANIFEST.MF文件中各个属性块做一次算法(数据SHA1摘要+Base64编码),存到到一个属性块中。
3、对CERT.SF文件做签名,内容存档到CERT.RSA中,所以CERT.RSA是一个加密文件,所以它长的很难看,不信的自己去看:
了解了上面apk的签名过程,我们可以深入思考一下下面这段话(某大神原话):
假如我们是一个非法者,想要篡改apk内容,我们怎么做呢?如果我们只把原文件改动了(比如加入了自己的病毒代码),那么重新打包后系统就会认为文件的SHA1-Base64值和MF的不一致导致安装失败,既然这样,那我们就改一下MF让他们一致呗?如果只是这样那么系统就会发现MF文件的内容的SHA1-Base64与SF不一致,还是会安装失败,既然这样,那我们就改一下SF和MF一致呗?如果这么做了,系统就会发现RSA解密后的值和SF的SHA1不一致,安装失败。那么我们让加密后的值和SF的SHA1一致就好了呗,但是呢,这个用来签名加密的是私钥,公钥随便玩,但是私钥我们却没有,所以没法做到一致。所以说上面的过程环环相扣,最后指向了RSA非对称加密的保证。
最后我们必须要知道签名机制只是保证了apk的完整性,具体是不是自己的apk包,系统并不知道,所以对于上面的通过apk签名进行完整性校验,攻击者可以通过直接重签名,让所有的信息都一致就能绕过校验,这样重签名后就可以安装了。所以对于应用签名是否被篡改,那就是另一门学问了……
参考链接:
1、https://blog.csdn.net/loongago/article/details/89646920
2、https://www.jianshu.com/p/a37d3be0a341
3、https://blog.csdn.net/lostinai/article/details/54694564?utm_source=blogxgwz3