论坛中的少有对ELF文件的动态分析，找了一些资料给补上。了解ELF文件的加载和动态执行流程，是学习安全知识和加固的前提。

参考

_周壑: https://www.bilibili.com/video/BV1no4y1U7C6

ELF文件格式解析 https://paper.seebug.org/papers/Archive/refs/elf/Understanding_ELF.pdf

aosp 源码： https://github.com/aosp-mirror/platform_bionic/tree/donut-release

可执行文件格式概述

不同平台的可执行文件是不一样的

• android中的可执行文件是dex文件格式

  • ios是 Mach-O格式
  • windows是PE文件格式
  • linux是ELF文件格式, 相关定义在“/usr/include/elf.h”文件里。

• Linux 文件中的ELF(Executable and Linking Format)文件包括:

  • 可执行文件(Executable File .exec ): 经过链接的、可执行的目标文件，通常也被称为程序

  • 可重定位文件 / 待重定位文件 (Relocatable Object File)(.o) :由源文件编译而成且尚未链接的目标文件，通常以“.o”作为扩展名

  • 共享位目标文件 / 动态链接库文件 (Shared Object File) : 它在以下两种情况下被使用：第一，在连接过程中与其它动态链接库或可重定位文件一起构建新的目标文件；第二，在可执行文件被加载的过程中，被动态链接到新的进程中，成为运行代码的一部分。

    核心转储文件 (Core Dump FIle): 进程意外终止时进程地址空间的转储，也是ELF文件的一种。使用gdb读取这类文件可以辅助调试和查找程序崩溃的原因。

ELF文件 有两种视角可供选择，一种是链接视角，通过节（Section）来进行划分；另一种是运行视角，通过段（Segment）来进行划分。

• ELF 文件头 (ELF header)

  位于文件的最开始处，包含有整个文件的结构信息。

• 程序头表 (program header table)

  在运行过程中是必须的，在连接过程中是可选的，因为它的作用是告诉系统如何创建进程的镜像。

• 节头表 (section header table)

  包含有文件中所有“节”的信息。在连接视图中，“节头表”是必须存在的，文件里的每一个“节”都需要在“节头表”中有一个对应的注册项，这个注册项描述了节的名字、大小等等。

elf 文件静态分析

ELF文件头

相关定义在“/usr/include/elf.h”

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

typedef struct {   unsigned char    e_ident[16];            /* 魔术字符（7f 45(E) 4c(L) 46(F) ...)*/   Elf64_Half    e_type;                    /* 目标文件类型 */   Elf64_Half    e_machine;        /* Architecture */   Elf64_Word    e_version;        /* Object file version */   Elf64_Addr    e_entry;        /* Entry point virtual address */   Elf64_Off    e_phoff;        /* Program header table file offset */   Elf64_Off    e_shoff;        /* Section header table file offset */   Elf64_Word    e_flags;        /* Processor-specific flags */   Elf64_Half    e_ehsize;        /* ELF header size in bytes */   Elf64_Half    e_phentsize;        /* Program header table entry size */   Elf64_Half    e_phnum;        /* Program header table entry count */   Elf64_Half    e_shentsize;        /* Section header table entry size */   Elf64_Half    e_simage-20220726214233481hnum;        /* Section header table entry count */   Elf64_Half    e_shstrndx;        /* Section header string table index */ } Elf64_Ehdr;

描述整个文件的一些基本信息，例如ELF文件类型、版本/ABI版本、目标机器、程序入口、段表和节表的位置和长度等。

使用代码查看信息

节头表（Section header table）

节头表结构

节头表（Section header table）: 保存节的信息，表的每一项都是一个Elf64_Shdr结构体（也称为节描述符）,通过每一个表项可以定位到对应的节，记录了节的名字、长度、偏移、读写权限等信息。

• 文件头中， e_shoff字段记录节头表相对于文件开始处的偏移量， e_shnum 成员指明节头表中包含多少个表项；e_shentsize 成员指明了每一个表项的大小
• 节头表对于程序运行并不是必须的，因为它与程序内存布局无关，是程序头表的任务，所以常有程序去除节头表，以增加反编译器的分析难度。
• 目标文件中的每一个节一定对应有一个节头(section header)，节头中有对节的描述信息；但有的节头可以没有对应的节，而只是一个空的头。

每一个节头表项的结构体如下所示：

1 2 3 4 5 6 7 8 9 10 11 12 13

typedef struct {   Elf64_Word    sh_name;        /* Section name (string tbl index) */   Elf64_Word    sh_type;        /* Section type */   Elf64_Xword    sh_flags;        /* Section flags */   Elf64_Addr    sh_addr;        /* Section virtual addr at execution */   Elf64_Off    sh_offset;        /* Section file offset */   Elf64_Xword    sh_size;        /* Section size in bytes */   Elf64_Word    sh_link;        /* Link to another section */   Elf64_Word    sh_info;        /* Additional section information */   Elf64_Xword    sh_addralign;        /* Section alignment */   Elf64_Xword    sh_entsize;        /* Entry size if section holds table */ } Elf64_Shdr;

• sh_type 本节的类型。

  | 名字 | 值 | 意义 |
  | ------------ | ---------- | ------------------------------------------------------------ |
  | SHT_NULL | 0 | 没有对应的节 |
  | SHT_PROGBITS | 1 | 程序定义节 |
  | SHT_SYMTAB | 2 | 动态连接完整的符号表 |
  | SHT_DYNSYM | 11 | 较小的符号表，专门用于动态连接 |
  | SHT_STRTAB | 3 | 字符串表 |
  | SHT_RELA | 4 | 重定位节 |
  | SHT_HASH | 5 | 哈希表，所有参与动态连接的目标文件都必须要包含<br/>一个符号哈希表。 |
  | SHT_DYNAMIC | 6 | 动态连接信息 |
  | SHT_NOTE | 7 | 标记本文件 |
  | SHT_NOBITS | 8 | 此值表明这一节的内容是空的，节并不占用实际的空间 |
  | SHT_REL | 9 | 重定位节，含有带明确加数的重定位项 |
  | SHT_SHLIB | 10 | 保留值 |
  | SHT_LOPROC | 0x70000000 | 为特殊处理器保留的节类型索引值的下边界 |
  | SHT_HIPROC | 0x7fffffff | 为特殊处理器保留的节类型索引值的上边界 |
  | SHT_LOUSER | 0x80000000 | 为应用程序保留节类型索引值的下边界 |
  | SHT_HIUSER | 0xffffffff | 为应用程序保留节类型索引值的上边界 |

• sh_flags 本节的一些属性，由一系列标志比特位组成，各个比特定义了节的不同属 性，当某种属性被设置时，相应的标志位被设为 1，反之则设为 0。未定义的标志 位被全部置 0。

  | 名字 | 值 | 意义 |
  | ------------- | ---------- | ------------------------------------------------------------ |
  | SHF_WRITE | 0x1 | 本节所包含的内容在进程运行过程中是可写的 |
  | SHF_ALLOC | 0x2 | 本节内容在进程运行过程中要占用内存单元。并不是所有节都会占用实际的内存，有一些起控制作用的节，在目标文件映射到进程空间时，并不需要占用内存。 |
  | SHF_EXECINSTR | 0x4 | 此节内容是指令代码 |
  | SHF_MASHPROC | 0xf0000000 | 保留 |

• sh_info 附加信息

  | sh_type | sh_link | sh_info |
  | ---------------------- | ---------------------------------------------- | ------------------------------------------------------------ |
  | SHT_DYNAMIC | 用于本节中项目的字符串表在节头表中相应的索引值 | 0本节包含动态连接信息，并且可能有 SHF_ALLOC 和 SHF_WRITE 等属性。 是否具有 SHF_WRITE 属性取决于操作系统和处理器。 |
  | SHT_HASH | 用于本节中哈希表的符号表在节头表中相应的索引值 | 0 |
  | SHT_REL /SHT_RELA | 相应符号表在节头表中的索引值 | 本重定位节所应用到目标节在节头表中的索引值 |
  | SHT_SYMTAB /SHT_DYNSYM | 相关字符串表的节头索引 | 符号表中最后一个本地符号的索引值加 1 |
  | 其它 | SHN_UNDEF | 0 |

代码解析如下：

常见的表的属性

.dynsym & .symtab 符号表

• 符号表记录了目标文件中所用到的所有符号信息，通常分为.dynsym和.symtab，前者是后者的子集。

• .dynsym保存了引用自外部文件的符号，只能在运行时被解析

• .symtab还保存了本地符号，用于调试和链接。

• 目标文件通过一个符号在表中的索引值来使用该符号。索引值从0开始计数，但值为0的表项不具有实际的意义，它表示未定义的符号STN_UNDEF。每个符号都有一个符号值（symbol value），对于变量和函数，该值就是符号的地址。

符号表项的格式定义（Elf64_Sym结构体）， 如下所示。

1 2 3 4 5 6 7 8 9

typedef struct {   Elf64_Word    st_name;        /* Symbol name (string tbl index) */   unsigned char    st_info;        /* Symbol type and binding */   unsigned char st_other;        /* Symbol visibility */   Elf64_Section    st_shndx;        /* Section index */   Elf64_Addr    st_value;        /* Symbol value */   Elf64_Xword    st_size;        /* Symbol size */ } Elf64_Sym;

符号表的第一项，即索引值为 STN_UNDEF(0)的这项，其内容与其它项不同

名字	值	意义
st_name	0	无效名字
st_value	0	0值
st_size	0	无效大小
st_info	0	无效类型
st_other	0
st_shndx	SHN_UNDEF	无对应节

• st_value 符号的值。这个值其实没有固定的类型，它可能代表一个数值，也可以是一 个地址，具体是什么要看上下文。

  | 文件类型 | st_name | st_value的意义 |
  | ---------------------- | ---------------- | ------------------------------------------------------------ |
  | 重定位文件 | SHN_COMMON | 是这个节内容的字节对齐数 |
  | 重定位文件 | 普通的字符串索引 | 该符号的起始地址在其所在节中的偏移量，而其所在的节的索引由st_shndx 给出 |
  | 可执行文件和共享库文件 | 普通的字符串索引 | st_value 不再是一个节内的偏移量，而是一个虚拟地址，直接指向符号所在的内存位置 |

  如果一个可执行文件中含有一个共享库文件函数的引用，那么那个共享目标文件的符号表应该含有这个 函数的符号。符号表的 st_shndx 成员值为 SHN_UNDEF，这就告诉了动态连接 器，这个函数的符号定义并不在可执行文件中。如果已经在可执行文件中给这个符 号申请了一个函数连接表项，而且符号表项的 st_value 成员不是 0，那么 st_value 值就将是函数连接表项中第一条指令的地址。否则，st_value 成员是 0。这个函数 连接表项地址被动态连接器用来解析函数地址。

• st_info 符号的类型和属性。st_info 由一系列的比特位构成，标识了“符号绑定 (symbol binding)”、“符号类型(symbol type)”和“符号信息(symbol infomation)” 三种属性。下面几个宏分别用于读取这三种属性值。

  • 符号绑定（ELF32_ST_BIND）

    1 2 3 4 5 6

    名字 | 值 STB_LOCAL | 0 STB_GLOBAL  | 1 STB_WEAK | 2 STB_LOPROC | 13 STB_HIPROC | 15

    | 名字 | 值 | 意义 |
    | ---------- | ---- | ------------------------------------------------------------ |
    | STB_LOCAL | 0 | 表明本符号是一个本地符号。它只出现在本文件中，在本文件外该符号 无效。所以在不同的文件中可以定义相同的符号名，它们之间不会互相影 响。 |
    | STB_GLOBAL | 1 | 表明本符号是一个全局符号。当有多个文件被连接在一起时，在所有文 件中该符号都是可见的。正常情况下，在一个文件中定义的全局符号，一 定是在其它文件中需要被引用，否则无须定义为全局。 |
    | STB_WEAK | 2 | 类似于全局符号，但是相对于 STB_GLOBAL，它们的优先级更低。 全局符号(global symbol)和弱符号(weak symbol)在以下两方面有区别：<br />- 当连接编辑器把若干个可重定位目标文件连接起来时，同名的 STB_GLOBAL 符号不允许出现多次。而如果在一个目标文件中已经定义 了一个全局的符号(global symbol)，当一个同名的弱符号(weak symbol)出 现时，并不会发生错误。连接编辑器会以全局符号为准，忽略弱符号。与 全局符号相似，如果已经存在的是一个公用符号，即 st_shndx 域为 SHN_COMMON 值的符号，当一个同名的弱符号(weak symbol)出现时， 也不会发生错误。连接编辑器会以公用符号为准，忽略弱符号。<br />- 在查找符号定义时，连接编辑器可能会搜索存档的库文件。如 果是查找全局符号，连接编辑器会提取包含该未定义的全局符号的存档成 员，存档成员可能是一个全局的符号，也可能是弱符号；而如果是查找弱 符号，连接编辑器不会去提取存档成员。未解析的弱符号值为 0。 |
    | STB_LOPROC | 13 | |
    | STB_HIPROC | 15 | |

  • 符号类型(ELF32_ST_TYPE)

    | 名字 | 值 | 意义 |
    | ----------- | ---- | ------------------------------------------------------------ |
    | STT_NOTYPE | 0 | 本符号类型未指定 |
    | STT_OBJECT | 1 | 本符号是一个数据对象，比如变量、数组等 |
    | STT_FUNC | 2 | 本符号是一个函数，或者其它的可执行代码。函数符号在共享目标文件 中有特殊的意义。当另外一个目标文件引用一个共享目标文件中的函数符 号时，连接编辑器为被引用符号自动创建一个连接表项。非 STT_FUNC 类型的共享目标符号不会通过这种连接表项被自动引用 |
    | STT_SECTION | 3 | 本符号与一个节相关联，用于重定位，通常具有 STB_LOCAL 属性 |
    | STT_FILE | 4 | 本符号是一个文件符号，它具有 STB_LOCAL 属性，它的节索引值是 SHN_ABS。在符号表中如果存在本类符号的话，它会出现在所有 STB_LOCAL 类符号的前部。 |
    | STT_LOPROC | 13 | 这一区间的符号类型为特殊处理器保留 |
    | STT_HIPROC | 15 | 这一区间的符号类型为特殊处理器保留 |

• st_shndx 任何一个符号表项的定义都与某一个“节”相联系，因为符号是为节而定 义，在节中被引用。本数据成员即指明了相关联的节。本数据成员是一个索引值， 它指向相关联的节在节头表中的索引。在重定位过程中，节的位置会改变，本数据 成员的值也随之改变，继续指向节的新位置。当本数据成员指向下面三种特殊的节 索引值时，本符号具有如下特别的意义：

  | 值 | 意义 |
  | -------------- | ------------------------------------------------------------ |
  | 普通的节的索引 | 指明了相关联的节 |
  | SHN_ABS | 符号的值是绝对的，具有常量性，在重定位过程中，此值不需要改变。 |
  | SHN_COMMON | 本符号所关联的是一个还没有分配的公共节，本符号的值规定了其内容的 字节对齐规则，与 sh_addralign 相似。也就是说，连接器会为本符号分配存储 空间，而且其起始地址是向 st_value 对齐的。本符号的值指明了要分配的字 节数。 |
  | SHN_UNDEF | 当一个符号指向第 1 节(SHN_UNDEF)时，表明本符号在当前目标文件中 未定义，在连接过程中，连接器会找到此符号被定义的文件，并把这些文件 连接在一起。本文件中对该符号的引用会被连接到实际的定义上去。 |

代码解析结果如下：

程序头表(program header table)

可执行文件和共享目标文 件（动态连接库）是程序的静态存储形式。要执行一个程序，系统要先把相应的可 执行文件和动态连接库装载到进程空间中，这样形成一个可运行的进程的内存空间 布局，也可以称它为“进程镜像”。一个已装载完成的进程空间会包含多个不同的 “段(segment)”，比如代码段(text segment)，数据段(data segment)，堆栈段(stack segment)等等。

程序头结构

描述一下与运行程序相关的目标文件结构, 它指明了文件中各个段的位置，还包含一些用于创建内存镜像的必要内容。

• 程序头表(program header table)是一个数组， 数组中的每一个元素称为“程序头(program header)”，每一个程序头描述了一个 “段(segment)”或者一块用于准备执行程序的信息。
• 一个目标文件中的“段 (segment)”包含一个或者多个“节(section)”。
• 程序头只对可执行文件或共享目标 文件有意义，对于其它类型的目标文件，该信息可以忽略。
• 在目标文件的文件头 (elf header)中，e_phentsize 和 e_phnum 成员指定了程序头的大小 。

程序头的结构

1 2 3 4 5 6 7 8 9 10

typedef struct {     Elf32_Word p_type;     Elf32_Off p_offset;     Elf32_Addr p_vaddr;     Elf32_Addr p_paddr;     Elf32_Word p_filesz;     Elf32_Word p_memsz;     Elf32_Word p_flags;     Elf32_Word p_align; } Elf32_Phdr;

• p_type 此数据成员说明了本程序头所描述的段的类型，或者如何解析本程序头的信息。

  | 名字 | 值 | 意义 |
  | ----------- | ---------- | ------------------------------------------------------------ |
  | PT_NULL | 0 | 此类型表明本程序头是未使用的，本程序头内的其它成员值均无意义。具 有此种类型的程序头应该被忽略。 |
  | PT_LOAD | 1 | 此类型表明本程序头指向一个可装载的段。段的内容会被从文件中拷贝到 内存中。一般来说，一个动态链接的ELF可执行文件通常包含两个可装载的段。 段类型都为PT_LOAD<br />- 一个是存放程序代码的text段<br />- 另一个是存放全局变量和动态链接信息的data段。 |
  | PT_DYNAMIC | 2 | 此类型表明本段指明了动态连接的信息。 |
  | PT_INTERP | 3 | 本段指向了一个以”null”结尾的字符串，这个字符串是一个 ELF 解析器的 路径。这种段类型只对可执行程序有意义，当它出现在共享目标文件中时， 是一个无意义的多余项。在一个 ELF 文件中它最多只能出现一次，而且必须 出现在其它可装载段的表项之前。 |
  | PT_NOTE | 4 | 本段指向了一个以”null”结尾的字符串，这个字符串包含一些附加的信息。 |
  | PT_SHLIB | 5 | 该段类型是保留的，而且未定义语法。UNIX System V 系统上的应用程序 不会包含这种表项。 |
  | PT_PHDR | 6 | 此类型的程序头如果存在的话，它表明的是其自身所在的程序头表在文件 或内存中的位置和大小。这样的段在文件中可以不存在，只有当所在程序头 表所覆盖的段只是整个程序的一部分时，才会出现一次这种表项，而且这种 表项一定出现在其它可装载段的表项之前。 |
  | PT_LOPROC | 0x70000000 | 类型值在这个区间的程序头是为特定处理器保留的 |
  | PT_HIPROC | 0x7fffffff | 类型值在这个区间的程序头是为特定处理器保留的 |

  所有程序头的段类型域 p_type 都是可选项，不是必须存在的。

代码分析结果如下

常见的段的结构

代码段text segment (.text)

代码段(.text)或直译为“文本段”，包含的是只读的指令和数据，一般情况下会 包含以下这些节。不过这里给出的只是一个典型的例子，一个实际的更复杂的代码 段可能包含更多的节。

数据段(data segment)

数据段(data segment)包含可写的数据和指令，典型的数据段包含以下节。

ELF 加载流程动态分析

ELF 由谁加载

ELF 文件的动态加载由 /system/bin/linker(旧版) ld.so(新版) 加载， 该加载器由段表[1]指定

/system/bin/linker 主要功能为

1. 映射要执行的ELF到内存中
2. 为ELF文件导入需要的模块
3. 重定位

源码分析整个加载过程： https://github.com/aosp-mirror/platform_bionic/tree/donut-release

映射内存

加载ELF第一步： 映射内存

linker 将类型为PT_LOAD的programe通过map映射到内存中, 如下所示

很明显这两个段， 一个是可执行的代码段， 一个是可写的数据段

以可执行文件(ls)为例， 映射到内存中，如下所示, 两个段被映射到了4个部分

其中 acec9000-acf0b000 是代码段， acf0c000-acf13000 整个部分是数据段

1 2 3 4 5 6 7 8

acec9000-acf0b000 r-xp 00000000 fe:20 14205      /data/user/ls     大小: 4 20 00 acf0c000-acf0e000 r--p 00042000 fe:20 14205      /data/user/ls   大小： 20 00 acf0e000-acf0f000 rw-p 00044000 fe:20 14205      /data/user/ls   大小： 10 00 acf0f000-acf13000 rw-p 00000000 00:00 0                          大小： 40 00

如果想要详细了解映射， 参考：https://www.bilibili.com/video/BV1SM4y157WE/?spm_id_from=333.999.0.0&vd_source=ca069728de78926f6ac8fc77093830f8

关键代码解析如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35

// 分析内存映射情况 System.out.println(); System.out.println("+++++++++++++++++++ 内存映射分析 ++++++++++++++++++"); for(ElfType32.elf32_phdr phdr : type_32.phdrList){     if(VariableUtils.bytes2int(phdr.p_type) == ElfType32.PT_LOAD){         int mem_vaddr_align = (VariableUtils.bytes2int(phdr.p_vaddr)/0x1000)*0x1000;         int mem_end_vaddr = VariableUtils.bytes2int(phdr.p_vaddr) + VariableUtils.bytes2int(phdr.p_memsz);         int mem_end_vaddr_align = mem_end_vaddr/0x1000*0x1000 + (mem_end_vaddr % 0x1000 != 0 ? 1 : 0)*0x1000;         int file_offset_align = (VariableUtils.bytes2int(phdr.p_offset)/0x1000)*0x1000;         int file_end_vaddr = VariableUtils.bytes2int(phdr.p_vaddr) + VariableUtils.bytes2int(phdr.p_filesz);         int file_end_vaddr_align = file_end_vaddr/0x1000*0x1000 + (file_end_vaddr % 0x1000 != 0 ? 1 : 0)*0x1000;         ElfType32.Elf32_MemMap memMap = new ElfType32.Elf32_MemMap();         memMap.mem_vaddr_align = mem_vaddr_align;         memMap.mem_end_vaddr_align = mem_end_vaddr_align;         memMap.file_offset = file_offset_align;         memMap.file_end_vaddr_align = file_end_vaddr_align;         System.out.print(" 内存起始地址: "+ VariableUtils.bytes2HexString(VariableUtils.int2bytes(mem_vaddr_align)) + " - " +VariableUtils.bytes2HexString(VariableUtils.int2bytes(mem_end_vaddr_align))  );         System.out.print(" 内存大小: "+ VariableUtils.bytes2HexString(VariableUtils.int2bytes(mem_end_vaddr_align - mem_vaddr_align )));         System.out.print(" 文件偏移起始地址: "+ VariableUtils.bytes2HexString(VariableUtils.int2bytes((VariableUtils.bytes2int(phdr.p_offset)/0x1000)*0x1000)));         System.out.println();         if( mem_end_vaddr_align- file_end_vaddr_align > 0){             System.out.print(" * (未映射到文件部分)内存起始地址: "+ VariableUtils.bytes2HexString(VariableUtils.int2bytes(file_end_vaddr_align)) + " - " +VariableUtils.bytes2HexString(VariableUtils.int2bytes(mem_end_vaddr_align))  );             System.out.print(" 内存大小: "+ VariableUtils.bytes2HexString(VariableUtils.int2bytes(mem_end_vaddr_align - file_end_vaddr_align)));             System.out.println();         }     }     if(VariableUtils.bytes2int(phdr.p_type) == ElfType32.PT_GNU_RELRO){         int mem_vaddr = (VariableUtils.bytes2int(phdr.p_vaddr)/0x1000)*0x1000;         int memsz_align = VariableUtils.bytes2int(phdr.p_memsz)/0x1000 + (VariableUtils.bytes2int(phdr.p_memsz) % 0x1000 != 0 ? 1 : 0);         int mem_end_vaddr = mem_vaddr + memsz_align*0x1000;         System.out.print(" * (只读的数据段部分)内存起始地址: "+ VariableUtils.bytes2HexString(VariableUtils.int2bytes(mem_vaddr)) + " - " +VariableUtils.bytes2HexString(VariableUtils.int2bytes(mem_end_vaddr))  );         System.out.print("  内存起始地址: "+ VariableUtils.bytes2HexString(VariableUtils.int2bytes(memsz_align*0x1000)));         System.out.println();     } }

Dynamic Segment 动态段解析

解析 programe[Dynamic Segment] 动态段， 指定了动态链接过程中所需要的各种信息。

每8个字节为一项 { 类型， value}

1 2 3 4 5 6 7 8

typedef struct {     Elf32_Sword d_tag;            // d_tag 控制着对 d_un 的解析     union {         Elf32_Word d_val;        // d_val 类型为 Elf32_Word 的目标项代表的是整型数。         Elf32_Addr d_ptr;        // d_ptr 类型为 Elf32_Addr 的目标项代表的是进程空间里的地址。     } d_un; } Elf32_Dyn; extern Elf32_Dyn _DYNAMIC[];

下表列出了可执行文件或共享目标文件中所要求的标记(d_tag)。如果一个标记 被置为“必需”，那么在 ELF 文件的动态连接数组中就必须包含一个此类型的 项；如果被置为“可选”，那就不是必需的，可以有也可以没有。

代码解析如下：

DT_STRTAB 字符串表

解析 字符串表(d_tag=5 DT_STRTAB, d_value 为 内存偏移 )

内存偏移1A20, 在第一个段内，所以文件偏移也是1A20

关键代码解析如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42

// 读取字符串表的内容 System.out.println(); System.out.println("+++++++++++++++++++DT_STRTAB of dynamic segment++++++++++++++++++"); int offset = 1; while (true){     String str = DT_STRTAB_getString(fileByteArys, offset);     System.out.println("偏移： 0x" + Integer.toHexString(offset) + " 字符串: " + str);     if(str.equals("")){         break;     }     offset += str.length()+1; }     /**  解析字符串表 DT_STRTAB      *      * @param fileByteArys 文件首地址      * @param offset_strtab 字符串表偏移      * @return      */     public static String DT_STRTAB_getString(byte[] fileByteArys, int offset_strtab){         // 遍历字符串表         int offset = 0;         for (int i = 0; i < type_32.dynamicList.size(); ++i) {             if( VariableUtils.bytes2int(type_32.dynamicList.get(i).d_tag) == ElfType32.DT_STRTAB){                 offset = VariableUtils.bytes2int(type_32.dynamicList.get(i).d_val_ptr );             }         }         // 内存偏移转文件偏移         offset = vaddr2offset(offset);         return VariableUtils.bytes2String(fileByteArys, offset + offset_strtab);     }     // 内存偏移转文件偏移     public static int vaddr2offset(int vaddr){         for (int i = 0; i < type_32.memList.size(); ++i) {             if( type_32.memList.get(i).isInSegment(vaddr)){                 return type_32.memList.get(i).vaddr2offset(vaddr);             }         }         return 0;     }

DT_NEEDED 导入库表

解析 导入库表(d_tag=1 DT_NEEDED, d_value 为相对字符串表DT_STRAB的offset)

d_value是相对字符串表DT_STRAB的内存偏移， 也都在第一个段内，所以文件偏移与内存偏移一致

关键代码解析如下：

1 2 3 4 5 6 7 8 9 10 11

// 读取导入库的内容 System.out.println(); System.out.println("+++++++++++++++++++导入库 of dynamic segment++++++++++++++++++"); // 遍历字符串表 for (int i = 0; i < type_32.dynamicList.size(); ++i) {     if( VariableUtils.bytes2int(type_32.dynamicList.get(i).d_tag) == ElfType32.DT_NEEDED){         vaddr = VariableUtils.bytes2int(type_32.dynamicList.get(i).d_val_ptr);         String str = DT_STRTAB_getString(fileByteArys, vaddr);         System.out.println("导入库： "+ str);     } }

DT_SYMTAB 符号表

解析符号表(类型=6 DT_SYMTAB, d_value 为符号表的offset)，符号表的每一项有16 字节{名字偏移，地址，大小,属性}, 尺寸没有明确指定（在节表中有指明符号表的大小，但不应该依赖于节表）

可以通过hash表来分析符号表的大小

https://stackoverflow.com/questions/59411449/what-is-the-entry-count-of-elf-dynamic-symbol-table

符号表表项的意义具体参考： .dynsym & .symtab 符号表

d_value是内存偏移， 也都在第一个段内，所以文件偏移与内存偏移一致

关键解析代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

//读取符号表信息(Symbol Table) System.out.println(); System.out.println("+++++++++++++++++++符号表 of dynamic segment++++++++++++++++++"); // 通过表的类型 DT_SYMTAB 定位符号表 for (ElfType32.Elf32_Dynamic phdr : type_32.dynamicList) { if( VariableUtils.bytes2int(phdr.d_tag) == ElfType32.DT_SYMTAB){ offset_sym = VariableUtils.bytes2int(phdr.d_val_ptr); } } // 内存偏移转换为文件偏移 type_32.symList_d = vaddr2offset(offset_sym); System.out.println("DT_SYMTAB符号表 基址： 0x"+ Integer.toHexString(offset_sym) ); // 确定符号表的总项数, 通过最后一项为0来确定 parseSymbolTableListD(fileByteArys, type_32.symList_d, 1);     /**      * 解析Symbol Table内容      * @param header 文件字节      * @param offset_symtab 符号表偏移      * @param offset 要查询的符号的索引      */     public static ElfType32.Elf32_Sym parseSymbolTableListD(byte[] header, int offset_symtab, int offset){         int header_size = 16;//16个字节         byte[] des = new byte[header_size];         des = VariableUtils.bytesSplite(header, offset*header_size + offset_symtab, header_size);         ElfType32.Elf32_Sym obj =parseSymbolTable(des);         System.out.println("正在解析的符号： "+ obj.st_name_toString(header));         System.out.println(obj.toString());         return obj;     }

DT_JMPREL 导入表

解析 导入表(类型=23 DT_JMPREL), 导入表的每一项有8 字节{重定位地址， 属性(1)，符号表索引(3)}, 尺寸为 (类型=2 DT_PLTRELSZ ) 字节决定

1 2 3 4

typedef struct elf32_rel {   Elf32_Addr    r_offset;            // 要重定位地址的地址   Elf32_Word    r_info;                // 属性(1)，符号表索引(3) } Elf32_Rel;

• r_info[0] 三种类型

  • R_ARM_JUMP_SLOT 22 (导入表中我只看到这种类型)

    直接替换地址

  • R_ARM_GLOB_DAT 21

    直接替换地址

  • R_ARM_ABS32 2

    不是替换地址， 而是在找到符号地址的基础上， 加上原本地址存有的数值

实际上导入表DT_JMPREL 导入的是函数地址， 对于其他模块变量的导入在后面的重定位表中实现

首先在动态段中定位导入表的内存偏移

在之前的内存映射关系中， 0x51d4 < 0x 00 04 20 00, 所以在第一个段中， 内存偏移等价于文件偏移

可以发现ida的静态分析可以解析出这些内容

以__libc_int符号为例， linker首先遍历之前解析的所有导入库的导出符号，获取同名的导出符号的地址，然后替换到模块中的内存偏移地址0x44B78 的位置

这种寻找符号的方法导致了一种与windows 的PE文件格式不同的地方， ELF 文件的导入库与导入函数之间并不是强相关。

比如在linux的hook中，通过LD_PRELOAD环境变量的hook函数，并不需要指定模块名， 只需要函数原型相同即可完成hook。参考 https://www.anquanke.com/post/id/254388

• 未导入符号地址， 该处的 0x9cF0并不能指向函数

  

  该地址被如下代码引用， 代码结合起来类似于 jmp [0x44B78] , 这就是R_ARM_JUMP_SLOT 22类型的导入地址使用方式

  

• 导入符号地址

  

关键代码解析：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36

public static class Elf32_Jmp {     public byte[] r_offset = new byte[4];     public byte[] r_info = new byte[4];     public Elf32_Jmp() {     }     public String toString() {         byte[] info = {r_info[1], r_info[2],r_info[3],0};         return "r_offset(存放导入符号地址的地址(类似与windows的IAT（导入地址表）)， 相对于 .dynstr 的 sh_offset):" + VariableUtils.bytes2HexString(this.r_offset) +                 "\n属性(虚拟地址，指向符号所在的内存地址):" + Byte.toString(r_info[0]) + e_type_toString()+                 "\n符号(虚拟地址，指向符号所在的内存地址):" +  VariableUtils.bytes2HexStringReverse(info);     }     public String r_sym_toString(byte[] fileByteArys){         byte[] info = {r_info[1], r_info[2],r_info[3],0};         ElfType32.Elf32_Sym sym = AndroidElfParser.parseSymbolTableListD(fileByteArys, AndroidElfParser.type_32.symList_d,  VariableUtils.bytes2int(info));         return sym.st_name_toString(fileByteArys);     }     public String e_type_toString(){         final int R_ARM_JUMP_SLOT = 22;         final int R_ARM_GLOB_DAT = 21;         final int R_ARM_ABS32 = 2;         int value = Byte.toUnsignedInt(r_info[0]);         switch (value){             case R_ARM_JUMP_SLOT:                 return "R_ARM_JUMP_SLOT 直接替换地址";             case R_ARM_GLOB_DAT:                 return "R_ARM_GLOB_DAT 直接替换地址";             case R_ARM_ABS32:                 return "R_ARM_ABS32 不是替换地址， 而是在找到符号地址的基础上， 加上原本地址存有的数值";             default:                 return "其他类型";         }     } }

DT_REL 重定位表

解析 重定位表(类型=17 DT_REL), 尺寸为 (类型=18 DT_RELSZ ) 字节决定, 重定位表的每一项有16 字节{重定位地址， 属性(1)，符号表索引(3)}

重定位表的解析与导入表完全相同，导入符号的处理时，会将这两个表一起用于搜索符号, 重定位表有一部分是其他模块变量的导入表

表项结构如下

1 2 3 4

typedef struct elf32_rel {   Elf32_Addr    r_offset;            // 要重定位地址的地址   Elf32_Word    r_info;                // 属性(1)，符号表索引(3) } Elf32_Rel;

• r_info[0] 三种类型

  • R_ARM_RELATIVE 23 只有该项与R_ARM_JUMP_SLOT 22 数值上的不同

    不是替换地址， 而是在找到符号地址的基础上， 加上原本地址存有的数值

  • R_ARM_GLOB_DAT 21

    直接替换地址

  • R_ARM_ABS32 2

    不是替换地址， 而是在找到符号地址的基础上， 加上原本地址存有的数值

先使用代码解析重定位表

首先定位第一个重定位的符号， 没有符号名， 重定位类型为 R_ARM_RELATIVE 23

这要重定位的是全局字符串， 大多数也都是字符串需要重定位

而重定位类型 R_ARM_GLOB_DAT 21 的使用通常作为函数指针直接使用

DT_GUN_HASH 导出/hash表

解析 导出/hash表表(类型=0x6ffffef5 DT_GUN_HASH)

1 2 3 4 5 6 7 8 9 10 11 12 13

struct{     uint32_t nbucket;        // bucket数组的个数, 每个bucket 4个字节     uint32_t symoffset;        // chain 表实际开始的符号表索引位置， 所以理论位置为chain-4*symoffset     /* Bloom Filter用于提前停止查找丢失的符号, 本节不研究*/     uint32_t bloom_size;     // 指定bloom数组的个数, 每个bloom 4个字节     uint32_t bloom_shift;     uint32_t bloom[bloom_size]; /* uint64_t for 64-bit binaries */     /*bucket     每个bucket 4个字节,是符号表中的索引, 索引*0x10 + 符号表偏移 = 函数地址     */     uint32_t bucket[nbucket];         uint32_t chain[];            // chain 是符号名的hash };

关于这个表的具体解析，参考： https://flapenguin.me/elf-dt-gnu-hash

下面这一套系统是用于快速索引导出表的一套结构， 理论上chain[]存储的是符号表的hash中的前31位， 所以项数nchain必须等于符号表的个数，不过由于符号表开始的一部分是导入表和重定位表的内容，为了减少空间的浪费所以chain表是从sym_tab的symoffset项开始的。

如下所示的一个哈希函数输入一个符号名，输出一个值用于计算 bucket 索引。如果给出一个符号名，经哈希函数计算得到值 x，那么 x%nbucket 是 bucket 表内的索引，bucket[x%nbucket] 给出一个符号表的索引值 y，y 同时也是 chain 表内的索引值。如果chain[y]前31位与hash值不匹配，chain[y]第32位是0则继续向下匹配，否则结束匹配， 说明这个导出表中并不含有此符号。继续遍历下一个模块的导出表.

哈希函数(hashing function)

1 2 3 4 5 6 7 8 9 10 11 12

unsigned long elf_hash(const unsigned char *name) {     unsigned long h = 0, g;     while (*name)     {         h = (h << 4) + *name++;         if (g = h & 0xf0000000)         h ^= g >> 24;         h &= ~g;     }     return h; }

关键解析代码:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

public static class Elf32_hash {     // bucket数组的个数, 每个bucket 4个字节     public byte[] nbucket = new byte[4];     // chain 表实际开始的符号表索引位置， 所以理论位置为chain-4*symoffset     public byte[] symoffset = new byte[4];     /* Bloom Filter用于提前停止查找丢失的符号, 本节不研究*/     public byte[] bloom_size = new byte[4]; // 指定bloom数组的个数, 每个bloom 4个字节     public byte[] bloom_shift = new byte[4]; /* uint64_t for 64-bit binaries */     public byte[] bloom;     /*bucket     共有 nbucket 个bucket     每个bucket 4个字节,是符号表中的索引, 索引*0x10 + 符号表偏移 = 函数地址     */     public int[] bucket;     // chain 是符号名的hash     public int[] chain;     public void getBucketArray(byte[] fileByteArys, int offset){         int num = VariableUtils.bytes2int(nbucket);         bucket = new int[num];         for( int i =0; i<num;i++){             bucket[i] =  VariableUtils.bytes2int(VariableUtils.bytesSplite(fileByteArys, offset+VariableUtils.bytes2int(bloom_size)*4 + 0x10 + i*4, 4));         }     }     public byte[] getChainArray(byte[] fileByteArys, int offset, int index){         int num = VariableUtils.bytes2int(nbucket);         int chain_offset = offset+VariableUtils.bytes2int(bloom_size)*4 + 0x10 + num*4;         return VariableUtils.bytesSplite(fileByteArys,index*4 + chain_offset, 4);     }     public String toString() {         return "nbucket(bucket数组的个数, 每个bucket 4个字节):" + VariableUtils.bytes2HexString(this.nbucket) +                 "\nsymoffset(chain 表实际开始的符号表索引位置， 所以理论位置为chain-4*symoffset):" + VariableUtils.bytes2HexString(this.symoffset) +                 "\nbloom_size(指定bloom数组的个数, 每个bloom 4个字节):" + VariableUtils.bytes2HexString(this.bloom_size) +                 "\nbloom_shift:" + VariableUtils.bytes2HexString(this.bloom_shift);     } }

源码： https://github.com/overturncat/reverse_android/tree/master/ELF%20%E6%96%87%E4%BB%B6%E8%A7%A3%E6%9E%90

看雪2022 KCTF 秋季赛 防守篇规则，征题截止日期11月12日！（iPhone 14等你拿！）

最后于 2022-9-30 08:57 被mb_svatpqwc编辑 ，原因：