linux逆向分析之ELF文件详解

首先如果大家遇到ELF二进制文件的逆向首先考虑的可能就是通过IDA进行静态逆向分析算法，那么我们首先就要了解ELF(Executable
and Linking Format)的文件格式。

ELF文件格式主要分为以下几类：

1． 可重定位文件（Relocatable File），这类文件包含了代码和数据，可以被用来链接成可执行文件或共享目标文件，静态链接库也可以归为这一类，如.o文件。
2． 可执行文件（Executable File），这类文件包含了直接执行的程序，如/bin/bash等。
3． 共享目标文件（Shared Object File），链接器可以使用这种文件跟其他的可重定位文件和共享目标文件链接，产生新的目标文件；动态链接器可以将几个共享目标文件与可执行文件结合，作为进程映像的一部分来运行，如glibc***.so。
4． 核心转储文件（Core Dump File），当进程意外终止时，系统可以将该进程的地址空间内容及终止时的一些其他信息转储到核心转储文件。

一.elf文件格式详解

以上是elf文件格式结构示意图

文件头
文件头的结构定义如下所示：
typedef struct {
unsigned char e_ident[16]; /* ELF魔数，ELF字长，字节序，ELF文件版本等 */
Elf32_Half e_type; /*ELF文件类型，REL, 可执行文件，共享目标文件等 */
Elf32_Half e_machine; /* ELF的CPU平台属性 */
Elf32_Word e_version; /* ELF版本号 */
Elf32_Addr e_entry; /* ELF程序的入口虚拟地址，REL一般没有入口地址为0 */
Elf32_Off e_phoff;
Elf32_Off e_shoff; /* 段表在文件中的偏移 */
Elf32_Word e_flags; /* 用于标识ELF文件平台相关的属性 */
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;

利用readelf命令可以查看elf文件的头部信息，大家可以对照着看

结构的各个成员的含义如注释中所解释的。对ELF文件，有两个视图，一个是从装载运行角度的，另一个是从连接角度的。从装载运行角度，我们关注的是程序头表，由程序头表的指引把ELF文件加载进内存运行它。从连接的角度，我们关注节头表，由节头表的指引把各个节连接组装起来。e_type的值与这两个视图相联系，由它我们可以知道能够从哪个视图去解读。

如果e_type=1，表明它是重定位文件，可以从连接视图去解读它；

如果e_type=2，表明它是可执行文件，至少可以从装载运行视图去解读它；

如果e_type=3，表明它是共享动态库文件，同样可以至少从装载运行视图去解读它；

如果e_type=4，表明它是Coredump文件，可以从哪个视图去解读依赖于具体的实现。
如上图显示的是可执行文件那么我就要从装在运行视图去解读它

按照这两个视图，整个ELF文件的内容这样来组织：

首先是ELF文件头，也就是上面的Elf32_Ehdr结构。或者对64位的ELF文件，是Elf64_Ehdr结构。ELF文件头位于文件开始处，无论e_type的值是什么，它是必须有的。

其次是程序头表，对可执行文件(e_type=2)和动态库文件(e_type=3)，它是必须有的。对重定位文件(e_type=1)，程序头表的有无是可选的。例如用gcc的-c选项生成的.o文件，就没有程序头表。但无论如何，e_phoff和e_phnum、e_phentsize给出了ELF文件的程序头表信息。没有程序头表时它们的值为零。

然后就是就是节头表，对可执行文件和动态库文件，它的有无是可选的，对重定位文件，它是必须有的。

Program header table

每个程序头表的每个表项的结构为：
typedefstruct
{
Elf32_Wordp_type;/*段类型*/
Elf32_Offp_offset;/*在文件中的偏移*/
Elf32_Addrp_vaddr;/*执行时的虚地址*/
Elf32_Addrp_paddr;/*执行时的物理地址*/
Elf32_Wordp_filesz;/*在文件中的字节数*/
Elf32_Wordp_memsz;/*在内存中的字节数*/
Elf32_Wordp_flags;/*标志*/
Elf32_Wordp_align;/*字节对齐*/
}Elf32_Phdr;

那什么是所谓 sections 呢？可以说，sections 是在ELF文件里头，用以装载内容数据的最小容器。在ELF文件里面，每一个 sections 内都装载了性质属性都一样的内容，比方：

1) .text section 里装载了可执行代码；

2) .data section 里面装载了被初始化的数据；

3) .bss section 里面装载了未被初始化的数据；

4) 以 .rec 打头的 sections 里面装载了重定位条目；

5) .symtab 或者 .dynsym section 里面装载了符号信息；

6) .strtab 或者 .dynstr section 里面装载了字符串信息；

7) 其他还有为满足不同目的所设置的section，比方满足调试的目的、满足动态链接与加载的目的等等。

Section heafer table

每个节头表的每个表项的结构为：

typedefstruct
{
Elf32_Wordsh_name;/*节名索引*/
Elf32_Wordsh_type;/*节类型*/
Elf32_Wordsh_flags;/*加载和读写标志*/
Elf32_Addrsh_addr;/*执行时的虚地址*/
Elf32_Offsh_offset;/*在文件中的偏移*/
Elf32_Wordsh_size;/*字节大小*/
Elf32_Wordsh_link;/*与其他节的关联*/
Elf32_Wordsh_info;/*其他信息*/
Elf32_Wordsh_addralign;/*字节对齐*/
Elf32_Wordsh_entsize;/*如果由表项组成，每个表项的大小*/
}Elf32_Shdr;

这里我们来讨论一下连接视图中section与装载运行视图segments之间的关系。

链接器在链接可执行文件或动态库的过程中，它会把来自不同可重定位对象文件中的相同名称的 section 合并起来构成同名的 section。接着，它又会把带有相同属性(比方都是只读并可加载的)的 section 都合并成所谓 segments(段)。segments 作为链接器的输出，常被称为输出section。

一个单独的 segment 通常会包含几个不同的 sections，比方一个可被加载的、只读的segment 通常就会包括可执行代码section .text、只读的数据section .rodata以及给动态链接器使用的符号section .dymsym等等。section 是被链接器使用的，但是 segments 是被加载器所使用的。加载器会将所需要的 segment 加载到内存空间中运行。和用 sections header table 来指定一个可重定位文件中到底有哪些 sections 一样。在一个可执行文件或者动态库中， program header table中包含有 segments。

在当我们执行命令readelf -l读取程序表头的时候，结果显示，在可执行文件中，总共有8个 segments程序头。同时，该结果也很明白显示出了哪些 section 映射到哪一个 segment 当中去。比方在索引为2的那个segment 中，总共有18个 sections 映射进来，其中包括我们前面提到过的 .text section。注意这个segment 有两个标志: R 和 E。这个表示该segment是可读的，也可执行的。如果你看到标志中有W，那表示该segment是可写的。

上面类型为PHDR的segment，用来包含程序头表本身。类型为INTERP的segment只包含一个 section，那就是 .interp。在这个section中，包含了动态链接过程中所使用的解释器路径和名称。在Linux里面，这个解释器实际上就是 /lib/ ，这可以通过下面的 hexdump 看出来：[yihect@juliantec test_2]$ hexdump -s 0x134 -n 32 -C ./ElfCrackme2 
$ hexdump -s 0x134 -n 32 -C ./ElfCrackMe2
00000134 2f 6c 69 62 2f 6c 64 2d 6c 69 6e 75 78 2e 73 6f |/lib/ld-linux.so|
00000144 2e 32 00 00 04 00 00 00 10 00 00 00 01 00 00 00 |.2..............|
00000154
关于ELF格式的知识就说到这，想了解更多的去了解下大牛的文章 点击打开链接