如果你是想直接用

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

image.png

扩展一下

https://github.com/lasting-yang/frida_dump/blob/master/dump_dex.js
这里yang的脱壳代码也是通过扫内存然后通过魔数来判断存不存的，当然缺陷也很明显，抹头的dex dump不出来。

image.png

image.png

加壳原理：

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

• 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

image.png

一、InMemoryDexClassLoader 类加载器脱壳点总结

1. dalvik_system_DexFile.cc#CreateSingleDexFileCookie
2. dalvik_system_DexFile.cc#CreateDexFile
3. dex_file.cc#DexFile::Open
4. dex_file.cc#DexFile::OpenCommon
5. dex_file.cc#DexFile::DexFile

二、ART 虚拟机下 DexClassLoader 类加载器脱壳点总结

1. file_magic.cc#OpenAndReadMagic 函数
2. dex_file.cc#DexFile::OpenCommon
3. 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日有多篇脱壳加壳详细文章，感兴趣可读。

——————————————————
暂时更新此处，本周内在此篇继续更

参考文献：
https://blog.51cto.com/u_15101562/2622410