Intro

这个加固是来自国内某个公司的作品，虽然在强度不是太高，但思路却不错，很好的平衡了性能和保护效果。目前看来，分析的这个版本只是一个很初级的框架，如果再此之上进行更多的防护和保护，强度会更好。

加固效果

加固之后，其效果是DEX中某些函数被加上ACC_NATIVE标志，原始的DEX代码已经消失，使得反编译、二次打包等功能失效。而加固之后新增的Libt**.so则负责在运行的时候，还原那些被抽取的Dalvik虚拟机代码。

相关结构

了解一下相关的结构有助于分析：

struct DexClassData {
    DexClassDataHeader header;
    DexField*          staticFields;
    DexField*          instanceFields;
    DexMethod*         directMethods;
    DexMethod*         virtualMethods;
};
struct DexMethod {
    u4 methodIdx;    /* index to a method_id_item */
    u4 accessFlags;
    u4 codeOff;      /* file offset to a code_item */
};
struct DexCode {
    u2  registersSize;
    u2  insSize;
    u2  outsSize;
    u2  triesSize;
    u4  debugInfoOff;       /* file offset to debug info stream */
    u4  insnsSize;          /* size of the insns array, in u2 units */
    u2  insns[1];
    /* followed by optional u2 padding */
    /* followed by try_item[triesSize] */
    /* followed by uleb128 handlersSize */
    /* followed by catch_handler_item[handlersSize] */
};

DexClassData描述了DEX文件中的某个类的相关信息，DexMethod则描述的是这个类的函数的信息。DexMethod的methodIdx是method在method_id_item中的Index，accessFlags描述了这个method的Access Control以及其他的信息，code_off是一个偏移，偏移之后的结构是DexCode结构，这个DexCode描述了method具体的信息。更多的信息可以参考Google的官方文档。
以上是DEX文件中相关的结构，而DVM运行的时候，会用上述的信息构造Method，DVM使用这个结构来执行：

struct Method {
    ClassObject*    clazz;
    u4              accessFlags;
    u2             methodIndex;
    u2              registersSize;  /* ins + locals */
    u2              outsSize;
    u2              insSize;
    const char*     name;
    DexProto        prototype;
    const char*     shorty;
    const u2*       insns;          /* instructions, in memory-mapped .dex */
    int             jniArgInfo;
    DalvikBridgeFunc nativeFunc;
    bool fastJni;
    bool noRef;
    bool shouldTrace;
    const RegisterMap* registerMap;
    bool            inProfile;
};

如果Method.accessFlags没有ACC_NATIVE标志，则insns指向Dalvik虚拟机代码，反之，表明该Method的实现在Native层，insns应该为空。

加固原理

上面说到，加固的效果是抽取了原始的Dalvik虚拟机代码，并且Method被加上了ACC_NATIVE标志。libt**.so在加载的时候，会获取这些method对应的Method结构，去掉accessFlags中的ACC_NATIVE标志，并且将insns写回这个结构。另外，DVM对insns是有要求的，代码如下：

INLINE const DexCode* dvmGetMethodCode(const Method* meth) {
    if (dvmIsBytecodeMethod(meth)) {
        /*
         * The insns field for a bytecode method actually points at
         * &(DexCode.insns), so we can subtract back to get at the
         * DexCode in front.
         */
        return (const DexCode*)
            (((const u1*) meth->insns) - offsetof(DexCode, insns));
    } else {
        return NULL;
    }
}
INLINE u4 dvmGetMethodInsnsSize(const Method* meth) {
    const DexCode* pCode = dvmGetMethodCode(meth);
    return (pCode == NULL) ? 0 : pCode->insnsSize;
}

可见insns指向的是DexCode中的insns结构，也就是有了Method.insns，就可以得到原始的DexCode结构。

脱壳

进一步分析发现，被这个加固抽取掉的DexCode信息还原封不动的保存在Data section中，而在dex的尾部，新增了一个结构用于描述DexCode和原始函数的关系。libt**.so运行的时候，就是通过这个结构来还原Method中的insns信息。
最后，在smali中加了10来行代码，成功脱掉。

总结

这个加固实现的效果有：

1. 反静态分析
即便是原始的虚拟机代码仍然保存在文件中，但是二者的关系已经被模糊，不经过修改的工具无法得知原始代码的位置。

2. 防止内存Dump
由于针对修复的对象是Method，是DVM内存中的结构体，而原始的odex并没有被修改。

3. 防止二次打包
由于这个加固在DEX尾部添加了一个自定义的结构，baksmali二次打包的时候会导致这些信息丢失，原始函数和虚拟机代码的代码也因此丢失，所以编译之后的程序无法运行。
最后，我分析的这个libt**.so有一处越界的Bug，可能会导致程序崩溃，或者直接篡改任意代码——这有点搞笑……