安卓逆向第八篇:脱壳原理分析
如果你是想直接用
FART github
直接装完一用就行了。
本文完！
如果想继续了解
注意点：
1、多dex：
使用脱完之后，可能会有很多dex文件。fart脱出来的dex文件会伴随着同名的txt文件。如果有想找的类名，可以grep类名到txt文件找，然后再找同名的dex。
2、打开异常：
可能是dex的开头魔数故障
https://blog.csdn.net/sinat_18268881/article/details/55832757
这里有解释魔数是什么。大概意思是用010Editor打开。开头是dex.035开头的。
问题的出现可能是魔数没了，或者开头不是dex.035开头的,比如
image.png
图里要把dex035前面的都删了。
如果没有魔数的，开头全是00000000，就把别的有魔数的直接粘过来就行
image.png
扩展一下
https://github.com/lasting-yang/frida_dump/blob/master/dump_dex.js
这里yang的脱壳代码也是通过扫内存然后通过魔数来判断存不存的，当然缺陷也很明显，抹头的dex dump不出来。
image.png
这个是葫芦娃的frida脱壳
https://github.com/hluwa/frida-dexdump/blob/master/frida_dexdump/agent/agent.js
image.png
加壳原理：
安卓有很多类加载器：(主要看后两个)
- BootClassLoader：其他加载器父类。
- PathClassLoader：默认的类加载器。
- DexClassLoader： 可以加载任意地方的类的加载器。所以也是插件化、热修复、加壳的重点
- InMemoryDexClassLoader： 这个是安卓8之后的内存加载dex
还有很多其他的。暂不考虑。用到再说。还有什么双亲委派机制能。不讲那么细了。说多了不容易理解
这里因为能动态加载类，只要壳厂商能自定义DexClassLoader，然后在壳想用的时候加载就ojbk了。
几代壳：
- 一代壳：dex整体套起来了
- 二代壳：类、函数啥的还在，里面代码为空，比如：func main(){}
- 三代壳：java的native化。代码不dex,跑so里去了，主要两类：vmp、dex2c
vmp、dex2c
开源代表作：
分辨：
- 函数的 注册地址相同 , 并且 函数逻辑相似 , 则使用的是 VMP 加壳 ;
- 函数的 注册地址不同 , 并且 函数逻辑不相似 , 则使用的是 Dex2C 加壳 ;
方法：
adb logcat | grep Acticity.onCreate
看一下每次切换Acticity。日志里FromJni:0X地址 看一下每次地址是否相同。
通用脱壳法：
因为刚才提到了InMemoryDexClassLoader和DexClassLoader
然后去源码里看http://www.aospxref.com/android-8.1.0_r81
image.png
就像这样 一层一层往上找，一直找到C代码。找到这些。
一、InMemoryDexClassLoader 类加载器脱壳点总结
- dalvik_system_DexFile.cc#CreateSingleDexFileCookie
- dalvik_system_DexFile.cc#CreateDexFile
- dex_file.cc#DexFile::Open
- dex_file.cc#DexFile::OpenCommon
- dex_file.cc#DexFile::DexFile
二、ART 虚拟机下 DexClassLoader 类加载器脱壳点总结
- file_magic.cc#OpenAndReadMagic 函数
- dex_file.cc#DexFile::OpenCommon
- dex_file.cc#DexFile::DexFile
这两种方式都有dex_file.cc#DexFile::OpenCommon和dex_file.cc#DexFile::DexFile
总结：
加固厂商可能使用 InMemoryDexClassLoader 类加载器 , 也可能使用 DexClassLoader 类加载器 , 这里为了保证不管使用什么类加载器 , 都可以进行脱壳 , 选择 2个类加载器都有的脱壳点 , 可以兼容两种类加载器 ;这两种方式都有dex_file.cc#DexFile::OpenCommon和dex_file.cc#DexFile::DexFile，就可以选择他俩。把传进来的dex保存下来就ojbk了
修改系统源码式的脱壳代码编写：↓
https://hanshuliang.blog.csdn.net/article/details/121964509?spm=1001.2014.3001.5502
找到上面说的那些时候还有一点提一下：
【Android 逆向】ART 函数抽取加壳 ( ART 下的函数抽取恢复时机 | 禁用 dex2oat 机制源码分析 )
这篇文章讲的主要的点是art下的时候，Dalvik虚拟机下没这么多事而且由于系统有点老这里就不谈了。
首先它给app加壳了，用的时候总要恢复。找恢复的时机是个比较重要的点。art虚拟机为了让app运行的更快搞了个预编译也就是dex2oat。
如文章所说
ART 下的函数抽取恢复时机 :
- 恢复抽取函数早于 oat 文件编译 : 在 ART 虚拟机下 , 需要将 dex 文件编译生成为 oat 文件 , 将 dex 文件中的 函数指令 抽取出来 , 必须 在 生成 oat 文件之前 , 将从 抽取的函数指令恢复 ;
- 禁用 dex2oat 机制 : 如果 禁用 dex2oat 的编译过程 , 则 恢复 被抽取的 函数指令 , 不在受 该条件限制 , 不是必须在 dex2oat 之前恢复 , 可以稍晚一些再恢复函数指令 ;
如果选择第一种方案 , 在 dex2oat 之前进行恢复 , 这没有任何意义 , dex2oat 编译后 , 生成的 oat 文件是完整的 , 此时 可以 完整的将 oat 文件 dump 到 SD 卡中 , 基本等于没有加固 , 还是一个一代壳 ;
因此 , 大部分加固厂商 , 选择 禁用 dex2oat 机制 ; 这样处于安全考虑 , 牺牲了应用的运行效率 ;
此人博客2021年12月12日--20日有多篇脱壳加壳详细文章，感兴趣可读。
——————————————————
暂时更新此处，本周内在此篇继续更
