DEX文件格式分析

前段时间忙于破解移动和电信的 apk ,挺久没有更新博客了,最近在写个工具,主要功能是通过配置对 dex 文件中的类型、函数、属性进行隐藏,达到防止被静态分析的效果。所以在写工具前必须对 dex 的文件格式有个清晰的认识,相对于 elf 文件格式 dex 文件格式会简单一些。

原文链接: DEX文件格式分析

0x00 前言

分析 dex 文件格式最好的方式是找个介绍文档,自己再写一个简单的 demo 然后用 010Editor 对照着分析。文档可以参考官方文档http://source.android.com/devices/tech/dalvik/dex-format.html,英文差的也可以找个中文的,比如说我。。。。。。

010Editor 这个工具比较好用,之前分析 elf 文件也是用的它。其实只要装了模板,可以分析很多文件。虽然是收费软件,有30天免费试用。但是如果你用的是 mac 试用期到了, 删一下这个文件 ~/.config/SweetScape/010 Editor.ini。

0x01 文件布局

dex 文件可以分为3个模块,头文件(header)、索引区(xxxx_ids)、数据区(data)。头文件概况的描述了整个 dex 文件的分布,包括每一个索引区的大小跟偏移。索引区的ids 是 identifiers 的缩写,表示每个数据的标识,索引区主要是指向数据区的偏移。

010Editor 中除了数据区(data)没有显示出来,其他区段都有显示,另外 link_data 在模板中被定为 map_list

0x02 header

header 描述了 dex 文件信息,和其他各个区的索引。010Editor(写010Editor 有点麻烦下面直接写010)中用结构体 struct header_item 来描述 header。

其中用到了两种数据类型char、uint。这里的 char 是 C/C++ 中的char 占 8-bit, java 中的 char 是占 16-bit 有点区别,但是我们可以他来表示 short/ushort 这个以后介绍最近写的工具会介绍。官方文档是用 ubyte来定义的,那还是按官方的来吧。结构体描述:


  1. ubyte 8-bit unsinged int 
  2. uint  32-bit unsigned int, little-endian 
  3.  
  4. struct header_item  
  5.     ubyte[8]  magic; 
  6.     unit      checksum;  
  7.     ubyte[20] signature;  
  8.     uint      file_size;  
  9.     uint      header_size;  
  10.     unit      endian_tag;  
  11.     uint      link_size;  
  12.     uint      link_off;  
  13.     uint      map_off; 
  14.     uint      string_ids_size;  
  15.     uint      string_ids_off;  
  16.     uint      type_ids_size;  
  17.     uint      type_ids_off;  
  18.     uint      proto_ids_size;  
  19.     uint      proto_ids_off;  
  20.     uint      method_ids_size;  
  21.     uint      method_ids_off;  
  22.     uint      class_defs_size;  
  23.     uint      class_defs_off;  
  24.     uint      data_size; 
  25.     uint      data_off;  

除了 magic、checksum、signature、file_size、endian_tag、map_off 其他元素都是成对出现的。_off 表示元素的偏移量,_size 表示元素的个数。其余的6个描述主要是 dex 文件的信息。

  • magic: 这个是固定值,用于识别 dex 文件。转化为字符串为:

  1. {0x64, 0x65, 0x78, 0x0A, 0x30, 0x33, 0x35, 0x00} = "dex\n035\0" 

中间是一个换行,后面035是版本号。

  • checksum: 文件校验码,使用 alder32 算法校验文件除去 maigc、checksum 外余下的所有文件区域,用于检 查文件错误。
  • signature: 使用 SHA-1 算法 hash 除去 magic、checksum 和 signature 外余下的所有文件区域, 用于唯一识别本文件 。
  • file_size: dex 文件大小
  • header_size: header 区域的大小,目前是固定为 0x70
  • endian_tag: 大小端标签,dex 文件格式为小端,固定值为 0x12345678 常量
  • map_off: map_item 的偏移地址,该 item 属于 data 区里的内容,值要大于等于 data_off 的大小,处于 dex 文件的末端。

0x03 string_ids

string_ids 区段描述了 dex 文件中所有的字符串。格式很简单只有一个偏移量,偏移量指向了 string_data 区段的一个字符串:

上述描述里提到了 LEB128 ( little endian base 128 ) 格式,是基于 1 个 byte 的一种不定长度的编码方式。若第一个 byte 的最高位为1,则表示还需要下一个 byte 来描述,直至最后一个 byte 的最高位为 0。每个 byte 的其余 bit 用来表示数据,如下表所示。实际中 LEB128 最大只能达到 32-bit 可以阅读 dalvik 中的Leb128.h源码看出来。

数据结构为:


  1. ubyte    8-bit unsinged int 
  2. uint     32-bit unsigned int, little-endian 
  3. uleb128  unsigned LEB128, valriable length 
  4.  
  5. struct string_ids_item 
  6.     uint string_data_off; 
  7.  
  8. struct string_data_item  
  9.     uleb128 utf16_size; 
  10.     ubyte   data;  

其中 data 保存的就是字符串的值。string_ids 是比较关键的,后续的区段很多都是直接指向 string_ids 的 index。在写工具进行比较的时候也需要提取到 string_id

0x04 type_ids

type_ids 区索引了 dex 文件里的所有数据类型,包括 class 类型,数组类型(array types)和基本类型(primitive types)。区段里的元素格式为 type_ids_item,结构描述如下 :


  1. uint 32-bit unsigned int, little-endian 
  2.  
  3. struct type_ids_item 
  4.     uint descriptor_idx;  //-->string_ids 

type_ids_item 里面 descriptor_idx 的值的意思,是 string_ids 里的 index 序号,是用来描述此 type 的字符串。

0x05 proto_ids

proto 的意思是 method prototype 代表 java 语言里的一个 method 的原型 。proto_ids 里的元素为 proto_id_item,结构如下:


  1. uint 32-bit unsigned int, little-endian  
  2.  
  3. struct proto_id_item 
  4.     uint shorty_idx;        //-->string_ids 
  5.     uint return_type_idx;    //-->type_ids 
  6.     uint parameters_off; 
  7. }  
  • shorty_idx: 跟 type_ids 一样,它的值是一个 string_ids 的 index 号 ,最终是一个简短的字符串描述,用来说明该 method 原型。
  • return_type_idx: 它的值是一个 type_ids 的 index 号 ,表示该 method 原型的返回值类型。
  • parameters_off: 指向 method 原型的参数列表 type_list,若 method 没有参数,值为0。参数列表的格式是 type_list,下面会有描述。

0x06 field_ids

filed_ids 区里面有 dex 文件引用的所有的 field。区段的元素格式是 field_id_item,结构如下:


  1. ushort 16-bit unsigned int, little-endian  
  2. uint   32-bit unsigned int, little-endian  
  3.  
  4. struct filed_id_item 
  5.     ushort class_idx;  //-->type_ids 
  6.     ushort type_idx;   //-->type_ids 
  7.     uint   name_idx;   //-->string_ids 
  8. }  
  • class_idx: 表示 field 所属的 class 类型,class_idx 的值是 type_ids 的一个 index,并且必须指向一个 class 类型。
  • type_idx: 表示本 field 的类型,它的值也是 type_ids 的一个 index 。
  • name_idx: 表示本 field 的名称,它的值是 string_ids 的一个 index 。

0x07 method_ids

method_ids 是索引区的最后一个条目,描述了 dex 文件里的所有的 method。method_ids 的元素格式是 method_id_item,结构跟 fields_ids 很相似:


  1. ushort 16-bit unsigned int, little-endian  
  2. uint   32-bit unsigned int, little-endian  
  3.  
  4. struct filed_id_item 
  5.     ushort class_idx;  //-->type_ids 
  6.     ushort proto_idx;   //-->proto_ids 
  7.     uint   name_idx;   //-->string_ids 
  8. }  
  • class_idx: 表示 method 所属的 class 类型,class_idx 的值是 type_ids 的一个 index,并且必须指向一个 class 类型。<font color=red>ushort类型也是为什么我们说一个 dex 只能有 65535 个方法的原因,多了必须分包</font>。
  • proto_idx: 表示 method 的类型,它的值也是 type_ids 的一个 index。
  • name_idx: 表示 method 的名称,它的值是 string_ids 的一个 index。

0x08 class_defs

class_def 区段主要是对 class 的定义,它的结构很复杂,看的我有点晕,一层套一层。先看一张 010 的结构图:

看着都晕,别说解析的时候了。

class_def_item

class_def_item 结构描述如下:


  1. uint   32-bit unsigned int, little-endian 
  2.  
  3. struct class_def_item 
  4.     uint class_idx;         //-->type_ids    
  5.     uint access_flags;         
  6.     uint superclass_idx;    //-->type_ids 
  7.     uint interface_off;     //-->type_list 
  8.     uint source_file_idx;    //-->string_ids 
  9.     uint annotations_off;    //-->annotation_directory_item 
  10.     uint class_data_off;    //-->class_data_item 
  11.     uint static_value_off;    //-->encoded_array_item 
  12. }  
  • class_idx: 描述具体的 class 类型,值是 type_ids 的一个 index 。值必须是一个 class 类型,不能是数组类型或者基本类型。
  • access_flags: 描述 class 的访问类型,诸如 public , final , static 等。在 dex-format.html 里 "access_flags Definitions" 有具体的描述 。
  • superclass_idx: 描述 supperclass 的类型,值的形式跟 class_idx 一样 。
  • interfaces_off: 值为偏移地址,指向 class 的 interfaces,被指向的数据结构为 type_list 。class 若没有 interfaces 值为 0。
  • source_file_idx: 表示源代码文件的信息,值是 string_ids 的一个 index。若此项信息缺失,此项值赋值为 NO_INDEX=0xffff ffff。
  • annotions_off: 值是一个偏移地址,指向的内容是该 class 的注释,位置在 data 区,格式为 annotations_direcotry_item。若没有此项内容,值为 0 。
  • class_data_off: 值是一个偏移地址,指向的内容是该 class 的使用到的数据,位置在 data 区,格式为 class_data_item。若没有此项内容值为 0。该结构里有很多内容,详细描述该 class 的 field、method, method 里的执行代码等信息,后面会介绍class_data_item。
  • static_value_off: 值是一个偏移地址 ,指向 data 区里的一个列表 (list),格式为 encoded_array_item。若没有此项内容值为 0。

type_list

type_list 在 data 区段,class_def_item->interface_off 就是指的这里的数据。数据结构如下:


  1. uint   32-bit unsigned int, little-endian 
  2.  
  3. struct type_list 
  4.     uint       size; 
  5.     type_item  list [size]  
  6.  
  7. struct type_item 
  8.     ushort type_idx   //-->type_ids 
  9. }  
  • size: 表示类型个数
  • type_idx: 对应一个 type_ids 的 index

annotations_directory_item

class_def_item->annotations_off 指向的数据区段,定义了 annotation 相关的数据描述,数据结构如下:


  1. uint   32-bit unsigned int, little-endian 
  2.  
  3. struct annotation_directory_item 
  4.     uint class_annotations_off;        //-->annotation_set_item 
  5.     uint fields_size; 
  6.     uint annotated_methods_size; 
  7.     uint annotated_parameters_size; 
  8.      
  9.     field_annotation field_annotations[fields_size]; 
  10.     method_annotation method_annotations[annotated_methods_size]; 
  11.     parameter_annotation parameter_annotations[annotated_parameters_size]; 
  12.  
  13. struct field_annotation 
  14.     uint field_idx; 
  15.     uint annotations_off;    //-->annotation_set_item 
  16.  
  17. struct method_annotation 
  18.     uint method_idx; 
  19.     uint annotations_off;    //-->annotation_set_item 
  20.  
  21. struct parameter_annotation 
  22.     uint method_idx; 
  23.     uint annotations_off;    //-->annotation_set_ref_list 
  24. }  
  • class_annotations_off: 这个偏移指向了 annotation_set_item 具体的可以看 dex-format.html 上的介绍。
  • fields_size: 表示属性的个数
  • annotated_methods_size: 表示方法的个数
  • annotated_parameters_size: 表示参数的个数

class_data_item

class_data_off 指向 data 区里的 class_data_item 结构,class_data_item 里存放着本 class 使用到的各种数据,下面是 class_data_item 的结构 :


  1. uleb128 unsigned little-endian base 128  
  2.  
  3. struct class_data_item 
  4.     uleb128 static_fields_size; 
  5.     uleb128 instance_fields_size; 
  6.     uleb128 direct_methods_size; 
  7.     uleb128 virtual_methods_size; 
  8.  
  9.     encoded_field  static_fields[static_fields_size]; 
  10.     encoded_field  instance_fields[instance_fields_size]; 
  11.     encoded_method direct_methods[direct_methods_size]; 
  12.     encoded_method virtual_methods[virtual_methods_size]; 
  13.  
  14. struct encoded_field 
  15.     uleb128 filed_idx_diff;  
  16.     uleb128 access_flags;   
  17.  
  18. struct encoded_method 
  19.     uleb128 method_idx_diff;  
  20.     uleb128 access_flags;  
  21.     uleb128 code_off; 
  22. }  

class_data_item

  • static_fields_size: 静态成员变量的个数
  • instance_fields_size: 实例成员变量个数
  • direct_methods_size: 直接函数个数
  • virtual_methods_size: 虚函数个数

下面几个就是对于的描述

encoded_field

  • method_idx_diff: 前缀 methd_idx 表示它的值是 method_ids 的一个 index ,后缀 _diff 表示它是于另 外一个 method_idx 的一个差值 ,就是相对于 encodeed_method [] 数组里上一个元素的 method_idx 的差值 。 其实 encoded_filed - > field_idx_diff 表示的也是相同的意思 ,只是编译出来的 Hello.dex 文件里没有使用到 class filed 所以没有仔细讲 ,详细的参考 dex_format.html 的官网文档。
  • access_flags: 访问权限,比如 public、private、static、final 等。
  • code_off: 一个指向 data 区的偏移地址,目标是本 method 的代码实现。被指向的结构是code_item,有近 10 项元素。

code_item

code_item 结构里描述着某个 method 的具体实现,它的结构描述如下:


  1. struct code_item  
  2.     ushort                         registers_size; 
  3.     ushort                         ins_size; 
  4.     ushort                         outs_size; 
  5.     ushort                         tries_size; 
  6.     uint                         debug_info_off; 
  7.     uint                         insns_size; 
  8.     ushort                         insns [insns_size];  
  9.     ushort                         paddding;             // optional 
  10.     try_item                     tries [tyies_size]; // optional 
  11.     encoded_catch_handler_list  handlers;             // optional 
  12. }  

末尾的 3 项标志为 optional , 表示可能有 ,也可能没有 ,根据具体的代码来。

  • registers_size: 本段代码使用到的寄存器数目。
  • ins_size: method 传入参数的数目 。
  • outs_size: 本段代码调用其它 method 时需要的参数个数 。
  • tries_size: try_item 结构的个数 。
  • debug_off: 偏移地址,指向本段代码的 debug 信息存放位置,是一个 debug_info_item 结构。
  • insns_size: 指令列表的大小,以 16-bit 为单位。 insns 是 instructions 的缩写 。
  • padding: 值为 0,用于对齐字节 。
  • tries 和 handlers: 用于处理 java 中的 exception,常见的语法有 try catch。

encoded_array_item

class_def_item->static_value_off 偏移指向该区段数据。


  1. uleb128  unsigned LEB128, valriable length 
  2.  
  3. struct encoded_array_item 
  4.     encoded_array value; 
  5.  
  6. struct encoded_array 
  7. {     
  8.     uleb128 size; 
  9.     encoded_value values[size]; 
  10. }  
  • size : 表示encoded_value 个数
  • encoded_value: 这个我也没分析出来怎么搞得

0x09 map_list

map_list 中大部分 item 跟 header 中的相应描述相同,都是介绍了各个区的偏移和大小,但是 map_list 中描述的更加全面,包括了 HEADER_ITEM 、TYPE_LIST、STRING_DATA_ITEM、DEBUG_INFO_ITEM 等信息。

010 中map_list 表示为:

数据结构为:


  1. ushort 16-bit unsigned int, little-endian 
  2. uint   32-bit unsigned int, little-endian 
  3.  
  4. struct map_list  
  5.     uint     size; 
  6.     map_item list [size];  
  7. struct map_item  
  8.     ushort type;  
  9.     ushort unuse;  
  10.     uint   size;  
  11.     uint   offset; 
  12. }  

map_list 里先用一个 uint 描述后面有 size 个 map_item,后续就是对应的 size 个 map_item 描述。 map_item 结构有 4 个元素: type 表示该 map_item 的类型,Dalvik Executable Format 里 Type Code 的定义; size 表示再细分此 item,该类型的个数;offset 是第一个元素的针对文件初始位置的偏移量; unuse 是用对齐字节的,无实际用处。

作者:凸一_一凸

来源:51CTO

时间: 2024-10-13 23:05:08

DEX文件格式分析的相关文章

ART世界探险(11) - OAT文件格式分析(1) - ELF文件头(上)

ART世界探险(11) - OAT文件格式分析(1) - ELF文件头(上) 既然是要探险,咱们就保持一定的深度,起码将来可以做个基于ART的黑客之类的. 所以我们针对细节多下一些工夫,先仔细分析一下OAT文件的格式. ART的本质上是一个编译器,所以我们需要对编译.链接的主要环节都有一个比较深入的了解.想要绕过编译原理去学好ART,是不太现实的一件事情,我们选择可以让这个过程有趣和好玩. 闲扯不多说了,言归正传. 可执行文件 OAT是一种可执行文件,所以封装在一个ELF格式的可执行文件中. 可

wav文件格式分析详解

wav文件格式分析详解 文章转载自:http://blog.csdn.net/BlueSoal/article/details/932395 一.综述    WAVE文件作为多媒体中使用的声波文件格式之一,它是以RIFF格式为标准的.RIFF是英文Resource Interchange File Format的缩写,每个WAVE文件的头四个字节便是"RIFF".    WAVE文件是由若干个Chunk组成的.按照在文件中的出现位置包括:RIFF WAVEChunk, Format C

PE文件格式分析心得

PE文件格式最近好像炒得沸沸扬扬,由于我正在做一个这样的程序,索性将自己的心得写出来与大家同享. PE文件头分两大部分: 1:DOS 'MZ' HEADER 2:IMAGE_NT_HEADERS 其中IMAGE_NT_HEADERS中包含 PE signature IMAGE_FILE_HEADER IMAGE_OPTIONAL_HEADER(其中包含Data Direcotry) 文件头后紧跟着为 Section Table (array of IMAGE_SECTION_HEADERs) 在

视频文件格式分析(1):avi格式

近日某网盘对用户保存其中的部分私人视频进行篡改,使得这部分视频无论是在线或者下载后均无法播放.我们借着研究对应方法,修复被非法篡改的视频数据,恢复正常使用的机会,研究一下avi的数据格式. avi视频的格式分析 avi是"音视频交错(Audio-Video Interlance)"的缩写,是非常常见的视频文件封装格式.avi是一种适用于采集.编辑.播放的RIFF格式,对不同的编码标准和播放工具具有很强的适应性. 1.文件主体结构 RIFF文件的组成方式由多个chuck组成,组成方式为:

mpeg文件格式分析

MPEG-1流比特层次结构分析总结 1.简要介绍Mpeg 2.Mpeg-1数据流分析 2.1视频序列层(VideoStream) 2.2画面组层(GOP) 2.3画面层(Pictures) 2.4片层(Slice) 2.5宏块层(Macroblock) 2.6块层(Block) 3.加密位置的思考 附录 MPEG-1流比特层次结构分析总结 1.简要介绍Mpeg Mpeg是Motion Picture Expert Group的缩写.活动图像专家组是在1988年由ISO和IEC联合成立的专家组,负

DEX文件混淆加密

现在部分 app 出于安全性(比如加密算法)或者用户体验(热补丁修复bug)会考虑将部分模块采用热加载的形式 Load.所以针对这部分的 dex 进行加密是有必要的如果 dex 是修复的加密算法你总不想被人一下就反编译出来吧.当然也可以直接用一个加密算法对 dex 进行加密Load 前进行解密就可以了但是最好的加密就是让人分不清你是否加密了.一般逆向过程中拿到一个可以直接反编译成 java 源码的 dex 我们很可能就认为这个 dex 文件是没有加密可以分析的. 原文地址: DEX文件混淆加密

Android应用安全风险与防范

Hello,大家好,我是Clock.最近一段时间在做Android应用安全方面的功课,本文进行简单梳理方便以后Review,有错误和遗漏之处还请大家指出. 代码混淆 Android开发除了部分功能采用C/C++编码外,其余主要都是采用Java进行编码开发功能.Java应用非常容易被反编译,Android自然也不例外.只要利用apktool等类似的反编译工具,就可以通过安装包获取源代码.Google为了保护开发者的知识产权,为Android提供了ProGuard混淆方案,以增加反编译后源码阅读,但

UNIX/LINUX 平台可执行文件格式分析

可执行文件格式综述 相 对于其它文件类型,可执行文件可能是一个操作系统中最重要的文件类型,因为它们是完成操作的真正执行者.可执行文件的大小.运行速度.资源占用情况以及可 扩展性.可移植性等与文件格式的定义和文件加载过程紧密相关.研究可执行文件的格式对编写高性能程序和一些黑客技术的运用都是非常有意义的. 不 管何种可执行文件格式,一些基本的要素是必须的,显而易见的,文件中应包含代码和数据.因为文件可能引用外部文件定义的符号(变量和函数),因此重定位信 息和符号信息也是需要的.一些辅助信息是可选的,

位图BITMAP格式分析(2)

前一段时间开发一个编码filter ,过程中出现了回放图像上下倒置的现象,百思不得其解,只好在程序中加了一段将数据倒置的代码,今天看梁老(呵呵,不知多老,反正是前辈拉)的<编程高手箴言>,里面有一段讲正向位图的,好像突然明白了些,便在网上查了一下,终于弄明白以前的现象是怎么回事. bmp位图的存贮方式应该是从下到上,从左向右.也就是说bmp位图的显示方式是第一排显示的是最后一行的数据.在我开发过程中由于使用的是码流解码产生的解码图像(按bmp位图以RBG格式存储),自然是上下颠倒(从下到上)存