ELF相比Hex、Bin文件格式有哪些不同？

素材来源：综合CSDN

编辑整理：strongerHuang

关于计算机的文件有很多种，今天分享一种用于二进制文件、可执行文件、目标代码、共享库和核心转储格式文件。

一、ELF文件简介

ELF：Executable and Linkable Format，可执行与可链接格式。

首先，你需要知道的是所谓对象文件（Object files）有三个种类：

1）可重定向文件：文件保存着代码和适当的数据，用来和其他的目标文件一起来创建一个可执行文件或者是一个共享目标文件。（目标文件或者静态库文件，即通常后缀为.a和.o的文件）

2）可执行文件：文件保存着一个用来执行的程序。（例如bash，gcc等）

3）共享目标文件：共享库。文件保存着代码和合适的数据，用来被下连接编辑器和动态链接器链接。

二、ELF文件格式

首先，ELF文件格式提供了两种视图，分别是链接视图和执行视图。

链接视图是以节（section）为单位，执行视图是以段（segment）为单位。链接视图就是在链接时用到的视图，而执行视图则是在执行时用到的视图。上图左侧的视角是从链接来看的，右侧的视角是执行来看的。总个文件可以分为四个部分：

ELF header：描述整个文件的组织。

Program Header Table： 描述文件中的各种segments，用来告诉系统如何创建进程映像的。

sections 或者 segments：segments是从运行的角度来描述elf文件，sections是从链接的角度来描述elf文件，也就是说，在链接阶段，我们可以忽略program header table来处理此文件，在运行阶段可以忽略section header table来处理此程序（所以很多加固手段删除了section header table）。从图中我们也可以看出，segments与sections是包含的关系，一个segment包含若干个section。

Section Header Table： 包含了文件各个segction的属性信息，我们都将结合例子来解释。

程序头部表（Program Header Table），如果存在的话，告诉系统如何创建进程映像。

节区头部表（Section Header Table）包含了描述文件节区的信息，比如大小、偏移等。

如下图，可以通过执行命令”readelf -S android_server”来查看该可执行文件中有哪些section。

通过执行命令readelf –segments android_server，可以查看该文件的执行视图。

这验证了第一张图中所述，segment是section的一个集合，sections按照一定规则映射到segment。那么为什么需要区分两种不同视图？

当ELF文件被加载到内存中后，系统会将多个具有相同权限（flg值）section合并一个segment。操作系统往往以页为基本单位来管理内存分配，一般页的大小为4096B，即4KB的大小。同时，内存的权限管理的粒度也是以页为单位，页内的内存是具有同样的权限等属性，并且操作系统对内存的管理往往追求高效和高利用率这样的目标。ELF文件在被映射时，是以系统的页长度为单位的，那么每个section在映射时的长度都是系统页长度的整数倍，如果section的长度不是其整数倍，则导致多余部分也将占用一个页。而我们从上面的例子中知道，一个ELF文件具有很多的section，那么会导致内存浪费严重。这样可以减少页面内部的碎片，节省了空间，显著提高内存利用率。

需要注意地是：尽管图中显示的各个组成部分是有顺序的，实际上除了 ELF 头部表以外，其他节区和段都没有规定的顺序。

三、ELF Header

首先，我们先来看下32位ELF文件中常用的数据格式：名称大小对齐目的

Elf32_Addr44无符号程序地址

Elf32_Half22无符号中等整数

Elf32_Off44无符号文件偏移

Elf32_SWord44有符号大整数

Elf32_Word44无符号大整数

unsigned char11无符号小整数

然后我们来观察一下ELF Header的结构体：

#define EI_NIDENT 16typedef struct { unsigned char e_ident［EI_NIDENT］; ELF32_Half e_type; ELF32_Half e_machine; ELF32_Word e_version; ELF32__Addr e_entry; ELF32_Off e_phoff; ELF32_Off e_shoff; ELF32_Word e_flags; ELF32_Half e_ehsize; ELF32_Half e_phentsize; ELF32_Half e_phnum; ELF32_Half e_shentsize; ELF32_Half e_shnum; ELF32_Half e_shstrndx;}Elf32_Ehdr;

e_ident ：ELF的一些标识信息，前四位为.ELF，其他的信息比如大小端等

e_machine ：文件的目标体系架构，比如ARM

e_version ： 0为非法版本，1为当前版本

e_entry ：程序入口的虚拟地址

e_phoff ：程序头部表偏移地址

e_shoff ：节区头部表偏移地址

e_flags ：保存与文件相关的，特定于处理器的标志

e_ehsize ：ELF头的大小

e_phentsize ：每个程序头部表的大小

e_phnum ：程序头部表的数量

e_shentsize：每个节区头部表的大小

e_shnum ：节区头部表的数量

e_shstrndx：节区字符串表位置

接着运行readelf -h android_server命令，可以看到ELF Header结构的内容。

或者使用010Editor的ELF模板也可以看到ELF Header结构。对比以下三类ELF文件，我们得到了以下结论：

1、e_type标识了文件类型

2、Relocatable File（.o文件）不需要执行，因此e_entry字段为0，且没有Program Header Table等执行视图

3、不同类型的ELF文件的Section也有较大区别，比如只有Relocatable File有.strtab节。

Shared Object File（.so文件）

Executable File（可执行文件android_server）

Relocatable File（.o文件）

四、Section Header Table

一个ELF文件中到底有哪些具体的 sections，由包含在这个ELF文件中的 section head table（SHT）决定。在SHT中，针对每一个section，都设置有一个条目（entry），用来描述对应的这个section，其内容主要包括该 section 的名称、类型、大小以及在整个ELF文件中的字节偏移位置等等。我们也可以在TISCv1.2规范中找到SHT表中条目的C结构定义：

typedef struct{ Elf32_Word sh_name; //节区名，是节区头部字符串表节区（Section Header String Table Section）的索引。名字是一个 NULL 结尾的字符串。 Elf32_Word sh_type; //为节区类型 Elf32_Word sh_flags; //节区标志 Elf32_Addr sh_addr; //如果节区将出现在进程的内存映像中，此成员给出节区的第一个字节应处的位置。否则，此字段为 0。 Elf32_Off sh_offset; //此成员的取值给出节区的第一个字节与文件头之间的偏移。 Elf32_Word sh_size; //此 成 员 给 出 节 区 的 长 度 （ 字 节 数 ）。 Elf32_Word sh_link; //此成员给出节区头部表索引链接。其具体的解释依赖于节区类型。 Elf32_Word sh_info; //此成员给出附加信息，其解释依赖于节区类型。 Elf32_Word sh_addralign; //某些节区带有地址对齐约束。 Elf32_Word sh_entsize; //某些节区中包含固定大小的项目，如符号表。对于这类节区，此成员给出每个表项的长度字节数。}Elf32_Shdr;

sh_type的取值如下：

名称取值说明

SHT_NULL0此值标志节区头部是非活动的，没有对应的节区。此节区头部中的其他成员取值无意义。

SHT_PROGBITS1此节区包含程序定义的信息，其格式和含义都由程序来解释。

SHT_SYMTAB2此节区包含一个符号表。目前目标文件对每种类型的节区都只能包含一个，不过这个限制将来可能发生变化。一般，SHT_SYMTAB 节区提供用于链接编辑（指 ld 而言）的符号，尽管也可用来实现动态链接。

SHT_STRTAB3此节区包含字符串表。目标文件可能包含多个字符串表节区。

SHT_RELA4此节区包含重定位表项，其中可能会有补齐内容（addend），例如 32 位目标文件中的 Elf32_Rela 类型。目标文件可能拥有多个重定位节区。

SHT_HASH5此节区包含符号哈希表。所有参与动态链接的目标都必须包含一个符号哈希表。目前，一个目标文件只能包含一个哈希表，不过此限制将来可能会解除。

SHT_DYNAMIC6此节区包含动态链接的信息。目前一个目标文件中只能包含一个动态节区，将来可能会取消这一限制。

SHT_NOTE7此节区包含以某种方式来标记文件的信息。

SHT_NOBITS8这 种 类 型 的 节 区 不 占 用 文 件 中 的 空 间 ， 其 他 方 面 和SHT_PROGBITS 相似。尽管此节区不包含任何字节，成员sh_offset 中还是会包含概念性的文件偏移

SHT_REL9此节区包含重定位表项，其中没有补齐（addends），例如 32 位目标文件中的 Elf32_rel 类型。目标文件中可以拥有多个重定位节区。

SHT_SHLIB10此节区被保留，不过其语义是未规定的。包含此类型节区的程序与 ABI 不兼容。

SHT_DYNSYM11作为一个完整的符号表，它可能包含很多对动态链接而言不必要的符号。因此，目标文件也可以包含一个 SHT_DYNSYM 节区，其中保存动态链接符号的一个最小集合，以节省空间。

SHT_LOPROC0X70000000这一段（包括两个边界），是保留给处理器专用语义的。

SHT_HIPROCOX7FFFFFFF这一段（包括两个边界），是保留给处理器专用语义的。

SHT_LOUSER0X80000000此值给出保留给应用程序的索引下界。

SHT_HIUSER0X8FFFFFFF此值给出保留给应用程序的索引上界。

五、Section

有些节区是系统预订的，一般以点开头号，因此，我们有必要了解一些常用到的系统节区。

名称类型属性含义

.bssSHT_NOBITSSHF_ALLOC +

SHF_WRITE包含将出现在程序的内存映像中的为初始化数据。根据定义，当程序开始执行，系统将把这些数据初始化为 0。此节区不占用文件空间。

.commentSHT_PROGBITS（无）包含版本控制信息。

.dataSHT_PROGBITSSHF_ALLOC +

SHF_WRITE这些节区包含初始化了的数据，将出现在程序的内存映像中。

.data1SHT_PROGBITSSHF_ALLOC +

SHF_WRITE这些节区包含初始化了的数据，将出现在程序的内存映像中。

.debugSHT_PROGBITS（无）此节区包含用于符号调试的信息。

.dynamicSHT_DYNAMIC

此节区包含动态链接信息。节区的属性将包含 SHF_ALLOC 位。是否 SHF_WRITE 位被设置取决于处理器。

.dynstrSHT_STRTABSHF_ALLOC此节区包含用于动态链接的字符串，大多数情况下这些字符串代表了与符号表项相关的名称。

.dynsymSHT_DYNSYMSHF_ALLOC此节区包含了动态链接符号表。

.finiSHT_PROGBITSSHF_ALLOC +

SHF_EXECINSTR此节区包含了可执行的指令，是进程终止代码的一部分。程序正常退出时，系统将安排执行这里的代码。

.gotSHT_PROGBITS

此节区包含全局偏移表。

.hashSHT_HASHSHF_ALLOC此节区包含了一个符号哈希表。

.initSHT_PROGBITSSHF_ALLOC +

SHF_EXECINSTR此节区包含了可执行指令，是进程初始化代码的一部分。当程序开始执行时，系统要在开始调用主程序入口之前（通常指 C 语言的 main 函数）执行这些代码。

.interpSHT_PROGBITS

此节区包含程序解释器的路径名。如果程序包含一个可加载的段，段中包含此节区，那么节区的属性将包含 SHF_ALLOC 位，否则该位为 0。

.lineSHT_PROGBITS（无）此节区包含符号调试的行号信息，其中描述了源程序与机器指令之间的对应关系。其内容是未定义的。

.noteSHT_NOTE（无）此节区中包含注释信息，有独立的格式。

.pltSHT_PROGBITS

此节区包含过程链接表（procedure linkage table）。

.relname

.relanameSHT_REL

SHT_RELA

这些节区中包含了重定位信息。如果文件中包含可加载的段，段中有重定位内容，节区的属性将包含 SHF_ALLOC 位，否则该位置 0。传统上 name 根据重定位所适用的节区给定。例如 .text 节区的重定位节区名字将是：.rel.text 或者 .rela.text。

.rodata

.rodata1SHT_PROGBITSSHF_ALLOC这些节区包含只读数据，这些数据通常参与进程映像的不可写段。

.shstrtabSHT_STRTAB

此节区包含节区名称。

.strtabSHT_STRTAB

此节区包含字符串，通常是代表与符号表项相关的名称。如果文件拥有一个可加载的段，段中包含符号串表，节区的属性将包含SHF_ALLOC 位，否则该位为 0。

.symtabSHT_SYMTAB

此节区包含一个符号表。如果文件中包含一个可加载的段，并且该段中包含符号表，那么节区的属性中包含SHF_ALLOC 位，否则该位置为 0。

.textSHT_PROGBITSSHF_ALLOC +

SHF_EXECINSTR此节区包含程序的可执行指令。

六、Program Header Table

程序头部（Program Header）描述与程序执行直接相关的目标文件结构信息。用来在文件中定位各个段的映像。同时包含其他一些用来为程序创建映像所必须的信息。

可执行文件或者共享目标文件的程序头部是一个结构数组，每个结构描述了一个段或者系统准备程序执行所必须的其他信息。目标文件的“段”包含一个或者多个“节区”，也就是“段内容（Segment Contents）”。程序头部仅对可执行文件和共享目标文件有意义。

程序头部的数据结构如下：

typedef struct { Elf32_Word p_type; //此数组元素描述的段的类型，或者如何解释此数组元素的信息。 Elf32_Off p_offset; //此成员给出从文件头到该段第一个字节的偏移 Elf32_Addr p_vaddr; //此成员给出段的第一个字节将被放到内存中的虚拟地址 Elf32_Addr p_paddr; //此成员仅用于与物理地址相关的系统中。System V忽略所有应用程序的物理地址信息。 Elf32_Word p_filesz; //此成员给出段在文件映像中所占的字节数。可以为0。 Elf32_Word p_memsz; //此成员给出段在内存映像中占用的字节数。可以为0。 Elf32_Word p_flags; //此成员给出与段相关的标志。 Elf32_Word p_align; //此成员给出段在文件中和内存中如何对齐。} Elf32_phdr;

p_type：

名称取值说明

PT_NULL0此数组元素未用。结构中其他成员都是未定义的。

PT_LOAD1此数组元素给出一个可加载的段，段的大小由 p_filesz 和 p_memsz描述。文件中的字节被映射到内存段开始处。如果 p_memsz 大于p_filesz，“剩余”的字节要清零。p_filesz 不能大于 p_memsz。可加载的段在程序头部表格中根据 p_vaddr 成员按升序排列。

PT_DYNAMIC2数组元素给出动态链接信息。

PT_INTERP3数组元素给出一个 NULL 结尾的字符串的位置和长度，该字符串将被当作解释器调用。这种段类型仅对与可执行文件有意义（尽管也可能在共享目标文件上发生）。在一个文件中不能出现一次以上。如果存在这种类型的段，它必须在所有可加载段项目的前面。

PT_NOTE4此数组元素给出附加信息的位置和大小。

PT_SHLIB5此段类型被保留，不过语义未指定。包含这种类型的段的程序与 ABI不符。

PT_PHDR6此类型的数组元素如果存在，则给出了程序头部表自身的大小和位置，既包括在文件中也包括在内存中的信息。此类型的段在文件中不能出现一次以上。并且只有程序头部表是程序的内存映像的一部分时才起作用。如果存在此类型段，则必须在所有可加载段项目的前面。

PT_LOPROC~

PT_HIPROC0x70000000~

0x7fffffff此范围的类型保留给处理器专用语义。

好了，本文主要内容就分享到这里，具体可以参看ELF文件详细描述。

责任编辑：haq