dalvik.system.PathClassLoader[DexPathList[[directory “.”],nativeLibraryDirectories=[/system/lib64, /vendor/lib64, /system/lib64, /vendor/lib64]]]

查看源码可以看到PathClassLoader是继承自BaseDexClassLoader的,而PathClassLoader还有另外两个兄弟: InMemoryDexClassLoader以及DexClassLoader,而壳程序很多都使用了这两个类加载器来加载解密后的dex文件。其中InMemoryDexClassLoader是Android8.0以后新增的类,可以实现所谓的"不落地加载"。
总结一下,主要有如下几个ClassLoader:

  1. BootClassLoader: 加载系统核心类的加载器,由系统创建
  2. BaseDexClassLoader: 加载dex文件的基类加载器
  3. PathClassLoader: 加载应用程序开发者自己编写的代码的加载器,比如四大组件类,它继承自BaseDexClassLoader
  4. DexClassLoader: 从源码中可以看到几乎和BaseDexClassLoader没有区别,它继承自BaseDexClassLoader,一般用于实现插件化和加壳
  5. InMemoryDexClassLoader: 通过ByteBuffer数组来加载dex的加载器,它继承自BaseDexClassLoader
  6. 自定义ClassLoader: 可以实现想实现的任何功能

前面说过壳加载完原始的dex以后还需要对ClassLoader进行修正,否则加载组件类运行的时候会报ClassNotFoundException,为什么会报这种错误呢? 这就涉及到了组件类的创建过程,比如对于Activity来说,应用程序的Activity对象是在ActivityThread类的performLaunchActivity()方法中通过调用mInstrumentation.newActivity()创建出来的,这个函数的实现逻辑为:

Android项目 默认没有so文件夹_加载

可以看到是通过ClassLoader先加载Activity类,再通过newInstance()来实现化类对象。

这个方法传递进来的ClassLoader是加载应用程序的ClassLoader,它所加载的dex为应用程序的主体的dex,对应的DexPathList是没有原始的dex路径的,因此会报ClassNotFoundException。这里也可以看出,一个BaseClassLoader对应着其实是一个Dex文件的列表,如果尝试让BaseClassLoader加载不在这个列表中的类,就会报ClassNotFoundException

为了解决上面的问题,可以有两种解决方案:

  1. 替换系统组件类加载器为我们的DexClassLoader,同时设置DexClassLoader的parent为系统组件类加载器
  2. 打包原有的双亲关系,在系统组件类加载器和BootClassLoader的中间插入我们的DexClassLoader,即加载原始dex的DexClassLoader作为PathClassLoader的parent

第一种解决方案是将系统组件类替换,这样通过mInstrumentation.newActivity()试图加载类的时候,就能找到相应的类。
第二种解决方案将ClassLoader的继承关系修改为: BootClassLoader --> DexClassLoader --> PathClassLoader,由于双亲委派机制的存在,当PathClassLoader找不到动态加载的原始dex时,它会请求parent即DexClassLoader加载,因此可以加载成功。
还有一些壳是通过对PathClassLoader中的Elements数组进行合并来达到目的,这样的好处是当你试图用Frida枚举ClassLoader对象的时候,看不到额外的ClassLoader对象,也就无法轻易的得到Dex文件加载的路径。


五. 通用整体脱壳方法:

从上面的内容可以得知,加载Dex有很多种实现方式,每种壳的实现都不一定相同,如果想实现一个比较通用的整体脱壳方法,就必须寻找一个壳绕不开的方式来实现。这个关键的数据结构就是art虚拟机中定义的类art::DexFile,它的定义位于art/runtime/dex_file.h文件中。
这个类有两个成员变量,分别代表着dex文件加载到内存当中的起始地址以及大小,得到这两个信息以后通过内存dump的方式就可以轻轻松松的将dex文件dump下来。
这就表示一个事实: 在某个时机点内存当中一定会有解密后的完整dex存在。

Android项目 默认没有so文件夹_加载_02

art::DexFile是加载dex绕不开的类,不论是使用BaseClassLoader,还是自定义类加载器,最终都需要art::DexFile,这一结论可以通过查阅class_linker.cc文件中的函数得到,像ClassLinker::DefineClassClassLinker::LoadMethodClassLinker::LoadClassMembers这些重量级函数都需要以DexFile对象做为参数:

Android项目 默认没有so文件夹_Java_03

Android项目 默认没有so文件夹_Android项目 默认没有so文件夹_04

Android项目 默认没有so文件夹_Android项目 默认没有so文件夹_05

通过BaseDexClassLoader来加载类会执行art/runtime/native/dalvik_system_DexFile.ccDexFile_defineClassNative函数,这个函数的实现就是遍历Java层的DexFilemCookie对象所表示的native层的art::DexFile,因为这个art::DexFile对象代表了dex文件在内存中的结构,所以可以通过类名在art::DexFile列表中查找到DexFile::ClassDef结构,才能继续调用ClassLinker::DefineClass()函数,最终才能得到一个虚拟机实现中的Class对象表示mirror::Class*,因此这个流程仍然离不开虚拟机中的art::DexFile类。

Android项目 默认没有so文件夹_Java_06

这还会引发出一个问题:
art虚拟机执行smail指令可以解释执行,这种模式叫Interpreter模式(很显然解释模式下需要dex文件存在于内存当中才能解释执行)
也可以执行oat以后elf文件中的本地机器指令,这种模式叫quick code模式。
在quick code模式中,dex编译出来的机器指令包含在dex2oat生成出来的oat文件中(对于app来说,oat文件以.odex结尾),那么对于quick code模式是否还需要dex文件呢?如果不需要dex文件,是不是就无法在内存中dump出dex文件了?

事实上quick code模式内存中也是会有原始的dex文件存在的,具体的执行逻辑在Runtime的GetOatFileManager().OpenDexFilesFromOat()函数中,在这个函数中如果走dex2oat流程的话就会执行oat_file_assistant.MakeUpToDate()调用dex2oat命令生成odex和vdex文件,并生成OatFile类的对象,这个类就代表着dex2oat以后oat文件在内存中的映射表示,oat文件其实就是可执行文件,只不过它有特殊的几个符号:oatdata,oatlastword,oatbss,oatbsslastword等,OatFile类中的成员变量oat_dex_files_storage_是个std::vector<const OatDexFile*>类型的变量,而OatDexFile类表示的是这个oat文件所对应的dex文件的信息(列表),通过OatDexFiledex_file_pointer_即可以找到对应的art::DexFile对象的地址。
在android8.0以后,oat文件存放着dex文件编译出来的可执行指令,而原始的dex内容其实存放在vdex文件中,这一点可以在后面的dump程序中看到。
在quick code模式下也需要原始dex的存在的原因是dex文件还存放着类相关的信息,如class_def_item,method_id_item,对于类方法的执行还离不开这些信息。

六. 整体脱壳实践:

既然知道虚拟机中的art::DexFile类是dex在内存中的表示,那么得到这个对象就可以dump出dex文件。
接下来就是寻找一个合适的点可以得到art::DexFile对象,得到对象以后通过hook的方式或者修改源码的方式都可以dump下来了。
下面是脱函数抽取型壳fart的作者寒冰大佬所提出的办法:
找到libart.so文件中所有导出函数中带有art::DexFile参数或者返回值的函数,那么这就是一个可以脱壳的点
我写了一个命令可以查找满足这种条件的函数:

arm64-readelf -s libart.so -W | tr -s ’ ’ | cut -f9 -d ’ '| c++filt | grep “art::DexFile”

比如在art/runtime/dex_file.ccDexFile::OpenCommon或者DexFile::DexFile中添加如下代码即可脱壳:

pid_t pid = getpid();
 char dexfilepath[100] = {0};
 sprintf(dexfilepath,“/sdcard/drdump_%d_%d_DexFile.dex”,(int)size,(int) pid);
 int fd = open(dexfilepath, O_CREAT | O_RDWR , 666);
 if (fd > 0){
 int number = write(fd,base,size);
 if(number > 0){
 }
 close(fd);
 }

这种是修改源码的方式来脱壳。


还有一种方式是通过frida hook来脱壳,它的优点是简单有效,不需要重新编译rom。
它的原理如下:
对于通过使用BaseDexClassLoader来加载的程序来说,DexFile.java类的mCookie变量在native层的表现其实是一个jlong类型的指针的数组,数组的个数为此ClassLoader加载的dex文件个数 + 1,第一个元素类型为OatFile*,剩余的元素为对应的art::DexFile*,因此可以通过获取mCookie变量来得到art::DexFile*列表,并且通过art::DexFile的begin_和size_来dump。
代码如下:

function hasOwnProperty(obj, name) {
 try {
 return obj.hasOwnProperty(name) || name in obj;
 } catch (e) {
 return obj.hasOwnProperty(name)
 }
 }function getHandle(object) {
 var result = null;
 if (hasOwnProperty(object, "KaTeX parse error: Expected '}', got 'EOF' at end of input: …esult = object.handle;
 if (result) {
 return result;
 }
 }
 if (hasOwnProperty(object, "KaTeX parse error: Expected '}', got 'EOF' at end of input: … return object.h;
 }return null;
 }function dump_dex(packagename, dexfilebegin, dexfilesize) {
 var dexfile_path = “/sdcard/my_frida_dump_” + packagename + “_” + dexfilesize + “.dex”;
 var dexfile_handle = new File(dexfile_path, “w”);
 if (dexfile_handle && dexfile_handle != null) {
 var dex_buffer = ptr(dexfilebegin).readByteArray(dexfilesize);
 dexfile_handle.write(dex_buffer);
 dexfile_handle.flush();
 dexfile_handle.close();
 }
 }function dealwithClassLoader(classloaderobj, packagename) {
 if (Java.available) {
 Java.perform(function () {
 try {
 var dexfileclass = Java.use(“dalvik.system.DexFile”);
 var BaseDexClassLoaderclass = Java.use(“dalvik.system.BaseDexClassLoader”);
 var DexPathListclass = Java.use(“dalvik.system.DexPathList”);
 var Elementclass = Java.use(“dalvik.system.DexPathList$Element”);
 var basedexclassloaderobj = Java.cast(classloaderobj, BaseDexClassLoaderclass);
 var tmpobj = basedexclassloaderobj.pathList.value;
 var pathlistobj = Java.cast(tmpobj, DexPathListclass);
 console.log(“pathlistobj->” + pathlistobj);
 var dexElementsobj = pathlistobj.dexElements.value;
 console.log(“dexElementsobj->” + dexElementsobj);
 for (var i in dexElementsobj) {
 var obj = dexElementsobj[i];
 var elementobj = Java.cast(obj, Elementclass);
 console.log(“elementobj->” + elementobj);
 tmpobj = elementobj.dexFile.value;
 var dexfileobj = Java.cast(tmpobj, dexfileclass);
 var mCookie = dexfileobj.mInternalCookie.value;
 var mInternalCookie = dexfileobj.mInternalCookie.value;
 if (mCookie != null) {
 var jnienv = Java.vm.tryGetEnv();
 var cookiePtr = getHandle(mCookie);
 var arrayLength = jnienv.getArrayLength(cookiePtr);
 var long_data = jnienv.getLongArrayElements(cookiePtr, 0);
 console.log(“arrayLength:” + arrayLength + “,long_data:” + long_data);
 for (var i = 1; i < arrayLength; i++) {
 var dexfileptr = Memory.readPointer(ptr(long_data).add(8 * i));
 var dexfilebegin = Memory.readPointer(ptr(dexfileptr).add(Process.pointerSize * 1));
 var dexfilesize = Memory.readU32(ptr(dexfileptr).add(Process.pointerSize * 2));
 console.log(“pointer:” + dexfileptr + “,dexfilebegin:” + dexfilebegin + “,dexfilesize:” + dexfilesize);
 dump_dex(packagename, dexfilebegin, dexfilesize);
 }
 }
 }
 } catch (e) {
 console.log(e);
 }});
 }}
function tuoke(packagename) {
 if (Java.available) {
 Java.perform(function () {
 console.log(“go into enumerateClassLoaders!”);
 Java.enumerateClassLoadersSync().forEach(function (loader) {
 if (loader.toString().indexOf(“BootClassLoader”) >= 0) {
 console.log(“this is a BootClassLoader!”)
 } else {
 try {
 console.log("classloader : " + loader);
 dealwithClassLoader(loader, packagename);
 } catch (e) {
 console.log(e);