素材來源：綜合CSDN

編輯整理：strongerHuang

關于計算機的文件有很多種，今天分享一種用于二進制文件、可執行文件、目標代碼、共享庫和核心轉儲格式文件。

一、ELF文件簡介

ELF：Executable and Linkable Format，可執行與可鏈接格式。

首先，你需要知道的是所謂對象文件（Object files）有三個種類：

1）可重定向文件：文件保存著代碼和適當的數據，用來和其他的目標文件一起來創建一個可執行文件或者是一個共享目標文件。（目標文件或者靜態庫文件，即通常后綴為.a和.o的文件）

2）可執行文件：文件保存著一個用來執行的程序。（例如bash，gcc等）

3）共享目標文件：共享庫。文件保存著代碼和合適的數據，用來被下連接編輯器和動態鏈接器鏈接。

二、ELF文件格式

首先，ELF文件格式提供了兩種視圖，分別是鏈接視圖和執行視圖。

鏈接視圖是以節（section）為單位，執行視圖是以段（segment）為單位。鏈接視圖就是在鏈接時用到的視圖，而執行視圖則是在執行時用到的視圖。上圖左側的視角是從鏈接來看的，右側的視角是執行來看的。總個文件可以分為四個部分：

ELF header：描述整個文件的組織。

Program Header Table： 描述文件中的各種segments，用來告訴系統如何創建進程映像的。

sections 或者 segments：segments是從運行的角度來描述elf文件，sections是從鏈接的角度來描述elf文件，也就是說，在鏈接階段，我們可以忽略program header table來處理此文件，在運行階段可以忽略section header table來處理此程序（所以很多加固手段刪除了section header table）。從圖中我們也可以看出，segments與sections是包含的關系，一個segment包含若干個section。

Section Header Table： 包含了文件各個segction的屬性信息，我們都將結合例子來解釋。

程序頭部表（Program Header Table），如果存在的話，告訴系統如何創建進程映像。

節區頭部表（Section Header Table）包含了描述文件節區的信息，比如大小、偏移等。

如下圖，可以通過執行命令”readelf -S android_server”來查看該可執行文件中有哪些section。

通過執行命令readelf –segments android_server，可以查看該文件的執行視圖。

這驗證了第一張圖中所述，segment是section的一個集合，sections按照一定規則映射到segment。那么為什么需要區分兩種不同視圖？

當ELF文件被加載到內存中后，系統會將多個具有相同權限（flg值）section合并一個segment。操作系統往往以頁為基本單位來管理內存分配，一般頁的大小為4096B，即4KB的大小。同時，內存的權限管理的粒度也是以頁為單位，頁內的內存是具有同樣的權限等屬性，并且操作系統對內存的管理往往追求高效和高利用率這樣的目標。ELF文件在被映射時，是以系統的頁長度為單位的，那么每個section在映射時的長度都是系統頁長度的整數倍，如果section的長度不是其整數倍，則導致多余部分也將占用一個頁。而我們從上面的例子中知道，一個ELF文件具有很多的section，那么會導致內存浪費嚴重。這樣可以減少頁面內部的碎片，節省了空間，顯著提高內存利用率。

需要注意地是：盡管圖中顯示的各個組成部分是有順序的，實際上除了 ELF 頭部表以外，其他節區和段都沒有規定的順序。

三、ELF Header

首先，我們先來看下32位ELF文件中常用的數據格式：名稱大小對齊目的

Elf32_Addr44無符號程序地址

Elf32_Half22無符號中等整數

Elf32_Off44無符號文件偏移

Elf32_SWord44有符號大整數

Elf32_Word44無符號大整數

unsigned char11無符號小整數

然后我們來觀察一下ELF Header的結構體：

#define EI_NIDENT 16typedef struct { unsigned char e_ident［EI_NIDENT］; ELF32_Half e_type; ELF32_Half e_machine; ELF32_Word e_version; ELF32__Addr e_entry; ELF32_Off e_phoff; ELF32_Off e_shoff; ELF32_Word e_flags; 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;

e_ident ：ELF的一些標識信息，前四位為.ELF，其他的信息比如大小端等

e_machine ：文件的目標體系架構，比如ARM

e_version ： 0為非法版本，1為當前版本

e_entry ：程序入口的虛擬地址

e_phoff ：程序頭部表偏移地址

e_shoff ：節區頭部表偏移地址

e_flags ：保存與文件相關的，特定于處理器的標志

e_ehsize ：ELF頭的大小

e_phentsize ：每個程序頭部表的大小

e_phnum ：程序頭部表的數量

e_shentsize：每個節區頭部表的大小

e_shnum ：節區頭部表的數量

e_shstrndx：節區字符串表位置

接著運行readelf -h android_server命令，可以看到ELF Header結構的內容。

或者使用010Editor的ELF模板也可以看到ELF Header結構。對比以下三類ELF文件，我們得到了以下結論：

1、e_type標識了文件類型

2、Relocatable File（.o文件）不需要執行，因此e_entry字段為0，且沒有Program Header Table等執行視圖

3、不同類型的ELF文件的Section也有較大區別，比如只有Relocatable File有.strtab節。

Shared Object File（.so文件）

Executable File（可執行文件android_server）

Relocatable File（.o文件）

四、Section Header Table

一個ELF文件中到底有哪些具體的 sections，由包含在這個ELF文件中的 section head table（SHT）決定。在SHT中，針對每一個section，都設置有一個條目（entry），用來描述對應的這個section，其內容主要包括該 section 的名稱、類型、大小以及在整個ELF文件中的字節偏移位置等等。我們也可以在TISCv1.2規范中找到SHT表中條目的C結構定義：

typedef struct{ Elf32_Word sh_name; //節區名，是節區頭部字符串表節區（Section Header String Table Section）的索引。名字是一個 NULL 結尾的字符串。 Elf32_Word sh_type; //為節區類型 Elf32_Word sh_flags; //節區標志 Elf32_Addr sh_addr; //如果節區將出現在進程的內存映像中，此成員給出節區的第一個字節應處的位置。否則，此字段為 0。 Elf32_Off sh_offset; //此成員的取值給出節區的第一個字節與文件頭之間的偏移。 Elf32_Word sh_size; //此 成 員 給 出 節 區 的 長 度 （ 字 節 數 ）。 Elf32_Word sh_link; //此成員給出節區頭部表索引鏈接。其具體的解釋依賴于節區類型。 Elf32_Word sh_info; //此成員給出附加信息，其解釋依賴于節區類型。 Elf32_Word sh_addralign; //某些節區帶有地址對齊約束。 Elf32_Word sh_entsize; //某些節區中包含固定大小的項目，如符號表。對于這類節區，此成員給出每個表項的長度字節數。}Elf32_Shdr;

sh_type的取值如下：

名稱取值說明

SHT_NULL0此值標志節區頭部是非活動的，沒有對應的節區。此節區頭部中的其他成員取值無意義。

SHT_PROGBITS1此節區包含程序定義的信息，其格式和含義都由程序來解釋。

SHT_SYMTAB2此節區包含一個符號表。目前目標文件對每種類型的節區都只能包含一個，不過這個限制將來可能發生變化。一般，SHT_SYMTAB 節區提供用于鏈接編輯（指 ld 而言）的符號，盡管也可用來實現動態鏈接。

SHT_STRTAB3此節區包含字符串表。目標文件可能包含多個字符串表節區。

SHT_RELA4此節區包含重定位表項，其中可能會有補齊內容（addend），例如 32 位目標文件中的 Elf32_Rela 類型。目標文件可能擁有多個重定位節區。

SHT_HASH5此節區包含符號哈希表。所有參與動態鏈接的目標都必須包含一個符號哈希表。目前，一個目標文件只能包含一個哈希表，不過此限制將來可能會解除。

SHT_DYNAMIC6此節區包含動態鏈接的信息。目前一個目標文件中只能包含一個動態節區，將來可能會取消這一限制。

SHT_NOTE7此節區包含以某種方式來標記文件的信息。

SHT_NOBITS8這 種 類 型 的 節 區 不 占 用 文 件 中 的 空 間 ， 其 他 方 面 和SHT_PROGBITS 相似。盡管此節區不包含任何字節，成員sh_offset 中還是會包含概念性的文件偏移

SHT_REL9此節區包含重定位表項，其中沒有補齊（addends），例如 32 位目標文件中的 Elf32_rel 類型。目標文件中可以擁有多個重定位節區。

SHT_SHLIB10此節區被保留，不過其語義是未規定的。包含此類型節區的程序與 ABI 不兼容。

SHT_DYNSYM11作為一個完整的符號表，它可能包含很多對動態鏈接而言不必要的符號。因此，目標文件也可以包含一個 SHT_DYNSYM 節區，其中保存動態鏈接符號的一個最小集合，以節省空間。

SHT_LOPROC0X70000000這一段（包括兩個邊界），是保留給處理器專用語義的。

SHT_HIPROCOX7FFFFFFF這一段（包括兩個邊界），是保留給處理器專用語義的。

SHT_LOUSER0X80000000此值給出保留給應用程序的索引下界。

SHT_HIUSER0X8FFFFFFF此值給出保留給應用程序的索引上界。

五、Section

有些節區是系統預訂的，一般以點開頭號，因此，我們有必要了解一些常用到的系統節區。

名稱類型屬性含義

.bssSHT_NOBITSSHF_ALLOC +

SHF_WRITE包含將出現在程序的內存映像中的為初始化數據。根據定義，當程序開始執行，系統將把這些數據初始化為 0。此節區不占用文件空間。

.commentSHT_PROGBITS（無）包含版本控制信息。

.dataSHT_PROGBITSSHF_ALLOC +

SHF_WRITE這些節區包含初始化了的數據，將出現在程序的內存映像中。

.data1SHT_PROGBITSSHF_ALLOC +

SHF_WRITE這些節區包含初始化了的數據，將出現在程序的內存映像中。

.debugSHT_PROGBITS（無）此節區包含用于符號調試的信息。

.dynamicSHT_DYNAMIC

此節區包含動態鏈接信息。節區的屬性將包含 SHF_ALLOC 位。是否 SHF_WRITE 位被設置取決于處理器。

.dynstrSHT_STRTABSHF_ALLOC此節區包含用于動態鏈接的字符串，大多數情況下這些字符串代表了與符號表項相關的名稱。

.dynsymSHT_DYNSYMSHF_ALLOC此節區包含了動態鏈接符號表。

.finiSHT_PROGBITSSHF_ALLOC +

SHF_EXECINSTR此節區包含了可執行的指令，是進程終止代碼的一部分。程序正常退出時，系統將安排執行這里的代碼。

.gotSHT_PROGBITS

此節區包含全局偏移表。

.hashSHT_HASHSHF_ALLOC此節區包含了一個符號哈希表。

.initSHT_PROGBITSSHF_ALLOC +

SHF_EXECINSTR此節區包含了可執行指令，是進程初始化代碼的一部分。當程序開始執行時，系統要在開始調用主程序入口之前（通常指 C 語言的 main 函數）執行這些代碼。

.interpSHT_PROGBITS

此節區包含程序解釋器的路徑名。如果程序包含一個可加載的段，段中包含此節區，那么節區的屬性將包含 SHF_ALLOC 位，否則該位為 0。

.lineSHT_PROGBITS（無）此節區包含符號調試的行號信息，其中描述了源程序與機器指令之間的對應關系。其內容是未定義的。

.noteSHT_NOTE（無）此節區中包含注釋信息，有獨立的格式。

.pltSHT_PROGBITS

此節區包含過程鏈接表（procedure linkage table）。

.relname

.relanameSHT_REL

SHT_RELA

這些節區中包含了重定位信息。如果文件中包含可加載的段，段中有重定位內容，節區的屬性將包含 SHF_ALLOC 位，否則該位置 0。傳統上 name 根據重定位所適用的節區給定。例如 .text 節區的重定位節區名字將是：.rel.text 或者 .rela.text。

.rodata

.rodata1SHT_PROGBITSSHF_ALLOC這些節區包含只讀數據，這些數據通常參與進程映像的不可寫段。

.shstrtabSHT_STRTAB

此節區包含節區名稱。

.strtabSHT_STRTAB

此節區包含字符串，通常是代表與符號表項相關的名稱。如果文件擁有一個可加載的段，段中包含符號串表，節區的屬性將包含SHF_ALLOC 位，否則該位為 0。

.symtabSHT_SYMTAB

此節區包含一個符號表。如果文件中包含一個可加載的段，并且該段中包含符號表，那么節區的屬性中包含SHF_ALLOC 位，否則該位置為 0。

.textSHT_PROGBITSSHF_ALLOC +

SHF_EXECINSTR此節區包含程序的可執行指令。

六、Program Header Table

程序頭部（Program Header）描述與程序執行直接相關的目標文件結構信息。用來在文件中定位各個段的映像。同時包含其他一些用來為程序創建映像所必須的信息。

可執行文件或者共享目標文件的程序頭部是一個結構數組，每個結構描述了一個段或者系統準備程序執行所必須的其他信息。目標文件的“段”包含一個或者多個“節區”，也就是“段內容（Segment Contents）”。程序頭部僅對可執行文件和共享目標文件有意義。

程序頭部的數據結構如下：

typedef struct { Elf32_Word p_type; //此數組元素描述的段的類型，或者如何解釋此數組元素的信息。 Elf32_Off p_offset; //此成員給出從文件頭到該段第一個字節的偏移 Elf32_Addr p_vaddr; //此成員給出段的第一個字節將被放到內存中的虛擬地址 Elf32_Addr p_paddr; //此成員僅用于與物理地址相關的系統中。System V忽略所有應用程序的物理地址信息。 Elf32_Word p_filesz; //此成員給出段在文件映像中所占的字節數。可以為0。 Elf32_Word p_memsz; //此成員給出段在內存映像中占用的字節數。可以為0。 Elf32_Word p_flags; //此成員給出與段相關的標志。 Elf32_Word p_align; //此成員給出段在文件中和內存中如何對齊。} Elf32_phdr;

p_type：

名稱取值說明

PT_NULL0此數組元素未用。結構中其他成員都是未定義的。

PT_LOAD1此數組元素給出一個可加載的段，段的大小由 p_filesz 和 p_memsz描述。文件中的字節被映射到內存段開始處。如果 p_memsz 大于p_filesz，“剩余”的字節要清零。p_filesz 不能大于 p_memsz。可加載的段在程序頭部表格中根據 p_vaddr 成員按升序排列。

PT_DYNAMIC2數組元素給出動態鏈接信息。

PT_INTERP3數組元素給出一個 NULL 結尾的字符串的位置和長度，該字符串將被當作解釋器調用。這種段類型僅對與可執行文件有意義（盡管也可能在共享目標文件上發生）。在一個文件中不能出現一次以上。如果存在這種類型的段，它必須在所有可加載段項目的前面。

PT_NOTE4此數組元素給出附加信息的位置和大小。

PT_SHLIB5此段類型被保留，不過語義未指定。包含這種類型的段的程序與 ABI不符。

PT_PHDR6此類型的數組元素如果存在，則給出了程序頭部表自身的大小和位置，既包括在文件中也包括在內存中的信息。此類型的段在文件中不能出現一次以上。并且只有程序頭部表是程序的內存映像的一部分時才起作用。如果存在此類型段，則必須在所有可加載段項目的前面。

PT_LOPROC~

PT_HIPROC0x70000000~

0x7fffffff此范圍的類型保留給處理器專用語義。

好了，本文主要內容就分享到這里，具體可以參看ELF文件詳細描述。

責任編輯：haq