安卓逆向:脱壳原理分析

注意点：

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开头的,比如
图里要把dex035前面的都删了。
如果没有魔数的，开头全是00000000，就把别的有魔数的直接粘过来就行
扩展一下
https://github.com/lasting-yang/frida_dump/blob/master/dump_dex.js
这里yang的脱壳代码也是通过扫内存然后通过魔数来判断存不存的，当然缺陷也很明显，抹头的dex dump不出来。

这个是葫芦娃的frida脱壳
https://github.com/hluwa/frida-dexdump/blob/master/frida_dexdump/agent/agent.js

加壳原理：

安卓有很多类加载器：(主要看后两个)

BootClassLoader：其他加载器父类。
PathClassLoader：默认的类加载器。
DexClassLoader： 可以加载任意地方的类的加载器。所以也是插件化、热修复、加壳的重点
InMemoryDexClassLoader： 这个是安卓8之后的内存加载dex
还有很多其他的。暂不考虑。用到再说。还有什么双亲委派机制能。不讲那么细了。说多了不容易理解
这里因为能动态加载类，只要壳厂商能自定义DexClassLoader，然后在壳想用的时候加载就ojbk了。

几代壳：

一代壳：dex整体套起来了
二代壳：类、函数啥的还在，里面代码为空，比如：func main(){}
三代壳：java的native化。代码不dex,跑so里去了，主要两类：vmp、dex2c
vmp、dex2c
开源代表作：
vmp： ADVMP
dex2c: dcc
分辨：
函数的 注册地址相同 , 并且 函数逻辑相似 , 则使用的是 VMP 加壳 ;
函数的 注册地址不同 , 并且 函数逻辑不相似 , 则使用的是 Dex2C 加壳 ;
方法：
adb logcat | grep Acticity.onCreate
看一下每次切换Acticity。日志里FromJni:0X地址 看一下每次地址是否相同。

通用脱壳法：

因为刚才提到了InMemoryDexClassLoader和DexClassLoader
然后去源码里看http://www.aospxref.com/android-8.1.0_r81

就像这样 一层一层往上找，一直找到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