安卓逆向第八篇:脱壳原理分析

• BootClassLoader：其他加载器父类。
  
• PathClassLoader：默认的类加载器。
  
• DexClassLoader： 可以加载恣意地方的类的加载器。以是也是插件化、热修复、加壳的重点
  
• InMemoryDexClassLoader： 这个是安卓8之后的内存加载dex
  尚有许多其他的。暂不思量。用到再说。尚有什么双亲委派机制能。不讲那么细了。说多了不轻易明确
  

• 一代壳：dex整体套起来了
  
• 二代壳：类、函数啥的还在，内里代码为空，比如：func main(){}
  
• 三代壳：java的native化。代码不dex,跑so里去了，告急两类：vmp、dex2c
  

• vmp： ADVMP
  
• dex2c:   dcc
  

• 函数的 注册地点类似 , 而且 函数逻辑相似 , 则利用的是 VMP 加壳 ;
  
• 函数的 注册地点差别 , 而且 函数逻辑不相似 , 则利用的是 Dex2C 加壳 ;
  

• 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
  

• file_magic.cc#OpenAndReadMagic 函数
  
• 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了

ART 下的函数抽取恢复机会 :

• 恢复抽取函数早于 oat 文件编译 : 在 ART 假造机下 , 必要将 dex 文件编译天生为 oat 文件 , 将 dex 文件中的 函数指令 抽取出来 , 必须 在 天生 oat 文件之前 , 将从 抽取的函数指令恢复 ;
  
• 禁用 dex2oat 机制 : 如果 禁用 dex2oat 的编译过程 , 则 恢复 被抽取的 函数指令 , 不在受 该条件限定 , 不是必须在 dex2oat 之前恢复 , 可以稍晚一些再恢复函数指令 ;
  

如果选择第一种方案 , 在 dex2oat 之前举行恢复 , 这没有任何意义 , dex2oat 编译后 , 天生的 oat 文件是完备的 , 此时 可以 完备的将 oat 文件 dump 到 SD 卡中 , 根本便是没有加固 , 还是一个一代壳 ;
因此 , 大部分加固厂商 , 选择 禁用 dex2oat 机制 ; 如许处于安全思量 , 断送了应用的运行服从 ;
此人博客2021年12月12日--20日有多篇脱壳加壳详细文章，感爱好可读。