ELF format -- How programs look from the inside

ELF format -- How programs look from the inside

ELF 是用于Linux系统下一种文件格式,包括目标文件,二进制文件,共享库和core dump。

它非常简单,而且具有好的输出格式。

ELF针对不同的架构具有相同的布局,但是排列次序(endianness)和字长可能不同；重定位类型,符号类型和可能具有平台相关的值,当然也包括平台相关的代码。

一个ELF文件对它包含的数据提供两种视图,链接视图和执行视图。这两个视图能够被两个头访问：Section Header Table(SHT)和Program Header Table(PHT).

Linking View： Section Header Table(SHT)

SHT提供对ELF文件所有section的概述。特别令人关注的是REL section(relocations),SYMTAB/DYNSYM(symbol tables),VERSYM/VERDEF/VERNEED sections(symbol versioning information)。

[john@localhost objmodel]$ readelf -S /bin/bash

There are 32 section headers, starting at offset 0xd5ea8:

Section Headers:

[Nr] Name Type Addr Off Size ES Flg Lk Inf Al

[ 0] NULL 00000000 000000 000000 00 0 0 0

[ 1] .interp PROGBITS 08047134 000134 000013 00 A 0 0 1

[ 2] .note.ABI-tag NOTE 08047148 000148 000020 00 A 0 0 4

[ 3] .note.gnu.build-i NOTE 08047168 000168 000024 00 A 0 0 4

[ 4] .gnu.hash GNU_HASH 0804718c 00018c 003600 04 A 5 0 4

[ 5] .dynsym DYNSYM 0804a78c 00378c 0083c0 10 A 8 1 4

[ 6] .gnu.liblist GNU_LIBLIST 08052b4c 00bb4c 000050 14 A 8 0 4

[ 7] .gnu.conflict RELA 08052b9c 00bb9c 000240 0c A 5 0 4

[ 8] .dynstr STRTAB 08053b3a 00cb3a 008076 00 A 0 0 1

[ 9] .gnu.version VERSYM 0805bbb0 014bb0 001078 02 A 5 0 2

[10] .gnu.version_r VERNEED 0805cc28 015c28 0000b0 00 A 8 2 4

[11] .rel.dyn REL 0805ccd8 015cd8 000040 08 A 5 0 4

[12] .rel.plt REL 0805cd18 015d18 000638 08 A 5 14 4

[13] .init PROGBITS 0805d350 016350 000030 00 AX 0 0 4

[14] .plt PROGBITS 0805d380 016380 000c80 04 AX 0 0 4

[15] .text PROGBITS 0805e000 017000 0886ac 00 AX 0 0 16

[16] .fini PROGBITS 080e66ac 09f6ac 00001c 00 AX 0 0 4

[17] .rodata PROGBITS 080e66e0 09f6e0 01905e 00 A 0 0 32

[18] .eh_frame_hdr PROGBITS 080ff740 0b8740 003aa4 00 A 0 0 4

[19] .eh_frame PROGBITS 081031e4 0bc1e4 014b84 00 A 0 0 4

[20] .ctors PROGBITS 08118000 0d1000 000008 00 WA 0 0 4

[21] .dtors PROGBITS 08118008 0d1008 000008 00 WA 0 0 4

[22] .jcr PROGBITS 08118010 0d1010 000004 00 WA 0 0 4

[23] .dynamic DYNAMIC 08118014 0d1014 0000d8 08 WA 8 0 4

[24] .got PROGBITS 081180ec 0d10ec 000004 04 WA 0 0 4

[25] .got.plt PROGBITS 081180f0 0d10f0 000328 04 WA 0 0 4

[26] .data PROGBITS 08118420 0d1420 004390 00 WA 0 0 32

[27] .dynbss PROGBITS 0811c7c0 0d57c0 000044 00 WA 0 0 32

[28] .bss NOBITS 0811c804 0d5804 004e08 00 WA 0 0 32

[29] .gnu_debuglink PROGBITS 00000000 0d5804 000010 00 0 0 4

[30] .gnu.prelink_undo PROGBITS 00000000 0d5814 00056c 01 0 0 4

[31] .shstrtab STRTAB 00000000 0d5d80 000127 00 0 0 1

Key to Flags:

W (write), A (alloc), X (execute), M (merge), S (strings)

I (info), L (link order), G (group), x (unknown)

O (extra OS processing required) o (OS specific), p (processor specific)

Execution view: Program Header Table (PHT)

PHT包含一些信息,让内核知道怎么启动程序。LOAD指令决定ELF文件的那部分需要映射到内存。INTERP指令指定一个ELF解释器, 在Linux系统下一般是/lib/ld-linux.so.2。

DYNAMIC 入口点指向.dynamic段，包含用于ELF解释器设置二进制的信息。

[john@localhost objmodel]$ readelf -l /bin/bash

Elf file type is EXEC (Executable file)

Entry point 0x805e000

There are 8 program headers, starting at offset 52

Program Headers:

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align

PHDR 0x000034 0x08047034 0x08047034 0x00100 0x00100 R E 0x4

INTERP 0x000134 0x08047134 0x08047134 0x00013 0x00013 R 0x1

[Requesting program interpreter: /lib/ld-linux.so.2]

LOAD 0x000000 0x08047000 0x08047000 0xd0d68 0xd0d68 R E 0x1000

LOAD 0x0d1000 0x08118000 0x08118000 0x04804 0x0960c RW 0x1000

DYNAMIC 0x0d1014 0x08118014 0x08118014 0x000d8 0x000d8 RW 0x4

NOTE 0x000148 0x08047148 0x08047148 0x00044 0x00044 R 0x4

GNU_EH_FRAME 0x0b8740 0x080ff740 0x080ff740 0x03aa4 0x03aa4 R 0x4

GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

Section to Segment mapping:

Segment Sections...

00

01 .interp

02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .gnu.liblist .gnu.conflict .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame

03 .ctors .dtors .jcr .dynamic .got .got.plt .data .dynbss .bss

04 .dynamic

05 .note.ABI-tag .note.gnu.build-id

06 .eh_frame_hdr

07

把它们放在一起：ELF头

STH和PTH都没有固定的位置，他们可以放在ELF文件的任何地方。 使用ELF头来找到它们，ELF头定位在文件的开始处。

第一个字节包含ELF magic(？)"/x7fELF",接着是ClassID(32/64bit ELF文件)，数据格式ID(小端/大端)，机器类型，等等。

在ELF头的结尾处有指向SHT和PHT的指针。

[john@localhost objmodel]$ readelf -h /bin/bash

ELF Header:

Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00

Class: ELF32

Data: 2's complement, little endian

Version: 1 (current)

OS/ABI: UNIX - System V

ABI Version: 0

Type: EXEC (Executable file)

Machine: Intel 80386

Version: 0x1

Entry point address: 0x805e000

Start of program headers: 52 (bytes into file)

Start of section headers: 876200 (bytes into file)

Flags: 0x0

Size of this header: 52 (bytes)

Size of program headers: 32 (bytes)

Number of program headers: 8

Size of section headers: 40 (bytes)

Number of section headers: 32

Section header string table index: 31

Relocation Table

重定位表指定哪里需要重定位，使程序能够运行起来。在程序中正常都是符号重定位，例如动态链接器需要用符号名来决议，然后把符号地址写到指定的重定位入口点。

重定位类型是架构相关的，这儿通常有很多相关的。在i386上最重要的是R_386_COPY 类型，意思是"只是拷贝符号地址到另一个地址", R_386_JUMP_SLOT,用于一般的PLT/GOT函数调用重定位机制。

符号值自身的决议是通过动态链接库(包含在/lib/ld-linux.so.2,通常用到ELF解释器)，这是个很复杂的过程。基本上链接器搜索所有加载的ELF对象(二进制文件本身和加载的动态库)，当搜索到第一个符号定义时就使用它。

[john@localhost objmodel]$ readelf -r /bin/bash | more

Relocation section '.gnu.conflict' at offset 0xbb9c contains 48 entries:

Offset Info Type Sym.Value Sym. Name + Addend

081181a8 0000002a R_386_IRELATIVE 006c00f0

081181b8 0000002a R_386_IRELATIVE 007386b0

08118278 0000002a R_386_IRELATIVE 006c0700

08118280 0000002a R_386_IRELATIVE 006bee80

081182f8 0000002a R_386_IRELATIVE 006c6bc0

08118338 0000002a R_386_IRELATIVE 006c81f0

08118358 0000002a R_386_IRELATIVE 006c0030

081183a4 0000002a R_386_IRELATIVE 006bf100

081183b0 0000002a R_386_IRELATIVE 006bf460

081183d0 0000002a R_386_IRELATIVE 00738700

081183ec 0000002a R_386_IRELATIVE 006be880

00448a88 00000001 R_386_32 0811c7c0

...

输出的符号(exported symbols)

当动态链接器通过浏览动态符号表.dynsym来搜索符号时，所有的能被其他程序使用的符号都会出现(换句话说：exported and in case of a library, part of the ABI),Application Binary Interface.

实际上处理过程是很复杂的(在.hash段中调用hashes),但是最后的结果和描述的是一样的。

[john@localhost objmodel]$ readelf -D -s /bin/bash | more

Symbol table of `.gnu.hash' for image:

Num Buc: Value Size Type Bind Vis Ndx Name

199 1: 0811f46c 4 OBJECT GLOBAL DEFAULT 28 prog_completes

200 1: 080c4780 406 FUNC GLOBAL DEFAULT 15 sh_regmatch

201 1: 0807d590 90 FUNC GLOBAL DEFAULT 15 fatal_error

202 1: 080965b0 34 FUNC GLOBAL DEFAULT 15 set_sigwinch_handler

203 2: 080b6f50 465 FUNC GLOBAL DEFAULT 15 set_shellopts

204 2: 08074730 194 FUNC GLOBAL DEFAULT 15 execute_command

205 2: 08060c30 354 FUNC GLOBAL DEFAULT 15 history_delimiting_chars

206 2: 08118ae8 20 OBJECT GLOBAL DEFAULT 26 it_builtins

...

A more detailed look at versionsort64

机警的读者也许已经注意到versionsort64已经在上文动态符号表中提到过两次，这两个符号具有不同的值。

原因很简单，libc.so.6使用符号版本，这里有两个versionsort64版本是有效的。很不幸，binutils(二进制工具集)readelf 不能显示符号版本，eu-readelf 来至于elfutils包

[john@localhost objmodel]$ readelf -D -s /lib/libc.so.6 | grep versionsort64

1127 9: 006e19a0 31 FUNC GLOBAL DEFAULT 12 versionsort64

1126 9: 00766a40 31 FUNC GLOBAL DEFAULT 12 versionsort64

1126 498: 00766a40 31 FUNC GLOBAL DEFAULT 12 versionsort64

1127 498: 006e19a0 31 FUNC GLOBAL DEFAULT 12 versionsort64

内核载入程序

ELF文件本身不是特别有趣。ELF文件是怎样被载入内存的，在程序能够执行自己核心之前会发生什么。

一个程序的执行开始与内核的内部，也就是在系统调用中开始。查找文件类型，调用合适的处理程序。binfmt-elf处理程序加载ELF头和PHT， 紧接着是大量完整性检查。

然后内核在PHT的LOAD指令下部分的载入到内存。假如INTERP进入点已经存在，解释器也会被加载。静态链接的二进制可以不需要解释器，动态链接的程序总是需要/lib/ld-linux.so来解释，因为它包含许多启动代码，loads shared libraries needed by the binary, and performs relocation？

最后控制权会转移到程序中，(到解释器中，如果存在，否则就在二进制本身)to the interpreter, if present, otherwise to the binary itself。

[john@localhost objmodel]$ readelf -l /bin/bash

Elf file type is EXEC (Executable file)

Entry point 0x805e000

There are 8 program headers, starting at offset 52

Program Headers:

Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align

PHDR 0x000034 0x08047034 0x08047034 0x00100 0x00100 R E 0x4

INTERP 0x000134 0x08047134 0x08047134 0x00013 0x00013 R 0x1

[Requesting program interpreter: /lib/ld-linux.so.2]

LOAD 0x000000 0x08047000 0x08047000 0xd0d68 0xd0d68 R E 0x1000

LOAD 0x0d1000 0x08118000 0x08118000 0x04804 0x0960c RW 0x1000

DYNAMIC 0x0d1014 0x08118014 0x08118014 0x000d8 0x000d8 RW 0x4

NOTE 0x000148 0x08047148 0x08047148 0x00044 0x00044 R 0x4

GNU_EH_FRAME 0x0b8740 0x080ff740 0x080ff740 0x03aa4 0x03aa4 R 0x4

GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RW 0x4

Section to Segment mapping:

Segment Sections...

00

01 .interp

02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .gnu.liblist .gnu.conflict .dynstr .gnu.version .gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_frame

03 .ctors .dtors .jcr .dynamic .got .got.plt .data .dynbss .bss

04 .dynamic

05 .note.ABI-tag .note.gnu.build-id

06 .eh_frame_hdr

动态链接和ELF解释器

In case of a statically linked binary that's pretty much it, however with dynamically linked binaries a lot more magic has to go on

首先动态链接器(包含在解释器中)查看.dynamic段，它的地址存储在PHT中。

当发现NEEDED进入点是，在程序运行之前决定哪个库要不加载，×REL× 进入点包含重定位表的地址，×VER*进入点包含符号版本信息，等等。

所以动态链接器加载必要的库，执行重定位(无论是直接在程序启动时或之后，尽快重定位符号是必要的，根据不同的重定位类型。

最后控制权转交给二进制中符号_start的地址。通常许多gcc/glibc启动代码就在这里，最后调用main()。

[john@localhost objmodel]$ readelf -d /bin/bash

Dynamic section at offset 0xd1014 contains 26 entries:

Tag Type Name/Value

0x00000001 (NEEDED) Shared library: [libtinfo.so.5]

0x00000001 (NEEDED) Shared library: [libdl.so.2]

0x00000001 (NEEDED) Shared library: [libc.so.6]

0x0000000c (INIT) 0x805d350

0x0000000d (FINI) 0x80e66ac

0x6ffffef5 (GNU_HASH) 0x804718c

0x00000005 (STRTAB) 0x8053b3a

0x00000006 (SYMTAB) 0x804a78c

0x0000000a (STRSZ) 32867 (bytes)

0x0000000b (SYMENT) 16 (bytes)

0x00000015 (DEBUG) 0x0

0x00000003 (PLTGOT) 0x81180f0

0x00000002 (PLTRELSZ) 1592 (bytes)

0x00000014 (PLTREL) REL

0x00000017 (JMPREL) 0x805cd18

0x00000011 (REL) 0x805ccd8

0x00000012 (RELSZ) 64 (bytes)

0x00000013 (RELENT) 8 (bytes)

0x6ffffffe (VERNEED) 0x805cc28

0x6fffffff (VERNEEDNUM) 2

0x6ffffff0 (VERSYM) 0x805bbb0

0x6ffffef9 (GNU_LIBLIST) 0x8052b4c

0x6ffffdf7 (GNU_LIBLISTSZ) 80 (bytes)

0x6ffffef8 (GNU_CONFLICT) 0x8052b9c

0x6ffffdf6 (GNU_CONFLICTSZ) 576 (bytes)

0x00000000 (NULL) 0x0

动态链接器的符号查找(symbol lookup by the dynamic linker)

在上面提到，符号查找是一个复杂的过程，我将会给一个简单的描述。

对于每个加载的对象，RTLD(Runtime dynamic linker)保持一个加载对象的列表，叫做“查找范围(lookup scope)”，每个范围包含指向所有加载对象的指针(二进制和所有加载的库)，但是不同的范围对象的顺序是不同的。可是在每个scope中binary总是第一个对象。

当RTLD决议一个符号时，它第一步检查那个对象需要执行重定位。是查找的二进制文件本身或者一个加载的库。然后它给出那个对象的查找范围，迭代之中的每一个对象。

对于每一个对象，它在动态符号表中查找需要的符号。当匹配上后，它用符号值来做重定位，否则继续查找这个scope中的下一个对象。

符号查找规则的重要性(consequences of the symbol lookup rules)

Libs不能够直接跳转到它输出的函数上(它们当然知道它们自己的函数在哪里)，但是也必须通过描述的符号查找机制。

总有这样一个事实，二进制总是第一个在每个查找范围中查找，意味着符号定义在二进制中总是覆盖符号定义在库中。

特意采用这样的方式，是允许二进制覆盖它不喜欢的库中的函数。如果没有发生，就将采用库中的函数，也不是由库本身来调用。

通常这是很好的，但是这可能带来一个问题，假如二进制不留意定义了一个符号，这个符号也在许多加载的库使用(think program uses GTK, which pulls in different theme and input plugins depending on the user's system config)。

假如程序定义一个函数void print_error(int error_code, char* str);同时许多插件也定义了同样名字的函数，但是另一个署名，例如int print_error(char* str), 这也许是有问题的。假如插件没有输出print_error符号，这里就没有问题，因为在插件中的代码只是直接调用合适的函数，并不需要查找符号表。

然而假如插件输出符号了，它就要自己查找符号表(因为那是由SystemV ABI规范所要求的，同时也有LSB).那么print_error将会被二进制中的符号干预，那是个不兼容的签名，将会引发一个崩溃。

解决方案(solutions for this)

正确的解决方案是不要输出那些你不期望其它地方用到的符号。这是TheRightWay的，因为1，加速库/插件(没有符号查找，只是在函数内部使用)，你不必污染名称空间，你避免了上面所提到的可能出现的问题，最后，符号不是你ABI的一部分，那意味这你可以任意的修改，也不会弄坏任何依赖的程序。

这里有一个快速的方法来避免上述的问题。当在连接的的命令行中加入-Bsymbolic来连接一个库时，库的查找范围改变了，库本身就在第一现场，然后才是二进制。

这不能带给你任何优势，程序也不能干预你的符号，即使它想那么做。因此，-Bsymbolic应当避免，除非你真的很懒很懒！;-)