`
1025250620
  • 浏览: 225625 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

dex文件结构(转)

 
阅读更多

Dex文件和Dalvik虚拟机

在Android系统中,dex文件是可以直接在Dalvik虚拟机中加载运行的文件。通过ADT,经过复杂的编译,可以把java源代码转换为dex文 件。 那么这个文件的格式是什么样的呢?为什么Android不直接使用class文件,而采用这个不一样文件呢?其实它是针对嵌入式系统优化的结 果,Dalvik虚拟机的指令码并不是标准的Java虚拟机指令码,而是使用了自己独有的一套指令集。如果有自己的编译系统,可以不生成class文件, 直接生成dex文件。dex文件中共用了很多类名称、常量字符串,使它的体积比较小,运行效率也比较高。但归根到底,Dalvik还是基于寄存器的虚拟机 的一个实现。

文件头(File Header)

Dex文件头主要包括校验和以及其他结构的偏移地址和长度信息。

字段名称 偏移值 长度 描述
magic 0x0 8 'Magic'值,即魔数字段,格式如”dex/n035/0”,其中的035表示结构的版本。
checksum 0x8 4 校验码。
signature 0xC 20 SHA-1签名。
file_size 0x20 4 Dex文件的总长度。
header_size 0x24 4 文件头长度,009版本=0x5C,035版本=0x70。
endian_tag 0x28 4 标识字节顺序的常量,根据这个常量可以判断文件是否交换了字节顺序,缺省情况下=0x78563412。
link_size 0x2C 4 连接段的大小,如果为0就表示是静态连接。
link_off 0x30 4 连接段的开始位置,从本文件头开始算起。如果连接段的大小为0,这里也是0。
map_off 0x34 4 map数据基地址。
string_ids_size 0x38 4 字符串列表的字符串个数。
string_ids_off 0x3C 4 字符串列表表基地址。
type_ids_size 0x40 4 类型列表里类型个数。
type_ids_off 0x44 4 类型列表基地址。
proto_ids_size 0x48 4 原型列表里原型个数。
proto_ids_off 0x4C 4 原型列表基地址。
field_ids_size 0x50 4 字段列表里字段个数。
field_ids_off 0x54 4 字段列表基地址。
method_ids_size 0x58 4 方法列表里方法个数。
method_ids_off 0x5C 4 方法列表基地址。
class_defs_size 0x60 4 类定义类表中类的个数。
class_defs_off 0x64 4 类定义列表基地址。
data_size 0x68 4 数据段的大小,必须以4字节对齐。
data_off 0x6C 4 数据段基地址

魔数字段

魔数字段,主要就是Dex文件的标识符,它占用4个字节,在目前的源码里是 “dex\n”,它的作用主要是用来标识dex文件的,比如有一个文件也以dex为后缀名,仅此并不会被认为是Davlik虚拟机运行的文件,还要判断这 四个字节。另外Davlik虚拟机也有优化的Dex,也是通过个字段来区分的,当它是优化的Dex文件时,它的值就变成”dey\n”了。根据这四个字 节,就可以识别不同类型的Dex文件了。

跟在“dex\n”后面的是版本字段,主要用来标识Dex文件的版本。目前支持的版本号为“035\0”,不管是否优化的版本,都是使用这个版本号。

检验码字段

主要用来检查从这个字段开始到文件结尾,这段数据是否完整,有没有人修改过,或者传送过程中是否有出错等等。通常用来检查数据是否完整的算法,有 CRC32、有SHA128等,但这里采用并不是这两类,而采用一个比较特别的算法,叫做adler32,这是在开源zlib里常用的算法,用来检查文件 是否完整性。该算法由MarkAdler发明,其可靠程度跟CRC32差不多,不过还是弱一点点,但它有一个很好的优点,就是使用软件来计算检验码时比较 CRC32要快很多。可见Android系统,就算法上就已经为移动设备进行优化了。

Adler32算法的C源码如下(Java中可使用java.util.zip.Adler32类做校验操作):

#define ZLIB_INTERNAL
#include "zlib.h"
#define BASE 65521UL /* largest prime smaller than 65536 */
#define NMAX 5552 
/*NMAX is the largest n such that 255n(n+1)/2 + (n+1)(BASE-1) <=2^32-1 */
 
#define DO1(buf,i){adler += (buf)[i]; sum2 += adler;}
#define DO2(buf,i) DO1(buf,i); DO1(buf,i+1);
#define DO4(buf,i) DO2(buf,i); DO2(buf,i+2);
#define DO8(buf,i) DO4(buf,i); DO4(buf,i+4);
#define DO16(buf) DO8(buf,0); DO8(buf,8);
 
/*use NO_DIVIDE if your processor does not do division in hardware */
#ifdef NO_DIVIDE
#define MOD(a) \ 
do{ \ 
if(a >= (BASE << 16)) a -= (BASE << 16); \ 
if(a >= (BASE << 15)) a -= (BASE << 15); \ 
if(a >= (BASE << 14)) a -= (BASE << 14); \ 
if(a >= (BASE << 13)) a -= (BASE << 13); \ 
if(a >= (BASE << 12)) a -= (BASE << 12); \ 
if(a >= (BASE << 11)) a -= (BASE << 11); \ 
if(a >= (BASE << 10)) a -= (BASE << 10); \ 
if(a >= (BASE << 9)) a -= (BASE << 9); \ 
if(a >= (BASE << 8)) a -= (BASE << 8); \ 
if(a >= (BASE << 7)) a -= (BASE << 7); \ 
if(a >= (BASE << 6)) a -= (BASE << 6); \ 
if(a >= (BASE << 5)) a -= (BASE << 5); \ 
if(a >= (BASE << 4)) a -= (BASE << 4); \ 
if(a >= (BASE << 3)) a -= (BASE << 3); \ 
if(a >= (BASE << 2)) a -= (BASE << 2); \ 
if(a >= (BASE << 1)) a -= (BASE << 1); \ 
if(a >= BASE) a -= BASE; \ 
}while (0)
# define MOD4(a) \ 
do{ \ 
if(a >= (BASE << 4)) a -= (BASE << 4); \ 
if(a >= (BASE << 3)) a -= (BASE << 3); \ 
if(a >= (BASE << 2)) a -= (BASE << 2); \ 
if(a >= (BASE << 1)) a -= (BASE << 1); \ 
if(a >= BASE) a -= BASE; \ 
}while (0)
#else
#define MOD(a) a %= BASE
#define MOD4(a) a %= BASE
#endif
 
/*=========================================================================*/
uLong ZEXPORT adler32(adler, buf, len)
    uLong adler;
    const Bytef *buf;
    uInt len;
{
    unsigned long sum2;
    unsigned n;
 
    /*split Adler-32 into component sums */
    sum2= (adler >> 16) & 0xffff;
    adler&= 0xffff;
 
    /*in case user likes doing a byte at a time, keep it fast */
    if(len == 1) {
        adler+= buf[0];
        if(adler >= BASE)adler-= BASE;
        sum2+= adler;
        if(sum2 >= BASE)sum2-= BASE;
        return adler|(sum2 << 16);
    }
 
    /*initial Adler-32 value (deferred check for len == 1 speed) */
    if(buf == Z_NULL)return 1L;
 
    /*in case short lengths are provided, keep it somewhat fast */
    if(len < 16) {
        while(len--) {
            adler+= *buf++;
            sum2+= adler;
        }
        if(adler >= BASE)
            adler-= BASE;
        MOD4(sum2); /* only added so many BASE's */
        return adler|(sum2 << 16);
    }
 
    /*do length NMAX blocks -- requires just one modulo operation */
    while(len >= NMAX) {
        len-= NMAX;
        n= NMAX/16; /* NMAX is divisible by 16 */
        do{
            DO16(buf); /* 16 sums unrolled */
            buf+= 16;
        }while (--n);
        MOD(adler);
        MOD(sum2);
    }
 
    /*do remaining bytes (less than NMAX, still just one modulo) */
    if(len) { 
        /* avoid modulos if none remaining */
        while(len >= 16) {
            len-= 16;
            DO16(buf);
            buf+= 16;
        }
        while(len--) {
            adler+= *buf++;
            sum2+= adler;
        }
        MOD(adler);
        MOD(sum2);
    }
 
    /*return recombined sums */
    return adler|(sum2 << 16);
}

SHA-1签名字段

dex文件头里,前面已经有了面有一个4字节的检验字段码了,为什么还会有SHA-1签名字段呢?不是重复了吗?可是仔细考虑一下,这样设计自有道理。因 为dex文件一般都不是很小,简单的应用程序都有几十K,这么多数据使用一个4字节的检验码,重复的机率还是有的,也就是说当文件里的数据修改了,还是很 有可能检验不出来的。这时检验码就失去了作用,需要使用更加强大的检验码,这就是SHA-1。SHA-1校验码有20个字节,比前面的检验码多了16个字 节,几乎不会不同的文件计算出来的检验是一样的。设计两个检验码的目的,就是先使用第一个检验码进行快速检查,这样可以先把简单出错的dex文件丢掉了, 接着再使用第二个复杂的检验码进行复杂计算,验证文件是否完整,这样确保执行的文件完整和安全。

SHA(Secure Hash Algorithm, 安全散列算法)是美国国家安全局设计,美国国家标准与技术研究院发布的一系列密码散列函数。SHA-1看起来和MD5算法很像,也许是Ron Rivest在SHA-1的设计中起了一定的作用。SHA-1的内部比MD5更强,其摘要比MD5的16字节长4个字节,这个算法成功经受了密码分析专家 的攻击,也因而受到密码学界的广泛推崇。这个算法在目前网络上的签名,BT软件里就有大量使用,比如在BT里要计算是否同一个种子时,就是利用文件的签名 来判断的。同一份8G的电影从几千BT用户那里下载,也不会出现错误的数据,导致电影不播放。

map_off字段

这个字段主要保存map开始位置,就是从文件头开始到map数据的长度,通过这个索引就可以找到map数据。map的数据结构如下:

名称 大小 说明
size 4字节 map里项的个数
list 变长 每一项定义为12字节,项的个数由上面项大小决定。

map数据排列结构定义如下:

/*
*Direct-mapped "map_list".
*/
 
typedef struct DexMapList {
    u4 size; /* #of entries inlist */
    DexMapItem list[1]; /* entries */
}DexMapList;

每一个map项的结构定义如下:

/*
*Direct-mapped "map_item".
*/
 
typedef struct DexMapItem {
    u2 type; /* type code (seekDexType* above) */
    u2 unused;
    u4 size; /* count of items ofthe indicated type */
    u4 offset; /* file offset tothe start of data */
}DexMapItem;

DexMapItem结构定义每一项的数据意义:类型、类型个数、类型开始位置。

其中的类型定义如下:

/*map item type codes */
enum{
    kDexTypeHeaderItem = 0x0000,
    kDexTypeStringIdItem = 0x0001,
    kDexTypeTypeIdItem = 0x0002,
    kDexTypeProtoIdItem = 0x0003,
    kDexTypeFieldIdItem = 0x0004,
    kDexTypeMethodIdItem = 0x0005,
    kDexTypeClassDefItem = 0x0006,
    kDexTypeMapList = 0x1000,
    kDexTypeTypeList = 0x1001,
    kDexTypeAnnotationSetRefList = 0x1002,
    kDexTypeAnnotationSetItem = 0x1003,
    kDexTypeClassDataItem = 0x2000,
    kDexTypeCodeItem = 0x2001,
    kDexTypeStringDataItem = 0x2002,
    kDexTypeDebugInfoItem = 0x2003,
    kDexTypeAnnotationItem = 0x2004,
    kDexTypeEncodedArrayItem = 0x2005,
    kDexTypeAnnotationsDirectoryItem = 0x2006,
};

从上面的类型可知,它包括了在dex文件里可能出现的所有类型。可以看出这里的类型与文件头里定义的类型有很多是一样的,这里的类型其实就是文件头里定义 的类型。其实这个map的数据,就是头里类型的重复,完全是为了检验作用而存在的。当Android系统加载dex文件时,如果比较文件头类型个数与 map里类型不一致时,就会停止使用这个dex文件。

string_ids_size/off字段

这两个字段主要用来标识字符串资源。源程序编译后,程序里用到的字符串都保存在这个数据段里,以便解释执行这个dex文件使用。其中包括调用库函数里的类名称描述,用于输出显示的字符串等。

string_ids_size标识了有多少个字符串,string_ids_off标识字符串数据区的开始位置。字符串的存储结构如下:

/*
 * Direct-mapped "string_id_item".
 */
typedef struct DexStringId {
    u4  stringDataOff;      /* file offset to string_data_item */
} DexStringId;

可以看出这个数据区保存的只是字符串表的地址索引。如果要找到字符串的实际数据,还需要通过个地址索引找到文件的相应开始位置,然后才能得到字符串数据。 每一个字符串项的索引占用4个字节,因此这个数据区的大小就为4*string_ids_size。实际数据区中的字符串采用UTF8格式保存。

例如,如果dex文件使用16进制显示出来内容如下:
063c 696e 6974 3e00
其实际数据则是”<init>\0”

另外这段数据中不仅包括字符串的字符串的内容和结束标志,在最开头的位置还标明了字符串的长度。上例中第一个字节06就是表示这个字符串有6个字符。

关于字符串的长度有两点需要注意的地方:

1、关于长度的编码格式

dex文件里采用了变长方式表示字符串长度。一个字符串的长度可能是一个字节(小于256)或者4个字节(1G大小以上)。字符串的长度大多数都是小于 256个字节,因此需要使用一种编码,既可以表示一个字节的长度,也可以表示4个字节的长度,并且1个字节的长度占绝大多数。能满足这种表示的编码方式有 很多,但dex文件里采用的是uleb128方式。leb128编码是一种变长编码,每个字节采用7位来表达原来的数据,最高位用来表示是否有后继字节。

它的编码算法如下:

/*
 * Writes a 32-bit value in unsigned ULEB128 format.
 * Returns the updated pointer.
 */
DEX_INLINE u1* writeUnsignedLeb128(u1* ptr, u4 data)
{
    while (true) {
        u1 out = data & 0x7f;
        if (out != data) {
            *ptr++ = out | 0x80;
            data >>= 7;
        } else {
            *ptr++ = out;
            break;
        }
    }
    return ptr;
}

它的解码算法如下:

/*
 * Reads an unsigned LEB128 value, updating the given pointer to point
 * just past the end of the read value. This function tolerates
 * non-zero high-order bits in the fifth encoded byte.
 */
DEX_INLINE int readUnsignedLeb128(const u1** pStream) {
    const u1* ptr = *pStream;
    int result = *(ptr++);
   if (result > 0x7f) {
        int cur = *(ptr++);
        result = (result & 0x7f) | ((cur & 0x7f) << 7);
        if (cur > 0x7f) {
            cur = *(ptr++);
            result |= (cur & 0x7f) << 14;
            if (cur > 0x7f) {
                cur = *(ptr++);
                result |= (cur & 0x7f) << 21;
                if (cur > 0x7f) {
                    /*
                     * Note: We don't check to see if cur is out of
                     * range here, meaning we tolerate garbage in the
                     * high four-order bits.
                     */
                    cur = *(ptr++);
                    result |= cur << 28;
                }
            }
        }
    }
    *pStream = ptr;
    return result;
}

根据上面的算法分析上面例子字符串,取得第一个字节是06,最高位为0,因此没有后继字节,那么取出这个字节里7位有效数据,就是6,也就是说这个字符串是6个字节,但不包括结束字符“\0”。

2、关于长度的意义

由于字符串内容采用的是UTF-8格式编码,表示一个字符的字节数是不定的。即有时是一个字节表示一个字符,有时是两个、三个甚至四个字节表示一个字符。 而这里的长度代表的并不是整个字符串所占用的字节数,表示这个字符串包含的字符个数。所以在读取时需要注意,尤其是在包含中文字符时,往往会因为读取的长 度不正确导致字符串被截断。

关于计算UTF-8字符串的长度,可参见字符编码知识-UTF8编码规则

from:www.cnblogs.com/santry/archive/2011/10/24/2222900.html

分享到:
评论

相关推荐

    Dex文件结构

    详细介绍android apk Dex文件结构;

    Dex文件头结构解析器

    dex作为Android平台下的exe是一个非常重要的文件。所以分析就有了必要。 dex作为Android平台下的exe是一个非常重要的文件。所以分析就有了必要。

    安卓反编译dex文件格式实例分析

    1. dex 整个文件的布局 2. header 3. string_ids 4. type_ids 5. proto_ids 6. field_ids 7. method_ids 8. class_defs 8.1 class_def_item 8.2 class_def_item --&gt; class_data_item 8.3 class_def_item --&gt; ...

    Smali语法学习与DEX文件详解

    Smali代码是Android的Dalvik虚拟机的可执行文件DEX文件反汇编后的代码。所以Smali语言就是Dalvik的反汇编语言。 使用Apktool反编译apk 文件后,会在反编译工程目录下生成一个smali 文件夹,里面存放着所有反编译出的...

    Dex格式消亡史——最新Dex保护技术:流式编码.pdf

    • 安全背景、Dex格式、Dex指令编码 攻防演进 • 各代Dex壳的特点与弱点 虚拟化设计 • DexVmp设计、安全性 改进与展望 • 流式编码、后续演进 当下常用的DexVmp虚拟保护技术,某种程度上抑制了脱壳的自动化,但是...

    dexFileAnalyze:学习dex文件格式时写的一个小工具,主要目的是更具体的了解dex文件格式,理解dex文件的混淆是怎么一回事情,理解dex文件在被执行的时候和PE文件有什么区别?

    在学习《安卓逆向分析》一书的dex文件格式时写的一个小工具,因为PE文件结构在PC端是非常重要的,那么想了解安卓下的加壳就必须从代码的角度去分析一下dex文件格式。 文件说明: test.java:用与测试dex文件的java...

    dex_string_catch.zip_dex

    提取出dex文件中的字符串,通过分析dex的结构,索引到string。

    咋把dex文件变成java源码-redexer:Dalvik字节码的Redexer二进制检测框架

    咋把dex文件变成java源码 还原剂 Redexer 是一个重新设计的工具,用于操作 Android 应用程序二进制文件。 该工具能够将 DEX 文件解析为内存中的数据结构; 推断应用程序使用哪些参数使用某些权限(我们将此功能命名...

    Android应用程序的补丁方法.pdf

    Dex 文件结构 研究Windows的程序,首先要掌握PE文件格式,到了Linux/Unix环境,又必须掌握ELF文件格式。因为它们都是分析自身所在系统程序的基础。不了解它,就像中国人不了解汉字,美国人不了解英语,太阳不了解...

    Android运行时ART加载OAT文件的过程分析

    OAT文件是一种Android私有ELF文件格式,它不仅包含有从DEX文件翻译而来的本地机器指令,还包含有原来的DEX文件内容。这使得我们无需重新编译原有的APK就可以让它正常地在ART里面运行,也就是我们不需要改变原来的APK...

    android dalvik虚拟机结构及机制剖析 第二卷

    android dalvik虚拟机结构及机制剖析 第二版,详细介绍Android虚拟机值得阅览

    Android代码-apk_auto_enforce

    &gt; DEX文件结构分析 http://shuwoom.com/?p=179 &gt; DALVIK加载和解析DEX过程 http://shuwoom.com/?p=269 &gt; DALVIK查找类和方法的过程 http://shuwoom.com/?p=282 &gt; ELF文件结构分析 http://shuwoom.com/?p=286 &gt; SO...

    ApkIDE最新3.3.5少月增强版.rar

    APK改之理(APK IDE)是一款可视化的用于修改安卓Apk程序文件的工具,集成了ApkTool、Dex2jar、JD-GUI等...4.增加插件python版的DEX文件分析工具,可以对DEX文件进行反汇编、结构与代码关系分析,DEX文件头结构分析;

    Android逆向分析基础篇之格式篇.pdf

    目录 Dalvik 虚拟机 •Dalvik 虚拟机介绍 •Dalvik汇编语言基础 •Dalvik版本HellWorld ...•Dex文件结构解析 •ODex文件结构解析 •另类APK破解方法 Smali文件格式 •Smali文件结构解析 •IDA Pro 破解实例

    apktool.zip

    结构介绍: dex2jar-2.0:classes.dex转化成jar文件 dex2jar-2.0-plus:支持分包的classes.dex转化成jar文件 jd-gui:作用:查看APK中classes.dex转化成出的jar文件,即源码文件

    Dalvik知识收集

    目录(导读) 一、Dalvik虚拟机工作原理介绍 二、Dalvik与Androi架构 三、JNI技术(java与dll交互的技术) 四、Dex文件结构 五、Apk文件结构、dex反编译 5.2 反编译工具Dedexer 六、JAVA虚拟机的结构解析

    解包打包android内核system.img文件所需工具

    最后一步:因为system.img中的apk是优化过的,apk主目录下是没有classes.dex文件的,而是一个被优化过的odex文件,用于优化启动速度。 因此需要将修改后的apk包再用dexopt-wrapper优化apk包后生成出odex文件,...

    ApkIDE最新3.3.3少月增强版

    插件Python分析dex文件 插件smali插桩 APKIDE七少月RSA加密解密工具 APKIDE七少月ELF文件结构解析器 APKIDE七少月DES加密解密工具 1.彻底改变APKIDE 3.1模式,彻底解决了APKIDE无法反编和回编Untiy3D与COCO2DX平台...

    DEx.top:DEx.top-链上即时交易

    DEx.top-链上即时交易交流: : 概述DEx.top通过其两个分类账体系结构实现了即时交易体验:负责提供即时交易体验的链下分类账和基于智能合约的链上分类账,以确保交易者的资产安全。 这两个分类账是紧密同步的,所有...

    Android MasterKey漏洞调研报告

    要想了解APK签名漏洞,首先需要了解APK的文件结构,APK的签名验证机制。在调研了各个漏洞之后,本报告也给出了恶意程序检查方法。本调研报告内容组织如下: 1、APK文件格式 2、APK文件签名 3、APK签名验证过程 4、...

Global site tag (gtag.js) - Google Analytics