玩Linux的人应该明白ELF文件是一种文件格式,就好比.txt,.doc等一样,只是这个文件是按照特定信息排列组成,同样在windows上也存在一种格式,它叫PE,老的叫dos。下面我就来看看ELF文件里面到底有什么, 以hello.c为例子。
点击(此处)折叠或打开
-
#include <stdio.h>
-
-
int main (int argc, char *argv[])
-
{
-
printf ("Hello World\n");
-
-
return 0;
-
}
图 1
执行:make hello 生成hello可执行文件(ELF格式).
首先,我们可以通过readelf -h hello,来获取hello这个elf文件的头部信息(该信息放置在hello文件的头部,大小为64字节):
点击(此处)折叠或打开
-
$ readelf -h hello
-
ELF Header:
-
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
-
Class: ELF64
-
Data: 2's complement, little endian
-
Version: 1 (current)
-
OS/ABI: UNIX - System V
-
ABI Version: 0
-
Type: EXEC (Executable file)
-
Machine: Advanced Micro Devices X86-64
-
Version: 0x1
-
Entry point address: 0x400430
-
Start of program headers: 64 (bytes into file)
-
Start of section headers: 6696 (bytes into file)
-
Flags: 0x0
-
Size of this header: 64 (bytes)
-
Size of program headers: 56 (bytes)
-
Number of program headers: 9
-
Size of section headers: 64 (bytes)
-
Number of section headers: 31
-
Section header string table index: 28
图 2
当我们在shell命令行敲击./hello的时候,内核是怎么识别这是一个可执行文件(
elf文件)的呢?其实,在shell进行运行的时候,busybox会将"./hello"当成execve系统函数参数进行传参即:execve("./hello", ["./hello"]) 。当Linux发生系统调用并陷入内核后,Linux内核将这个hello文件的从0开始的前面几个字节与.ELF(
7f 45 4c 46)比较,如果一样,则是elf文件,如果不一样,则与"#!"进行比较,以此来查看是否为需要第三方解释的脚本语言(#!后面跟的是解释器的路径),如#!/bin/sh或者#!/usr/bin/python。
上面提到的7f 45 4c 46就是一个elf文件的magic,一种固定elf标志即文件的识别码,其对应的ascii码是
.ELF, 可以通过readelf -h hello获取到,如图2。
由图2可知,这个ELF文件支持的平台为X86-64,版本是0x1,入口地址是0x400430,段的起始地址是文件偏移6696字节处,Program Header在文件偏移64字节处即elf头信息之后。当前elf header占大小64字节,有9个program header和31个段等等,具体elf header格式,可以参考elf.h头文件。
温馨小提示:这里我们普及一下什么是section。我们常听说的section有代码段(TEXT段),BSS段,数据段(DATA段),只读数据段(RODATA段),HEAP, STACK等。在C语言中,.TEXT段主要用于存放函数对应的机器码的(也就是可执行程序的可运行部分),BSS段主要存放全局未初始化变量的(数据部分),DATA段主要存放全局并且已经初始化过的变量的(注意:初始化成0/NULL的全局变量会被认为是未初始化而放置到BSS段,因为BSS段的数据默认就是0/NULL),RODATA段用于存放const类型的变量,HEAP主要是分配内存使用,而STACK主要是用于函数调用和函数局部变量使用。
在讲ELF各个部分内容之前,我们先看看ELF文件的整体结构:
-
+-----------------------+ hello文件偏移 0bytes
-
| |
-
| ELF Header |
-
+-----------------------+ hello文件偏移 64bytes
-
| |
-
| Program Header |
-
+-----------------------+ hello文件偏移 568bytes (64+56 * 9)
-
| interpreter | (动态解释器位置)
-
+-----------------------+
-
| ....... |
-
+-----------------------+ hello文件偏移 3600bytes
-
| text | (代码段位置)
-
+-----------------------+
-
| ro data | (只读数据段位置)
-
+-----------------------+
-
| ....... | (其它段)
-
+-----------------------+
-
| data | (数据段)
-
+-----------------------+ hello文件偏移 6696bytes
-
| Section Header | (段表位置)
-
+-----------------------+ hello文件尾部 8680 bytes
-
$ ls -l hello
-
-rwxr-xr-x 1 cliu4 users 8680 9月 30 14:31 hello
图 3
如图3,图为hello文件的整个布局图,从图中可以看出,hello可执行文件的大小为8680字节,其中0-64字节存放的是elf文件的头部信息,即elf header(这个结构体可以通过查看elf.h获取),64字节之后存放的是program header,在之后放的是动态解释器(interpreter),而section header则是放到文件末尾的即6696字节处,中间放到程序段即section。而当我们知道了elf头部信息的作用就是指明当前elf文件的版本号,运行环境和其他段的位置,个数以及大小后,那么紧接着elf header的program header到底又有什么用呢?首先我们看看program header里面到底有什么,如下图:
点击(此处)折叠或打开
-
$ readelf -l hello
-
-
Elf file type is EXEC (Executable file)
-
Entry point 0x400430
-
There are 9 program headers, starting at offset 64
-
-
Program Headers:
-
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align
-
PHDR 0x0000000000000040 0x0000000000400040 0x0000000000400040 0x00000000000001f8 0x00000000000001f8 RE 8
-
INTERP 0x0000000000000238 0x0000000000400238 0x0000000000400238 0x000000000000001c 0x000000000000001c R 1
-
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
-
LOAD 0x0000000000000000 0x0000000000400000 0x0000000000400000 0x0000000000000794 0x0000000000000794 RE 200000
-
LOAD 0x0000000000000e00 0x0000000000600e00 0x0000000000600e00 0x0000000000000238 0x0000000000000240 RW 200000
-
DYNAMIC 0x0000000000000e28 0x0000000000600e28 0x0000000000600e28 0x00000000000001d0 0x00000000000001d0 RW 8
-
NOTE 0x0000000000000254 0x0000000000400254 0x0000000000400254 0x0000000000000044 0x0000000000000044 R 4
-
GNU_EH_FRAME 0x0000000000000618 0x0000000000400618 0x0000000000400618 0x0000000000000044 0x0000000000000044 R 4
-
GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10
-
GNU_RELRO 0x0000000000000e00 0x0000000000600e00 0x0000000000600e00 0x0000000000000200 0x0000000000000200 R 1
-
-
Section to Segment mapping:
-
Segment Sections...
-
00
-
01 .interp
-
02 .interp .note.ABI-tag .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .plt.got .text .fini .rodata .eh_frame_hdr .eh_frame
-
03 .init_array .fini_array .jcr .dynamic .got .got.plt .data .bss
-
04 .dynamic
-
05 .note.ABI-tag .note.gnu.build-id
-
06 .eh_frame_hdr
-
07
-
08 .init_array .fini_array .jcr .dynamic .got
图 4
如图4,program headers包含:1、PHDR(program header起始位置0x40,大小0x1f8);2、INTERP(动态解释器,其实就是一个字符串,记录了动态解释器的位置:/lib64/ld-linux-x86-64.so.2);3、LOAD;4、LOAD;5、DYNAMIC;6、NOTE等。从第20行"Section to Segment mapping"下面可以看到编号00,01,02,03....08,这些编号对应的是program header对应的表,例如:00对应的是PHDR,01对应的是INTERP,02对应的是LOAD等。因此,可以知道01对应的program header INTERP部分记录的是.interp段信息;而其他的与运行相关的记录在02/03对应的LOAD结构当中。那么这个program header到底有什么用呢?其实,这个program header仔细的朋友应该能够发现每个program header都记录了对应所在的文件偏移和内存的虚拟地址和物理地址,当系统调用execve陷入到内核,并且发现这个hello文件为elf文件的时候,Linux内核就会根据program header当中的提示信息来对hello进行内存映射,给hello开辟自己的虚拟地址空间(如LOAD部分虚拟地址是0x400000即图4标红部分),并且通过INTERP获取到当前elf文件的动态解释器路径
:/lib64/ld-linux-x86-64.so.2,还可以通过DYNAMIC部分获取到当前hello文件依赖的动态库信息,知道哪些动态库需要引用(readelf -d hello)。因此,我可以简单的理解为:program header信息 就是为Linux内核提供应用程序加载相关的信息,方便内核加载可执行程序。
如图3,经过了program header,挨着它的便是动态解释器(.interpreter)的位置了,这个地方比较简单,就是一个字符串,指明了动态解释器的路径。这个动态解释器
/lib64/ld-linux-x86-64.so.2看起来是一个动态库,其实不是,它是一个可用自我重定位的可执行程序,其主要作用就是帮助hello进行代码重定位。
如图3,在动态解释器后的具体段,将在section headers之后描述。
如图3,在文件的末尾,即6696偏移到8680偏移的位置处,存放的是section header。可用通过readelf -S hello获取到。下图是section headers结构的信息:
点击(此处)折叠或打开
-
There are 31 section headers, starting at offset 0x1a28:
-
-
Section Headers:
-
[Nr] Name Type Address Offset Size EntSize Flags Link Info Align
-
[ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0
-
[ 1] .interp PROGBITS 0000000000400238 00000238 000000000000001c 0000000000000000 A 0 0 1
-
[ 2] .note.ABI-tag NOTE 0000000000400254 00000254 0000000000000020 0000000000000000 A 0 0 4
-
[ 3] .note.gnu.build-i NOTE 0000000000400274 00000274 0000000000000024 0000000000000000 A 0 0 4
-
[ 4] .gnu.hash GNU_HASH 0000000000400298 00000298 000000000000001c 0000000000000000 A 5 0 8
-
[ 5] .dynsym DYNSYM 00000000004002b8 000002b8 0000000000000060 0000000000000018 A 6 1 8
-
[ 6] .dynstr STRTAB 0000000000400318 00000318 000000000000003d 0000000000000000 A 0 0 1
-
[ 7] .gnu.version VERSYM 0000000000400356 00000356 0000000000000008 0000000000000002 A 5 0 2
-
[ 8] .gnu.version_r VERNEED 0000000000400360 00000360 0000000000000020 0000000000000000 A 6 1 8
-
[ 9] .rela.dyn RELA 0000000000400380 00000380 0000000000000018 0000000000000018 A 5 0 8
-
[10] .rela.plt RELA 0000000000400398 00000398 0000000000000030 0000000000000018 AI 5 24 8
-
[11] .init PROGBITS 00000000004003c8 000003c8 000000000000001a 0000000000000000 AX 0 0 4
-
[12] .plt PROGBITS 00000000004003f0 000003f0 0000000000000030 0000000000000010 AX 0 0 16
-
[13] .plt.got PROGBITS 0000000000400420 00000420 0000000000000008 0000000000000000 AX 0 0 8
-
[14] .text PROGBITS 0000000000400430 00000430 00000000000001b2 0000000000000000 AX 0 0 16
-
[15] .fini PROGBITS 00000000004005e4 000005e4 0000000000000009 0000000000000000 AX 0 0 4
-
[16] .rodata PROGBITS 00000000004005f0 000005f0 0000000000000027 0000000000000000 A 0 0 4
-
[17] .eh_frame_hdr PROGBITS 0000000000400618 00000618 0000000000000044 0000000000000000 A 0 0 4
-
[18] .eh_frame PROGBITS 0000000000400660 00000660 0000000000000134 0000000000000000 A 0 0 8
-
[19] .init_array INIT_ARRAY 0000000000600e00 00000e00 0000000000000010 0000000000000000 WA 0 0 8
-
[20] .fini_array FINI_ARRAY 0000000000600e10 00000e10 0000000000000010 0000000000000000 WA 0 0 8
-
[21] .jcr PROGBITS 0000000000600e20 00000e20 0000000000000008 0000000000000000 WA 0 0 8
-
[22] .dynamic DYNAMIC 0000000000600e28 00000e28 00000000000001d0 0000000000000010 WA 6 0 8
-
[23] .got PROGBITS 0000000000600ff8 00000ff8 0000000000000008 0000000000000008 WA 0 0 8
-
[24] .got.plt PROGBITS 0000000000601000 00001000 0000000000000028 0000000000000008 WA 0 0 8
-
[25] .data PROGBITS 0000000000601028 00001028 0000000000000010 0000000000000000 WA 0 0 8
-
[26] .bss NOBITS 0000000000601038 00001038 0000000000000008 0000000000000000 WA 0 0 1
-
[27] .comment PROGBITS 0000000000000000 00001038 0000000000000035 0000000000000001 MS 0 0 1
-
[28] .shstrtab STRTAB 0000000000000000 00001915 000000000000010c 0000000000000000 0 0 1
-
[29] .symtab SYMTAB 0000000000000000 00001070 0000000000000678 0000000000000018 30 49 8
-
[30] .strtab STRTAB 0000000000000000 000016e8 000000000000022d 0000000000000000 0 0 1
图 5
图5是hello文件的section header, 这个信息描述了这个hello文件中到底存在有多少section,这里我将比较重要的section用紫色表示。其中,.interp, .text, .rodata, .data, .bss等几个常用段,这里就不在进行介绍(通常.rodata,.data,和.text是挨着的,是为了节约存储空间,因为.bss不会占用存储空间)。.interp的具体实现将在以后的文章中加以描述。.note开头和.gnu开头的段基本上都是存放与调试相关的信息。
.dynsym和.dynstr: 这两个段为动态符号段和动态字符串符号段,里面存放的是hello程序需要的外部符号信息,用于动态链接。
-
$readelf --dyn-syms hello
-
-
Symbol table '.dynsym' contains 4 entries:
-
Num: Value Size Type Bind Vis Ndx Name
-
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
-
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND puts@GLIBC_2.2.5 (2)
-
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
-
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
.rela.dyn和.rela.plt:这两个段是重定位符号表,主要用于指明需要动态解释器(interpreter)帮忙重定位的符号。
-
$readelf -r hello
-
-
Relocation section '.rela.dyn' at offset 0x380 contains 1 entries:
-
Offset Info Type Sym. Value Sym. Name + Addend
-
000000600ff8 000300000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
-
-
Relocation section '.rela.plt' at offset 0x398 contains 2 entries:
-
Offset Info Type Sym. Value Sym. Name + Addend
-
000000601018 000100000007 R_X86_64_JUMP_SLO 0000000000000000 puts@GLIBC_2.2.5 + 0
-
000000601020 000200000007 R_X86_64_JUMP_SLO 0000000000000000 __libc_start_main@GLIBC_2.2.5 + 0
注:在Linux当中,并不是所有符号需要在启动的时候,由动态解释器(interpreter)重定位。事实上,为了加快应用程序的启动速度,Linux引入了延迟加载功能,即PLT。所谓的延迟加载是指在启动的过程中,不需要对所有符号进行重定位,只有在需要该符号的时候,才对其进行重定位,通常Linux将函数作为PLT部分。
注:其中R_X86_64_GLOB_DAT 和R_X86_64_JUMP_SLO 为重定向类型,具体参考重定向。
.init: 与应用初始化相关,在进入main函数之前会涉及到,通常位于PLT代码的前面。
-
Disassembly of section .init: 只是一个过渡函数,由__libc_csu_init调用
-
-
00000000004003c8 <_init>:
-
4003c8: 48 83 ec 08 sub $0x8,%rsp
-
4003cc: 48 8b 05 25 0c 20 00 mov 0x200c25(%rip),%rax # 600ff8 <_DYNAMIC+0x1d0>
-
4003d3: 48 85 c0 test %rax,%rax
-
4003d6: 74 05 je 4003dd <_init+0x15>
-
4003d8: e8 43 00 00 00 callq 400420 <__libc_start_main@plt+0x10>
-
4003dd: 48 83 c4 08 add $0x8,%rsp
-
4003e1: c3 retq
.plt和.plt.got: .plt用于存放PLT跳板,如puts@GLIBC_2.2.5的实现(以后讲解具体怎么跳);下图为.plt段和.got.plt段的具体内容,其中.plt段内部是跳板函数的实现(汇编语句),.got.plt则只是数据的实现:
-
Contents of section .got.plt: .got.plt的内容,601020->0x400416, 601018->0x400406(标红部分,为数据,PLT第一次会访问这里,之后这里会被覆盖成真正的函数地址)
601000 280e6000 00000000 00000000 00000000 (.`.............
601010 00000000 00000000 06044000 00000000 ..........@.....
601020 16044000 00000000
-
Disassembly of section .plt:
-
-
00000000004003f0 <puts@plt-0x10>:
-
4003f0: ff 35 12 0c 20 00 pushq 0x200c12(%rip) # 601008 <_GLOBAL_OFFSET_TABLE_+0x8>
-
4003f6: ff 25 14 0c 20 00 jmpq *0x200c14(%rip) # 601010 <_GLOBAL_OFFSET_TABLE_+0x10>
-
4003fc: 0f 1f 40 00 nopl 0x0(%rax)
-
-
0000000000400400 <puts@plt>: 这是一个跳板函数,当第一次调用的时候,GOT+0x8指向400406,然后进行函数重定位 ,第二次调用的时候,指向重定位后的地址
-
400400: ff 25 12 0c 20 00 jmpq *0x200c12(%rip) # 601018 <_GLOBAL_OFFSET_TABLE_+0x18>
-
400406: 68 00 00 00 00 pushq $0x0
-
40040b: e9 e0 ff ff ff jmpq 4003f0 <_init+0x28>
-
-
0000000000400410 <__libc_start_main@plt>:跳板函数:当第一次调用的时候,GOT+0x8指向400416,然后进行函数重定位 ,第二次调用的时候,指向重定位后的地址
-
400410: ff 25 0a 0c 20 00 jmpq *0x200c0a(%rip) # 601020 <_GLOBAL_OFFSET_TABLE_+0x20>
-
400416: 68 01 00 00 00 pushq $0x1
-
40041b: e9 d0 ff ff ff jmpq 4003f0 <_init+0x28>
-
-
Disassembly of section .plt.got:
-
-
0000000000400420 <.plt.got>:
-
400420: ff 25 d2 0b 20 00 jmpq *0x200bd2(%rip) # 600ff8 <_DYNAMIC+0x1d0>
-
400426: 66 90 xchg %ax,%ax
如上图,如果我调用puts函数,则是通过callq 400400 来调用的,即首先调用的是puts@plt函数,而这个函数就是在.plt段中实现的跳板函数,由它来完成最后的延迟重定向。
.fini: 与应用退出有关,在main函数退出可能会涉及到,通常为空。
.init_array和.fini_array: 类似于构造函数和析构函数,挂在.init_array段里面的函数,在main函数运行前运行;挂在.fini_array段里面的函数在main函数退出后运行。
.got和.got.plt: 又名全局偏移表,用于存放全局符号地址,其中plt属于一种特殊的GOT表。.got.plt主要用于存放动态函数地址,此表和PLT搭配使用(以后会讲解)。
.symtab和.strtab: hello程序内部能提供的符号表和一些符号信息,这个段通常用于动态库需要,应用程序对此无用。
-
$readelf -s hello
-
-
Symbol table '.dynsym' contains 4 entries:
-
Num: Value Size Type Bind Vis Ndx Name
-
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
-
1: 0000000000000000 0 FUNC GLOBAL DEFAULT UND puts@GLIBC_2.2.5 (2)
-
2: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@GLIBC_2.2.5 (2)
-
3: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
-
-
Symbol table '.symtab' contains 69 entries:
-
Num: Value Size Type Bind Vis Ndx Name
-
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
-
1: 0000000000400238 0 SECTION LOCAL DEFAULT 1
-
2: 0000000000400254 0 SECTION LOCAL DEFAULT 2
-
3: 0000000000400274 0 SECTION LOCAL DEFAULT 3
-
4: 0000000000400298 0 SECTION LOCAL DEFAULT 4
-
5: 00000000004002b8 0 SECTION LOCAL DEFAULT 5
-
限于篇幅,此处省略部分符号
-
55: 0000000000000000 0 FUNC GLOBAL DEFAULT UND __libc_start_main@@GLIBC
-
56: 0000000000601028 0 NOTYPE GLOBAL DEFAULT 25 __data_start
-
57: 0000000000000000 0 NOTYPE WEAK DEFAULT UND __gmon_start__
-
58: 0000000000601030 0 OBJECT GLOBAL HIDDEN 25 __dso_handle
-
59: 00000000004005f0 4 OBJECT GLOBAL DEFAULT 16 _IO_stdin_used
-
60: 0000000000400570 101 FUNC GLOBAL DEFAULT 14 __libc_csu_init
-
61: 0000000000601040 0 NOTYPE GLOBAL DEFAULT 26 _end
-
62: 0000000000400430 42 FUNC GLOBAL DEFAULT 14 _start
-
63: 0000000000601038 0 NOTYPE GLOBAL DEFAULT 26 __bss_start
-
64: 0000000000400548 32 FUNC GLOBAL DEFAULT 14 main
-
65: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
-
66: 0000000000601038 0 OBJECT GLOBAL HIDDEN 25 __TMC_END__
-
67: 0000000000000000 0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable
-
68: 00000000004003c8 0 FUNC GLOBAL DEFAULT 11 _init
-
如上图,符号表可以看出一个符号是否为全局符号,是否为弱符号,是否为局部符号,符号是函数还是变量等等。其中UND表示未定义,需要外部重定位的,GLOBAL为全局,LOCAL为局部,WEAK为弱符号,FUNC为函数,OBJECT为变量,NOTYPE为需要外部重定位的。例如:
64行:
64: 0000000000400548 32 FUNC GLOBAL DEFAULT 14 main
函数名字main函数,全局符号,函数,地址0x400548等。
另外,我们可以通过objdump -s hello获取整个hello文件各个section对应的内容,如下:
通过上图,再结合各个段的具体信息,可以做进一步分析。上图的具体格式为:
Contents of section 段名:
地址 内容1 内容2 内容3 内容4 ASCII字符
地址 内容1 内容2 内容3 内容4 ASCII字符
地址 内容1 内容2 内容3 内容4 ASCII字符
...........................
elf文件的大致粗略信息就是如此,如果有需要可以进行更详细的分析,这篇到这里为止,下一篇,主要分析execve系统调用里面到底完成了什么。
阅读(3775) | 评论(6) | 转发(4) |