如果你是想直接用
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开头的,比如
图里要把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 加壳 ;
- 函数的 注册地点差别 , 而且 函数逻辑不相似 , 则利用的是 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:
 exFile
二、ART 假造机下 DexClassLoader 类加载器脱壳点总结
- file_magic.cc#OpenAndReadMagic 函数
- dex_file.cc#DexFile::OpenCommon
- dex_file.cc#DexFile:exFile
这两种方式都有dex_file.cc#DexFile::OpenCommon和dex_file.cc#DexFile:exFile
总结：
加固厂商大概利用 InMemoryDexClassLoader 类加载器 , 也大概利用 DexClassLoader 类加载器 , 这里为了包管不管利用什么类加载器 , 都可以举行脱壳 , 选择 2个类加载器都有的脱壳点 , 可以兼容两种类加载器 ;这两种方式都有dex_file.cc#DexFile::OpenCommon和dex_file.cc#DexFile:exFile，就可以选择他俩。把传进来的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 |
