Dex动态加载的C语言部分

本文详细分析了Android 4.0中Dex动态加载的C++部分,主要涉及内存加载过程。通过`Dalvik_dalvik_system_DexFile_openDexFile_bytearray`函数,从内存中读取字节数组并创建RawDexFile对象,再进行内存分配、文件内容拷贝和Dex文件打开操作。如果过程中出现异常,会抛出相应的运行时异常。
摘要由CSDN通过智能技术生成

 今天主要来分析Dex动态加载C++语言的部分(Android4.0)

 内存加载:

native代码:private static int openDexFile(byte[] fileContents) throws IOException

所对应的实现如下:

static void Dalvik_dalvik_system_DexFile_openDexFile_bytearray(const u4* args , JValue* pResult)
{
    ArrayObject* fileContentsObj = (ArrayObject*) args[0];
    u4 length;
    u1* pBytes;
    RawDexFile* pRawDexFile;
    DexOrJar* pDexOrJar = NULL;

    if (fileContentsObj == NULL) {
        dvmThrowNullPointerException("fileContents == null");
        RETURN_VOID();
    }

    length = fileContentsObj->length;
    pBytes = (u1*) malloc(length);

    if (pBytes == NULL) {
        dvmThrowRuntimeException("unable to allocate DEX memory");
        RETURN_VOID();
    }

    memcpy(pBytes, fileContentsObj->contents, length);

    if (dvmRawDexFileOpenArray(pBytes, length, &pRawDexFile) != 0) {
        LOGV("Unable to open in-memory DEX file");
        free(pBytes);
        dvmThrowRuntimeException("unable to open in-memory DEX file");
        RETURN_VOID();
    }

    LOGV("Opening in-memory DEX");
    pDexOrJar = (DexOrJar*) malloc(sizeof(DexOrJar));
    pDexOrJar->isDex = true;
    pDexOrJar->pRawDexFile = pRawDexFile;
    pDexOrJar->pDexMemory = pBytes;
    pDexOrJar->fileName = strdup("<memory>"); // Needs to be free()able.
    addToDexFileTable(pDexOrJar);

    RETURN_PTR(pDexOrJar);

}

首先来解释fileContentsObj这个对象的内容,从Java层传过来的byte[]类型的一个对象,当到达c++语言层的时候成了两个参数,args和pResult,然后把args这个数组中
的第一个元素直接转化成了ArrayObject对象,接下来显而易见,把这个元素的内容赋给了pBytes对象,那么这个总体的过程可以理解为一个Java层的byte[]类型的对象
转化为c++语言层的一个byte[]类型的对象;

接下来将是对dvmRawDexFileOpenArray(pBytes, length, &pRawDexFile)这个函数的分析,在分析之前,可以一起来看一下这个函数的三个参数,第一个参数和第二个
参数已经不用说了,就是一个byte[]类型的数组,以及这个数组中内容的长度,其实这个内容就是dex的字节流信息,第三个参数是一个RawDexFile的对象,这个对象的数据
结构是这样的:
struct RawDexFile {
    char*       cacheFileName;
    DvmDex*     pDvmDex;
};

这里又看到一个新的数据对象DvmDex,再来看一下这个数据结构:
struct DvmDex {
    DexFile*            pDexFile;
    const DexHeader*    pHeader;
    struct StringObject** pResStrings;
    struct ClassObject** pResClasses;
    struct Method**     pResMethods;
    struct Field**      pResFields;
    struct AtomicCache* pInterfaceCache;
    bool                isMappedReadOnly;
    MemMapping          memMap;
    pthread_mutex_t     modLock;
};

这里又看到一个新的数据对象DexFile,再来看一下这个数据结构:
struct DexFile {
    const DexOptHeader* pOptHeader;
 
    const DexHeader*    pHeader;
    const DexStringId*  pStringIds;
    const DexTypeId*    pTypeIds;
    const DexFieldId*   pFieldIds;
    const DexMethodId*  pMethodIds;
    const DexProtoId*   pProtoIds;
    const DexClassDef*  pClassDefs;
    const DexLink*      pLinkData;

    const DexClassLookup* pClassLookup;
    const void*         pRegisterMapPool;       // RegisterMapClassPool

    const u1*           baseAddr;

    int                 overhead;
}; 

这个数据结构如果了解dex文件格式的话,就对这里的一些对象比较清楚了,其实这个DvmDex数据结构中就保存了Dex文件的各个部分的一些相关内容,具体可以看一下Dex文件
的格式,这里不做多详细的介绍
现在回到那个方法,我们继续往下玩dvmRawDexFileOpenArray这个函数,
int dvmRawDexFileOpenArray(u1* pBytes, u4 length, RawDexFile** ppRawDexFile)
{
    DvmDex* pDvmDex = NULL;

    if (!dvmPrepareDexInMemory(pBytes, length, &pDvmDex)) {
        LOGD("Unable to open raw DEX from array");
        return -1;
    }
    assert(pDvmDex != NULL);

    *ppRawDexFile = (RawDexFile*) calloc(1, sizeof(RawDexFile));
    (*ppRawDexFile)->pDvmDex = pDvmDex;

    return 0;
}
我们可以看到进入这个函数的第一步就是建立了一个DvmDex类型的对象,并初始化为空,经过前面的分析,我们都应该有这个联系,这个pDvmDex对象不就是包含于RawDexFile
这个数据结构中的吗,再看最后第三行,(*ppRawDexFile)->pDvmDex = pDvmDex;,不用多解释,大家明白了这个赋值操作的含义,现在就来看看这个函数的中间部分到底
做了什么呢,还不是dvmPrepareDexInMemory(pBytes, length, &pDvmDex)这个东西惹的祸吗,我们继续进入其中作战,
bool dvmPrepareDexInMemory(u1* addr, size_t len, DvmDex** ppDvmDex)
{
    DexClassLookup* pClassLookup = NULL;
    if (!rewriteDex(addr, len, false, false, &pClassLookup, ppDvmDex)) {
        return false;
    }

    (*ppDvmDex)->pDexFile->pClassLookup = pClassLookup;

    return true;
}

先来看下DexClassLookup这个数据结构长啥模样吧,
struct DexClassLookup {
    int     size;                       
    int     numEntries;                 
    struct {
        u4      classDescriptorHash;    
        int     classDescriptorOffset;  
        int     classDefOffset;         
    } table[1];
};

其实很简单&#
《APK+Dex文件反编译及回编译工具》 简称:APKDB 是一款,针对Android OS系统的APK程序,直接反编译修改的工具。 APKDB集合了当今最强悍,最犀利的APK及Dex文件编译工具; 正常安装后,它直接在【鼠标右键】创建快捷菜单; 非常方便汉化工作者,对APK或Dex文件进行简易的反编译回编译操作 1.本工具必须先安装JAVA7; 2.如需显示APK自身图标必须先安装.NET Framework4 · 对*.Apk 文件 反编译 及 回编译 用于汉化修改 · 对*.Dex 文件 反编译 及 回编译 或查看详细源代码 · 对*.Apk 文件 批量反编译 及 回编译 · 对*.Apk、*.Zip 文件执行签名 · Windows下直示Apk件自身图标 v2.0.2 正式版 2016.06.05 *.更新,ShakaApktool v2.0.0(2016.06.01) *.更新,Apktool v2.1.1正式版(2016.05.07) *.更新,7-zip压缩工具版本到16.02 *.更新,smali、baksmali v2.1.2(2016.03.28) *.更新,ADB工具 (25.1 rc1版) *.更新,Zipalign优化工具 (23.0.3版) *.更新,合并Odex文件 *.更新,XML编辑器(提升速度,修复bug) *.更新,显示APK自身图标(Apkshellext v2.0.1.5780.2290) *.更新,刷机精灵APK安装器 *.新增,自定义默认签名,可用自己制作的签名包签名 *.新增,Keytool签名包制作工具,推荐使用JAVA8 *.新增,极限压缩优化APK内图片功能 *.新增,PNG图片优化工具OptiPNG v0.7.6 *.新增,设定默认Apktool版本(回车键直接执行) *.新增,ShakaApktool自定义操作 *.新增,选项,不反编译Resources、Classes文件 选择后(可同时使用),再选择使用Apktool工具。 *.新增,反编译jar文件时,自动识别是否含多个dex文件,并使用ShakaApktool反编译 *.新增,反编译JAR文件后,回编译时自动合并并转移到反编译目录内 右键[APK文件]、[RSA文件]、[original]目录、[META-INF]目录 可直接查看签名信息。 *.新增,创建[开始菜单-所有程序-APKDB]目录 *.新增,精简APK语言包功能(仅保留英文、简体中文、繁体中文) *.增强,对繁体系统的兼容 *.增强,右键菜单判别准确率 *.增强,重新调整右键菜单,强制关联所有文件 *.增強,针对不同系統的兼容性 *.修复,XP签名优化出错问题 *.修复,选项按键滞留问题 *.修复,文件名含空格优化失败问题 *.修复,签名遗留旧文件,删除框架文件… *.修复,卸载出错问题 *.修复,APK安装器不关联问题 *.修复,个别APK文件反编译时停顿问题 *.修复,修改AndroidManifest.xml回编译没变化问题 *.修复,各种小问题 *.优化,整体兼容性,增加选项状态提示 *.优化,界面调整 *.优化,安装过程 *.优化,对JAVA路径的判别 *.优化,对64位系统的支持 *.优化,执行脚本 *.优化,编译过程 *.优化,DEX文件夹的的判别 *.删减,旧版APKTOOL(2.0.0以下版本) *.其他,一些微调整
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值