Dalvik源码阅读笔记（二）

DVM 类加载原理：

DEX 文件加载到内存中 DvmDex 结构后，还没有完成类的解析工作，我们将 DEX 中的类填充到 ClassObject 结构的过程称为类加载。

ClassObject 用来描述一个完整的类，其中 Method 结构用于描述类的方法：

struct ClassObject : Object {
    -- snip -- 
    /* static, private, and <init> methods */
    int             directMethodCount;
    Method*         directMethods;
    /* virtual methods defined in this class; invoked through vtable */
    int             virtualMethodCount;
    Method*         virtualMethods;
    -- snip -- 
};

其包含了指令位置指针：

struct Method {
    -- snip --
    /* the actual code */
    const u2*       insns;          /* instructions, in memory-mapped .dex */
    -- snip --
};

Android DVM 提供了三种类加载方法：

（1）使用 Class.forName 显式加载
（2）使用 ClassLoader.loadClass 显式加载
（3）隐式加载，比如 new 操作符，当相应类未被访问过时，则发生隐式加载

其中，

Class.forName 调用 DVM 的 Dalvik_java_lang_Class_classForName 函数；
ClassLoader.loadClass 调用 Dalvik_dalvik_system_DexFile_defineClassNative 函数；
隐式加载调用 dvmResolveClass 函数；

调用关系如下：

 

DEX dump 时机：

观察 Dalvik_dalvik_system_DexFile_defineClassNative 函数实现：

static void Dalvik_dalvik_system_DexFile_defineClassNative(const u4* args,
    JValue* pResult)
{
    -- snip --
    if (pDexOrJar->isDex)
        pDvmDex = dvmGetRawDexFileDex(pDexOrJar->pRawDexFile);
    else
        pDvmDex = dvmGetJarFileDex(pDexOrJar->pJarFile);
    
    clazz = dvmDefineClass(pDvmDex, descriptor, loader);
    -- snip --
}

选取这个函数插入脱壳代码的原因有以下：

1. 函数位于关键路径
   无论何种类加载方式，必然会执行到 Dalvik_dalvik_system_DexFile_defineClassNative 函数

2. 包含内存中 DEX 结构，且可以通过 pDexOrJar->fileName 匹配 APK
   通过 pDvmDex = dvmGetJarFileDex(pDexOrJar->pJarFile) 处代码，可以取到内存中 DEX 文件结构信息，这些信息包括：

/*
 * Internal struct for managing DexFile.
 */
struct DexOrJar {
    char*       fileName;   // Unique String，可用来命中待脱壳 APP
    bool        isDex;
    bool        okayToFree;
    RawDexFile* pRawDexFile;
    JarFile*    pJarFile;   // 内存中 zip（APK） 文件结构
    u1*         pDexMemory; // malloc()ed memory, if any
};

pDvmDex 表示一个打开的 ODEX 文件，DvmDex 结构体有一个 memMap 成员，用来表示 ODEX 文件对应的内存信息：

/*
 * Some additional VM data structures that are associated with the DEX file.
 */
struct DvmDex {
    -- snip -- 
    /* shared memory region with file contents */
    bool                isMappedReadOnly;
    MemMapping          memMap;
    -- snip --
};

其中 addr 代表这块内存起始地址，length 代表这块内存大小：

/*
 * Use this to keep track of mapped segments.
 */
struct MemMapping {
    void*   addr;           /* start of data */
    size_t  length;         /* length of data */

    void*   baseAddr;       /* page-aligned base address */
    size_t  baseLength;     /* length of mapping */
};

想要 dump 目标 DEX，只需匹配 pDexOrJar->fileName 到相应的 fileName 时，通过 memMap->addr 和 memMap->length 定位到 ODEX 的内存位置， dump 出来即可。

ODEX 文件是为了提高 DVM 运行效率而设计的，它通过将引用到的 framework APIs 替换成预加载 vtable 的索引，提高方法查找和运行效率，因此 ODEX 是与具体设备强相关的，更具体来说是与 /system/framework 目录下的 odex 文件强相关的。

通过 backsmali 与 /system/framework 下 odex，便可以将 ODEX 恢复为 DEX 文件，网上有很多这方面材料，不再赘述。

解决几个问题：

目前，仍然有一个值得关注的问题：一个类加载完，其初始化（如<clinit>）可能仍未执行。

由于 <clinit> 先于其他任何类方法执行，因此加固程序可以在 <clinit> 中做些手脚，实现对方法指令的动态修改，即初始化前我们 dump 出的 DEX 可能完全是错的。

解决办法是，使用 dvmDefineClass 遍历 DEX 的所有类，通过 dvmIsClassInitialized 判断类是否已经初始化过，并调用 dvmInitClass 主动初始化所有类。这样内存中的类，都是初始化过的，这时便可以 dump 出相对正确的 ODEX 文件。

另外还有一个问题：

 

图中标志的 code_off 表示一个 direct_method 方法的指令字节码相对于 ODEX 头的偏移，而它的取值范围完全可以在 ODEX 内存区域之外，因此如果单纯根据 memMap 的 addr 和 length 进行 dump， 可能缺失关键的指令数据。解决办法是将不在 ODEX 内存区域的指令单独存储为一个 extra 文件中附在 dump 出的 ODEX 之后，并修复 code_off 等偏移。

Dexhunter 的弱点：

DexHunter 通过在类加载过程中插入代码，主动遍历并初始化所有类，然后进行内存 dump。但在类初始化完成后，DVM 并不保证方法指令正确。

因此对抗 DexHunter 的一个办法是，将指令还原选在 Dalvik_dalvik_system_DexFile_defineClassNative 函数执行完，方法指令执行前的某个位置，比如 Hook dvmDefineClass 函数。

另外一个方法是自己实现 Dalvik_dalvik_system_DexFile_defineClassNative 函数，通过 pDexOrJar->fileName 可以发现，360可能用了类似办法。