ELF 文件结构与分析

本文主要整理与学习了 ELF 文件的基本格式, 使用 readelf, gdb, objdump 等工具实际分析了 ELF 部分节区的字段细节, 但受于篇幅限制, 未对与 ELF 关联甚深的程序动静态链接、加载过程进行深入分析, 因此本文仅作为 ELF 基本结构的一个基本介绍与入门.

ELF 简介

可执行与可链接格式 ELF (Extensible Linking Format) 是一种用于可执行文件、目标代码、共享库和内核转储的通用标准文件格式, 主要在类Unix系统中使用. ELF 格式具有灵活性、可扩展性和跨平台性, 能在许多不同的硬件平台上被许多不同的操作系统所采用.

ELF 的主要使用场景如下:

• 可执行文件; 当运行 Linux Shell 上的各种命令时(ls, grep) 时, 都是执行的 ELF 格式的文件. 其包含程序的机器代码和必要的元数据, 定义入口点、程序头表等执行所需信息, 加载器(loader)能直接将其映射到内存并执行.

• 动态库/共享库(.so 文件); 共享库允许多个程序共享同一份代码，节省内存. 其支持动态链接，程序运行时才加载所需库

  • 动态库与共享库本质是两个名称的一个东西, 例如在 Windows 下的 .dll 动态链接库 Dynamic Link Library, 在 Linux/Unix 下的 .so 共享对象(Shared Object)

• 目标文件(.o 文件); 目标文件是那些编译但未链接的中间文件, 其包含编译后的机器代码, 但不能直接执行, 其保存了符号表、重定位信息等待链接器处理, 链接器最终将多个.o文件合并为可执行文件或共享库; 目标文件允许分离编译，提高构建大型项目的效率

• 静态库文件(.a 文件); 静态库本质上是多个目标文件(.o)的归档集合, 在链接时相关代码会被直接复制到最终的可执行文件中, 因此部署更加简单, 不依赖外部库

• 内核模块(.ko 文件); 内核模块作为 ELF 文件包含了特殊的段和符号信息, 如 .modinfo 节包含模块元数据(作者、描述、版本等), .module_layout 存储内核版本和布局信息, .symtab和.strtab包含大量内核特定符号等

• 内核转储文件(coredump); 系统崩溃或程序异常终止时生成的调试信息, 记录程序崩溃时的内存状态、寄存器值等信息

ELF 文件基本结构

ELF 格式的文件可能既会参与程序链接又会参与程序执行, 根据使用过程的不同, 其被设计为同时拥有两种并行的视图:

• 链接视图(Linking View): 主要用于链接器处理, 关注节(sections)

• 执行视图(Execution View): 主要用于加载器处理, 关注段(segments)

ELF 文件的两种视图

总的来说, ELF 可以分为四大部分: ELF Header, ELF Program Header Table (或称Program Headers、程序头)、ELF Section Header Table (或称Section Headers、节头表)以及若干ELF Sections.

• 尽管图中是按照 ELF 头, 程序头部表、节区、节区头部表的顺序排列的, 但实际上除了 ELF 头部表以外, 其它部分都没有严格的的顺序.

ELF 不同组成部分的索引关系

ELF Header

ELF 头部的 ELF Header 给出了整个文件的组织情况, 使用 readelf -h 可以看到对应的内容. 使用 g++ 不加任何额外选项的编译一段简单的 C代码, 生成的可执行文件的头信息如下:

 1$ readelf -h a.out
 2ELF Header:
 3  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
 4  Class:                             ELF64
 5  Data:                              2's complement, little endian
 6  Version:                           1 (current)
 7  OS/ABI:                            UNIX - System V
 8  ABI Version:                       0
 9  Type:                              DYN (Position-Independent Executable file)
10  Machine:                           Advanced Micro Devices X86-64
11  Version:                           0x1
12  Entry point address:               0x2210
13  Start of program headers:          64 (bytes into file)
14  Start of section headers:          55040 (bytes into file)
15  Flags:                             0x0
16  Size of this header:               64 (bytes)
17  Size of program headers:           56 (bytes)
18  Number of program headers:         13
19  Size of section headers:           64 (bytes)
20  Number of section headers:         32
21  Section header string table index: 31

其中比较重要的字段:

• 魔数 Magic; 作为 ELF 文件的签名, 总是以固定的字节序列开始: 0x7F后跟ASCII码"ELF"(45 4c 46). 操作系统通过检查这个魔数来确认文件是ELF格式. 后面的字节包含了其他元信息如位宽、字节序等.

• 文件类型 Type: ELF 文件主要有四种类型: 可重定位文件 ET_REL、可执行文件ET_EXEC, 共享目标文件ET_DYN、核心转储文件ET_CORE. 但是可以看到, 这里我们使用 g++ 生成的是一个 DYN 类型的文件, 括号里进一步说明这是一个 PIE 程序, 这不是一个传统的 EXEC 类型的可执行文件, 这是由于安全考虑的演进结果.

  • 问题背景: 传统上, 可执行文件是 EXEC 类型, 它们有固定的加载地址. 但随着安全威胁的增加, 特别是缓冲区溢出和返回导向编程(ROP)攻击, 操作系统引入了地址空间布局随机化(ASLR)作为防御机制. 但 ASLR 最初只能随机化共享库和堆栈的位置, 而传统 EXEC 类型的可执行文件主体依然加载在固定地址, 成为攻击者的目标. 为解决这个问题, PIE(位置无关可执行文件)被开发出来, 允许整个程序(包括代码段)被随机加载.

  • 工作原理: 当 g++ 生成 PIE 可执行文件时，其使用相对寻址而非绝对寻址, 编译所有代码为位置无关代码(PIC), 并将可执行文件标记为 DYN 类型

  • 程序加载: 操作系统加载器看到 DYN 类型的可执行文件时, 会将其当作共享库一样处理: 随机选择一个基地址, 然后相应调整所有内部引用. 这种行为很像动态库, 因此这些文件被标记为 DYN 类型, 尽管它们实际上是可执行文件.

  • 使用 g++ -no-pie 选项进行编译程序, 即可编译一个传统的 EXEC 类型的可执行文件.

• 兼容性相关字段, 包括 Machine 目标架构, Class 类别, Data 数据编码等

• 该ELF 文件结构相关字段, 包括程序头表、节头表的偏移量、长度与数量等

程序头表

如果程序头部表(Program Header Table)存在的话, 它会告诉系统如何创建进程. 用于生成进程的目标文件必须具有程序头部表, 但是重定位文件不需要这个表.

一个可执行文件(PIE)的程序头表示例如下:

 1$ readelf -l a.out
 2
 3Elf file type is DYN (Position-Independent Executable file)
 4Entry point 0x21f0
 5There are 13 program headers, starting at offset 64
 6
 7Program Headers:
 8  Type           Offset             VirtAddr           PhysAddr
 9                 FileSiz            MemSiz              Flags  Align
10  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040
11                 0x00000000000002d8 0x00000000000002d8  R      0x8
12  INTERP         0x0000000000000318 0x0000000000000318 0x0000000000000318
13                 0x000000000000001c 0x000000000000001c  R      0x1
14      [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
15  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000
16                 0x0000000000001278 0x0000000000001278  R      0x1000
17  LOAD           0x0000000000002000 0x0000000000002000 0x0000000000002000
18                 0x0000000000003579 0x0000000000003579  R E    0x1000
19  LOAD           0x0000000000006000 0x0000000000006000 0x0000000000006000
20                 0x0000000000001780 0x0000000000001780  R      0x1000
21  LOAD           0x0000000000007da0 0x0000000000008da0 0x0000000000008da0
22                 0x0000000000000358 0x00000000007a15f0  RW     0x1000
23  DYNAMIC        0x0000000000007db0 0x0000000000008db0 0x0000000000008db0
24                 0x0000000000000210 0x0000000000000210  RW     0x8
25  NOTE           0x0000000000000338 0x0000000000000338 0x0000000000000338
26                 0x0000000000000040 0x0000000000000040  R      0x8
27  NOTE           0x0000000000000378 0x0000000000000378 0x0000000000000378
28                 0x0000000000000044 0x0000000000000044  R      0x4
29  GNU_PROPERTY   0x0000000000000338 0x0000000000000338 0x0000000000000338
30                 0x0000000000000040 0x0000000000000040  R      0x8
31  GNU_EH_FRAME   0x0000000000006068 0x0000000000006068 0x0000000000006068
32                 0x0000000000000454 0x0000000000000454  R      0x4
33  GNU_STACK      0x0000000000000000 0x0000000000000000 0x0000000000000000
34                 0x0000000000000000 0x0000000000000000  RW     0x10
35  GNU_RELRO      0x0000000000007da0 0x0000000000008da0 0x0000000000008da0
36                 0x0000000000000260 0x0000000000000260  R      0x1
37
38 Section to Segment mapping:
39  Segment Sections...
40   00
41   01     .interp
42   02     .interp .note.gnu.property .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt
43   03     .init .plt .text .fini
44   04     .rodata .eh_frame_hdr .eh_frame .gcc_except_table
45   05     .init_array .fini_array .dynamic .got .got.plt .data .bss
46   06     .dynamic
47   07     .note.gnu.property
48   08     .note.ABI-tag .note.gnu.build-id
49   09     .note.gnu.property
50   10     .eh_frame_hdr
51   11
52   12     .init_array .fini_array .dynamic .got

每个程序头对应的字段含义如下:

段类型

段的类型 p_type 如下表所示.

需要注意, 程序头部表中的段类型又可以分为基本段和扩展段两大类:

• 基本段 是ELF规范最初定义的标准段类型, 在所有符合ELF标准的系统中都被支持和识别. 这些段类型构成了ELF可执行文件的基础结构, 对于程序的加载和执行是必不可少的. 基本段类型通常具有较小的类型值(0-7), 并在原始ELF规范中明确定义.

• 扩展段 是在ELF基本规范之外, 由特定操作系统、编译器或工具链引入的额外段类型. 这些段类型通常用于实现特定于平台的功能、安全特性或性能优化.

段地址

ELF 文件中程序段的 p_vaddr 表示该段在虚拟内存中的预期加载地址, 但这个地址通常不是最终的实际加载地址, 而是需要与基地址(Base Address)结合计算.

在讨论一个可执行程序实际的虚拟地址之前, 需要首先明确其是否使用了 PIC 位置无关代码技术:

• 对于那些使用绝对地址的代码, 程序在编译和链接时, 就假定它将在特定的虚拟地址空间中运行, 加载器也会尝试将程序段放置在它们指定的虚拟地址上.

• 但对于可能被加载到任何位置的共享库或是 PIC/PIE 程序而言, 其完全避免了绝对地址引用, 而是通过相对寻址的方式来访问自己的代码和数据, 使用全局偏移表(GOT)和过程链接表(PLT)处理动态符号, 段和段之间维持着相对位置关系即可.

因此, 程序段在内存中的实际地址计算公式为:

1实际加载地址 = 基地址 + (p_vaddr - 最小可加载段的p_vaddr)

• 基地址由动态加载器 (如 ld.so) 在加载时决定, 还会受到 ASLR、页对齐等机制的影响.

段标志位

当系统为可加载的段创建内存镜像时, 它会按照 p_flags 将段设置为对应的权限:

节区头表

节区头部表(Section Header Table)包含了描述文件节区的信息, 每个节区在表中都有一个表项, 会给出节区名称、节区大小等信息.

 1$ readelf -S a.out
 2There are 31 section headers, starting at offset 0xc558:
 3
 4Section Headers:
 5  [Nr] Name              Type             Address           Offset
 6       Size              EntSize          Flags  Link  Info  Align
 7  [ 0]                   NULL             0000000000000000  00000000
 8       0000000000000000  0000000000000000           0     0     0
 9  [ 1] .interp           PROGBITS         0000000000000318  00000318
10       000000000000001c  0000000000000000   A       0     0     1
11  [ 2] .note.gnu.pr[...] NOTE             0000000000000338  00000338
12       0000000000000040  0000000000000000   A       0     0     8
13  [ 3] .note.ABI-tag     NOTE             0000000000000378  00000378
14       0000000000000020  0000000000000000   A       0     0     4
15  [ 4] .note.gnu.bu[...] NOTE             0000000000000398  00000398
16       0000000000000024  0000000000000000   A       0     0     4
17  [ 5] .gnu.hash         GNU_HASH         00000000000003c0  000003c0
18       0000000000000024  0000000000000000   A       6     0     8
19  [ 6] .dynsym           DYNSYM           00000000000003e8  000003e8
20       0000000000000360  0000000000000018   A       7     1     8
21  [ 7] .dynstr           STRTAB           0000000000000748  00000748
22       000000000000067a  0000000000000000   A       0     0     1
23  [ 8] .gnu.version      VERSYM           0000000000000dc2  00000dc2
24       0000000000000048  0000000000000002   A       6     0     2
25  [ 9] .gnu.version_r    VERNEED          0000000000000e10  00000e10
26       00000000000000f0  0000000000000000   A       7     4     8
27  [10] .rela.dyn         RELA             0000000000000f00  00000f00
28       00000000000000d8  0000000000000018   A       6     0     8
29  [11] .rela.plt         RELA             0000000000000fd8  00000fd8
30       00000000000002a0  0000000000000018  AI       6    24     8
31  [12] .init             PROGBITS         0000000000002000  00002000
32       000000000000001b  0000000000000000  AX       0     0     4
33  [13] .plt              PROGBITS         0000000000002020  00002020
34       00000000000001d0  0000000000000010  AX       0     0     16
35  [14] .text             PROGBITS         00000000000021f0  000021f0
36       000000000000337c  0000000000000000  AX       0     0     16
37  [15] .fini             PROGBITS         000000000000556c  0000556c
38       000000000000000d  0000000000000000  AX       0     0     4
39  [16] .rodata           PROGBITS         0000000000006000  00006000
40       0000000000000067  0000000000000000   A       0     0     8
41  [17] .eh_frame_hdr     PROGBITS         0000000000006068  00006068
42       0000000000000454  0000000000000000   A       0     0     4
43  [18] .eh_frame         PROGBITS         00000000000064c0  000064c0
44       00000000000011f8  0000000000000000   A       0     0     8
45  [19] .gcc_except_table PROGBITS         00000000000076b8  000076b8
46       00000000000000c8  0000000000000000   A       0     0     1
47  [20] .init_array       INIT_ARRAY       0000000000008da0  00007da0
48       0000000000000008  0000000000000008  WA       0     0     8
49  [21] .fini_array       FINI_ARRAY       0000000000008da8  00007da8
50       0000000000000008  0000000000000008  WA       0     0     8
51  [22] .dynamic          DYNAMIC          0000000000008db0  00007db0
52       0000000000000210  0000000000000010  WA       7     0     8
53  [23] .got              PROGBITS         0000000000008fc0  00007fc0
54       0000000000000028  0000000000000008  WA       0     0     8
55  [24] .got.plt          PROGBITS         0000000000008fe8  00007fe8
56       00000000000000f8  0000000000000008  WA       0     0     8
57  [25] .data             PROGBITS         00000000000090e0  000080e0
58       0000000000000018  0000000000000000  WA       0     0     8
59  [26] .bss              NOBITS           0000000000009100  000080f8
60       00000000007a1290  0000000000000000  WA       0     0     32
61  [27] .comment          PROGBITS         0000000000000000  000080f8
62       0000000000000036  0000000000000001  MS       0     0     1
63  [28] .symtab           SYMTAB           0000000000000000  00008130
64       0000000000001578  0000000000000018          29    10     8
65  [29] .strtab           STRTAB           0000000000000000  000096a8
66       0000000000002d84  0000000000000000           0     0     1
67  [30] .shstrtab         STRTAB           0000000000000000  0000c42c
68       0000000000000128  0000000000000000           0     0     1
69Key to Flags:
70  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),
71  L (link order), O (extra OS processing required), G (group), T (TLS),
72  C (compressed), x (unknown), o (OS specific), E (exclude),
73  D (mbind), l (large), p (processor specific)

每个节区头对应的字段含义如下:

节区头部表中存在一些特殊的节区, 如:

• SHN_UNDEF(0), 表示未定义的节区

• SHN_LORESERVE(0xFF00), 表示保留区的下界, SHN_HIRESERVE(0xFFFF), 表示保留区的上界

  • 系统保留在 SHN_LORESERVE 到 SHN_HIRESERVE之间(包含边界)的索引值，这些值不在节头表中引用, 节头表不包含保留索引项

节区类型

节区标志位

节头中 sh_flags 字段的每一个比特位都可以给出其相应的标记信息, 其定义了对应的节区的内容是否可以被修改、被执行等信息.

link 与 info 字段

当节区类型的不同的时候，sh_link 和 sh_info 也会具有不同的含义:

节区

节区部分包含在链接视图中要使用的大部分信息: 指令、数据、符号表、重定位信息等等.

下表罗列了一些重要的节区:

段

段(Segments)是ELF文件在执行视图(Execution View)中的基本单位, 与链接视图中的节(Sections)不同, 段是程序加载到内存时实际使用的单位.

链接视图的节(Sections)提供了非常细粒度的程序组织方式, 这对编译器和链接器很有用. 但对操作系统加载器来说, 处理大量节会增加复杂性并降低效率. 段提供了一种更高层次的抽象, 将具有相似属性(如内存权限)的多个节组合在一起, 简化了加载过程.

一个简单的 ELF 可执行文件的内存布局如下:

 1虚拟地址空间
 2+------------------+ 高地址
 3|      栈区域      |
 4|        ↓         |
 5|                  |
 6|        ↑         |
 7|      堆区域      |
 8+------------------+
 9|    未映射区域    |
10+------------------+
11|                  |
12|    数据段(rw-)   | ← 包含.data, .bss等节
13|                  |
14+------------------+
15|                  |
16|   代码段(r-x)    | ← 包含.text, .rodata等节
17|                  |
18+------------------+ 低地址

节区类型

字符串表节区

对于字符串表类型 SHT_STRTAB 来说, 其包含了以 NULL(0) 结尾的字符串序列, 对字符串的引用通常以字符串在表中的下标来给出, 例如节区头表的 sh_name 便是使用这种方式来给出自身的名字, 节区头表关联的是 .shstrtab 节(Section Header String Table).

符号表节区

对于符号表类型 SHT_SYMTAB, 其包含了用来定位、重定位程序中符号定义和引用的信息, 表项字段含义如下:

st_value

st_value 在不同的上下文下含义不同, 在文章 ELF文件基本结构 - CTF Wiki 中其说明:

• 当符号对应为一个变量时, st_value 表明该变量在内存中的偏移.

  • 获取该符号对应的 st_shndx, 进而获取到相关的节区

  • 根据节区头元素可以获取节区的虚拟基地址和文件基地址

  • value-内存基虚拟地址=文件偏移-文件基地址

• 当符号对应为一个函数时, st_value 表明该函数在文件中的偏移.

但这其实貌似是不完全对的. ELF 中不会区别对待变量或函数, st_value 的含义由以下的因素决定:

• 文件类型（可重定位文件、可执行文件或共享对象文件）

• 符号绑定类型（局部、全局、弱符号）

更加精确的结论:

• 在可重定位文件(.o文件), 对于所有已定义的符号(无论是变量还是函数), st_value 都表示节区偏移量, 也就是相对于由 st_shndx 标识的节区起始位置的偏移量. 这一点对于变量和函数本质上是相同的.

• 在可执行文件或共享对象文件中: 对于所有已定义的符号, st_value 都表示虚拟内存地址.

为了更好地理解 st_value, 我们使用一段 C 代码来演示:

 1#include <stdio.h>
 2
 3// 全局变量
 4int global_var = 42;
 5
 6// 静态全局变量
 7static int static_global = 100;
 8
 9// 函数声明
10void another_function(void);
11
12int main(void) {
13    int local_var = 10;
14    printf("全局变量: %d\n", global_var);
15    another_function();
16    return 0;
17}
18
19void another_function(void) {
20    printf("另一个函数被调用\n");
21}

这边我们主要关注三个符号: 全局变量 global_var, 静态全局变量 static_global 以及一个函数 another_function.

首先使用-c 选项编译出来 .o 目标文件, 并查看其符号表以及节区头表:

 1$ gcc -c symbols.c -o symbols.o
 2
 3$ readelf -s symbols.o
 4
 5Symbol table '.symtab' contains 10 entries:
 6   Num:    Value          Size Type    Bind   Vis      Ndx Name
 7     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
 8     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS symbols.c
 9     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 .text
10     3: 0000000000000004     4 OBJECT  LOCAL  DEFAULT    3 static_global
11     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 .rodata
12     5: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    3 global_var
13     6: 0000000000000000    55 FUNC    GLOBAL DEFAULT    1 main
14     7: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND printf
15     8: 0000000000000037    22 FUNC    GLOBAL DEFAULT    1 another_function
16     9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND puts
17
18$ readelf -S symbols.o
19There are 14 section headers, starting at offset 0x3d8:
20
21Section Headers:
22  [Nr] Name              Type             Address           Offset
23       Size              EntSize          Flags  Link  Info  Align
24  [ 0]                   NULL             0000000000000000  00000000
25       0000000000000000  0000000000000000           0     0     0
26  [ 1] .text             PROGBITS         0000000000000000  00000040
27       000000000000004d  0000000000000000  AX       0     0     1
28  [ 2] .rela.text        RELA             0000000000000000  000002a0
29       0000000000000090  0000000000000018   I      11     1     8
30  [ 3] .data             PROGBITS         0000000000000000  00000090
31       0000000000000008  0000000000000000  WA       0     0     4
32
33       ...

通过查看节区头表, 可以看到索引 Ndx 1, 3 分别对应.text代码段以及.data数据段, 此时st_value表示该符号在对应的分区的偏移量. 使用 objdump 进行验证:

 1#################
 2## 查看数据段 ###
 3#################
 4$ objdump -s -j .data symbols.o
 5
 6symbols.o:     file format elf64-x86-64
 7
 8Contents of section .data:
 9 0000 2a000000 64000000                    *...d...
10
11
12#################
13## 查看代码段 ###
14#################
15# 直接查看 .text 不够直观
16$ objdump -s -j .text symbols.o
17
18# 反汇编查看代码段
19$ objdump -d symbols.o
20
21symbols.o:     file format elf64-x86-64
22
23
24Disassembly of section .text:
25
260000000000000000 <main>:
27   0:	55                   	push   %rbp
28   1:	48 89 e5             	mov    %rsp,%rbp
29   4:	48 83 ec 10          	sub    $0x10,%rsp
30   8:	c7 45 fc 0a 00 00 00 	movl   $0xa,-0x4(%rbp)
31   f:	8b 05 00 00 00 00    	mov    0x0(%rip),%eax        # 15 <main+0x15>
32  15:	89 c6                	mov    %eax,%esi
33  17:	48 8d 05 00 00 00 00 	lea    0x0(%rip),%rax        # 1e <main+0x1e>
34  1e:	48 89 c7             	mov    %rax,%rdi
35  21:	b8 00 00 00 00       	mov    $0x0,%eax
36  26:	e8 00 00 00 00       	call   2b <main+0x2b>
37  2b:	e8 00 00 00 00       	call   30 <main+0x30>
38  30:	b8 00 00 00 00       	mov    $0x0,%eax
39  35:	c9                   	leave
40  36:	c3                   	ret
41
420000000000000037 <another_function>:
43  37:	55                   	push   %rbp
44  38:	48 89 e5             	mov    %rsp,%rbp
45  3b:	48 8d 05 00 00 00 00 	lea    0x0(%rip),%rax        # 42 <another_function+0xb>
46  42:	48 89 c7             	mov    %rax,%rdi
47  45:	e8 00 00 00 00       	call   4a <another_function+0x13>
48  4a:	90                   	nop
49  4b:	5d                   	pop    %rbp
50  4c:	c3                   	ret

可以看到:

• 在 .data 中, 以小端序存放着 42 和 100 两个全局变量的值

• .text 为汇编后的代码, 使用 objdump -d 查看反汇编后的代码, 可以看到在对应偏移量的位置为 another_function

至此, 目标文件的分析完成, 无论是函数还是变量, st_value 都是对应节区的偏移量.

下面分析可执行文件中的情况, 我们需要验证: st_value 表示虚拟地址的位置.

 1# 省略了部分输出
 2
 3$ readelf -s symbols
 4
 5...
 6
 7Symbol table '.symtab' contains 28 entries:
 8   Num:    Value          Size Type    Bind   Vis      Ndx Name
 9     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
10     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS symbols.c
11     2: 0000000000004024     4 OBJECT  LOCAL  DEFAULT   24 static_global
12     3: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS
13    12: 0000000000001198     0 FUNC    GLOBAL HIDDEN    15 _fini
14    13: 0000000000001180    22 FUNC    GLOBAL DEFAULT   14 another_function
15    14: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND printf@GLIBC_2.2.5
16    15: 0000000000004020     4 OBJECT  GLOBAL DEFAULT   24 global_var
17    16: 0000000000004010     0 NOTYPE  GLOBAL DEFAULT   24 __data_start
18... 
19
20$ readelf -S symbols
21There are 30 section headers, starting at offset 0x3580:
22
23Section Headers:
24  [Nr] Name              Type             Address           Offset
25       Size              EntSize          Flags  Link  Info  Align
26  [14] .text             PROGBITS         0000000000001050  00001050
27       0000000000000146  0000000000000000  AX       0     0     16
28  [24] .data             PROGBITS         0000000000004010  00003010
29       0000000000000018  0000000000000000  WA       0     0     8

从 readelf 的结果可以看到, 相比于目标文件, 可执行文件的 st_value 的值已经变得大得多了, 尽管仍然通过 Ndx 指向数据段和代码段, 但此时该字段的含义已经变成了对应符号在运行时的虚拟地址的空间了. 我们使用 gdb 进行验证:

1$ gdb ./symbols
2GNU gdb (GDB) 15.2
3
4(gdb) info address another_function
5Symbol "another_function" is at 0x1180 in a file compiled without debugging.
6(gdb) info address global_var
7Symbol "global_var" is at 0x4020 in a file compiled without debugging.
8(gdb) info address static_global
9Symbol "static_global" is at 0x4024 in a file compiled without debugging.

gdb 的输出与符号表的输出是统一的, 以此验证通过!

st_info

st_info 中包含符号类型和绑定信息, 这里给出了控制它的值的方式具体信息如下:

1#define ELF32_ST_TYPE(i)    ((i)&0xf)                   # 低 4 位
2#define ELF32_ST_INFO(b, t) (((b)<<4) + ((t)&0xf))      # 高 4 位

符号类型如下:

• 共享目标文件中的函数符号有比较特殊, 当另一个目标文件从共享目标文件中引用一个函数时, 链接器自动为被引用符号创建过程链接表(PLT)项. 共享目标中除了STT_FUNC , 其它符号将不会通过过程链接表自动被引用.

符号绑定的信息确定了符号的链接可见性以及其行为, 具体的取值如下:

• 当链接器在链接多个可重定位目标文件时, 不允许定义多个相同名字的 STB_GLOBAL 符号. 但如果存在一个已定义的全局符号, 同名弱符号的存在不会引起错误. 链接器会优先选择全局定义, 忽略弱符号定义.

st_shndx

通常的 st_shndx 定义了符号所在节在节区头部表中的下标, 下面给出了一些特殊的取值:

• SHN_ABS: 符号的取值具有绝对性, 不会因为重定位而发生变化.

• SHN_COMMON: 符号标记了一个尚未分配的公共块. 符号的取值给出了对齐约束, 与节区的 sh_addralign 成员类似. 就是说, 链接编辑器将在地址位于 st_value 的倍数处为符号分配空间. 符号的大小给出了所需要的字节数.

• SHN_UNDEF: 此索引值表示符号没有定义. 当链接编辑器将此目标文件与其他定义了该符号的目标文件进行组合时, 此文件中对该符号的引用将被链接到实际定义的位置.

符号名称的定位

对于一个符号表而言, 其所有的符号名称也是通过另一张字符串表来给出的. 与节区头表中的节区名称 sh_name 类似, 符号表表项的名称 st_name 也是一个数值索引, 其使用的字符串表根据符号表头的 sh_link 字段给出.

以上述的 C 代码为例, 为了简便, 编译出目标代码, 使用 readelf 查看对应的内容:

 1# 查看所有的符号头表
 2$ readelf -S symbols.o
 3There are 14 section headers, starting at offset 0x408:
 4
 5Section Headers:
 6  [Nr] Name              Type             Address           Offset
 7       Size              EntSize          Flags  Link  Info  Align
 8
 9  ... 省略若干输出
10
11  [11] .symtab           SYMTAB           0000000000000000  00000168
12       00000000000000f0  0000000000000018          12     5     8
13  [12] .strtab           STRTAB           0000000000000000  00000258
14       0000000000000046  0000000000000000           0     0     1
15  [13] .shstrtab         STRTAB           0000000000000000  00000360
16       0000000000000074  0000000000000000           0     0     1
17
18# 查看 .symtab 关联的 12 号节区 .strtab
19$readelf -x 12 symbols.o
20
21Hex dump of section '.strtab':
22  0x00000000 0073796d 626f6c73 2e630073 74617469 .symbols.c.stati
23  0x00000010 635f676c 6f62616c 00676c6f 62616c5f c_global.global_
24  0x00000020 76617200 6d61696e 00707269 6e746600 var.main.printf.
25  0x00000030 616e6f74 6865725f 66756e63 74696f6e another_function
26  0x00000040 00707574 7300                       .puts.

通过符号表头的 Link 可以关联到 12 号节区表, 在 12 号节区内, 看到了所有符号的字符串名称.

但需要注意, 12 号节区中的内容是符号自身的字符串名字, 符号的值则由符号表内部的 Ndx 与 st_value 给出.

哈希表节区

哈希表节区是用于存储哈希值的特殊节区. 这些节区主要用于以下几个目的:

• 完整性验证：存储文件或特定节区的哈希值，用于验证文件是否被篡改

• 数字签名：支持代码签名机制，以验证软件的来源和完整性

• 安全启动：在嵌入式系统和安全启动过程中验证可执行文件

• 符号查找加速：某些哈希表用于加速符号查找过程

.hash 是传统的哈希表节区, 使用 GNU 工具链则会以 .gnu.hash 替代, 其比传统的 .hash 更加高效, 占用的内存空间更小, 哈希函数也更加现代, 相关的内容留待后续有机会再学习:

参考:

• 从实例分析ELF格式的.gnu.hash区与glibc的符号查找 - 橙子和雪 - 博客园

• GNU Hash ELF Sections

数据相关节区

• .bss; 未初始化的全局变量对应的节. 此节区不占用 ELF 文件空间, 但占用程序的内存映像中的空间. 当程序开始执行时, 系统将把这些数据初始化为 0.

  • bss 是 Block Started by Symbol 的简写, 说明该节区中单纯地说明了有哪些变量.

• .data; 这些节区包含初始化了的数据, 会在程序的内存映像中出现.

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

代码相关节区

• .init & .init_array; 此节区包含可执行指令, 是进程初始化代码的一部分. 程序开始执行时, 系统会在开始调用主程序入口(通常指 C 语言的 main 函数)前执行这些代码.

• .text ;此节区包含程序的可执行指令

• .fini & .fini_array; 此节区包含可执行的指令, 是进程终止代码的一部分. 程序正常退出时, 系统将执行这里的代码.

动态链接与重定位节区

ELF 文件中的动态链接相关节区主要包括:

1. .dynamic; 核心动态链接信息节区, 包含了所有动态链接所需的信息结构. 它存储了各种动态链接条目, 如共享库路径、符号表位置等.

2. .dynsym; 动态符号表, 包含了程序中所有需要动态链接的符号信息. 与.symtab不同, .dynsym只包含动态链接必需的符号.

3. .dynstr; 动态字符串表, 存储了.dynsym中符号的名称字符串.

4. .plt(Procedure Linkage Table)- 过程链接表, 用于支持延迟绑定(lazy binding)机制, 提高程序启动速度.

5. .got(Global Offset Table)- 全局偏移表, 存储外部符号的地址. PLT会使用GOT进行符号解析.

6. .got.plt; PLT专用的GOT表部分, 专门用于函数调用.

7. .rela.dyn/.rel.dyn; 用于变量的重定位表.

8. .rela.plt/.rel.plt; 用于函数的重定位表.

9. .interp; 存储动态链接器(如/lib64/ld-linux-x86-64.so.2)的路径.

有关动态链接、PLT、GOT 相关的内容, 由于较为复杂, 参见后续博客. TODO

后记

在写知识类博客的时候, 总是难免地变成知识摘抄(从网络博客与 LLM 的知识库中), 或是技术说明书(罗列冗余无趣的字段详解).. 尽管断断续续从在网上写下第一个字到如今已经有 6 年左右了, 但始终无法很好地产出此类的知识文章; 相比之下, 各种技术工具的折腾记录反而更加容易些. 其原因本质上还是在于对于知识的理解不够到位, 却又希望输出好的文章: 对于初学者来说, 对新知识的学习必然是零碎的、片面的, 但对于博客创作者来说, 又希望对知识的介绍是系统的、引人入胜且条理清晰的, 我是不愿将笔记、草稿作为博客上传到互联网上的, 此类的内容不宜使用博客作为载体, 使用批注或 Obisidian 等管理工具或许更好, 但我又不愿将一份知识的学习拆分为两种; 尽管有言道学习最好的方式就是将它教给别人, 但当我真的学会后, 我是没有太大的动力去做科普、系统性的知识教程的, 这就导致了一些内容产出理念上的偏差..

不过总体来说, 我的博客还是个人学习的沉淀与输出, 他人倘若能有些许的受益就是其发表于互联网上的价值所在了. 毕竟, 目前内容农场大行其道, 各种图片过期、CSS 样式丑陋的博客也不在少数, 我自认本博客的审美不至于过于丑陋, 也并无任何的广告, 不滥用 LLM 生成内容, 一些地方也是会记录下我在学习、探索过程中的独到之处, 因此应当还是有一定价值的!

参考资料

参考阅读:

• 计算机那些事(4)——ELF文件结构 | 楚权的世界

• ELF文件基本结构 - CTF Wiki

• ELF文件格式分析-北京大学操作系统实验室

• 可执行和可链接格式 - 维基百科 — Executable and Linkable Format - Wikipedia