程序員內功修煉：五分鐘徹底搞懂 Linux ELF 文件 !
大家好啊，我是小康。
今天咱們來聊一個看起來高深，實際上理解起來其實挺簡單的話題—— ELF 文件。
不知道你有沒有想過：我們敲下./program命令的那一刻，計算機是怎么把這個文件變成一個活蹦亂跳的進程的？這背后的"黑魔法"到底是什么？
沒錯，答案就是今天的主角：ELF（Executable and Linkable Format）可執行與可鏈接格式。你可以把它理解為 Linux 世界里程序的"靈魂容器"！
一、什么是 ELF 文件？給個痛快話！
簡單來說，ELF 是 Linux 下的可執行文件格式，就像 Windows 下的 .exe 一樣。但別被這個簡單的解釋騙了，ELF 可比 .exe 復雜得多，也強大得多！
ELF 文件可以是：
- 可執行文件（比如你的./program）
- 目標文件（編譯后但還沒鏈接的 .o 文件）
- 共享庫文件（就是 .so 文件，類似 Windows 下的 .dll）
- 核心轉儲文件（程序崩潰時的那個core dump）
本質上，ELF 就是一個容器，里面裝著代碼、數據以及程序運行所需的各種信息，按照特定的格式組織起來。
二、初見 ELF：第一印象很重要
想知道一個文件是不是 ELF 格式的？超簡單：
$ file /bin/ls
/bin/ls: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, ...看到沒？只要文件輸出信息的開頭是"ELF"，那它就是 ELF 格式的！
再來點兒硬核的，我們直接看一下 ELF 文件的前幾個字節：
$ hexdump -C -n 16 /bin/ls
00000000 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 |.ELF............|這里最開始的7f 45 4c 46就是 ELF 文件的"魔數"（Magic Number）。其中 45 4c 46 是 ASCII 碼中的 "ELF" 三個字母，前面的 7f 是一個特殊字符。這四個字節就是 ELF 文件的"身份證"，操作系統首先會檢查這四個字節，確認它是不是一個 ELF 文件。
三、ELF 文件的內部結構：化繁為簡
很多教程一上來就給你畫個復雜的結構圖，看得人頭暈眼花。咱們先別急，我用一個簡單的類比來幫你理解：
把 ELF 文件想象成一本"程序說明書"，這本書有三部分組成：
- 文件頭（ELF Header）：相當于書的封面和目錄，告訴你這本書有什么內容，怎么看
- 程序頭表（Program Header Table）：相當于給"閱讀器"（操作系統）看的指南，告訴它怎么把這本書變成一個活的程序
- 節區頭表（Section Header Table）：相當于給"編輯器"（鏈接器、調試器）看的指南，告訴它這本書的內部結構
然后，書的主體內容就是各種節區（Sections）或段（Segments），里面裝著代碼、數據等實際內容。
直觀一點，用圖來表示就是：
+------------------+
| ELF Header | <-- 文件開始處的標識信息和總體布局
+------------------+
| 程序頭表 | <-- 告訴操作系統如何加載
| Program Header 1 |
| Program Header 2 |
| ... |
+------------------+
| Section 1 | <-- 實際內容，如代碼、數據等
| Section 2 |
| ... |
+------------------+
| 節區頭表 | <-- 描述每個Section的信息
| Section Header 1 |
| Section Header 2 |
| ... |
+------------------+哎，你可能會問：什么是節區（Section）？什么又是段（Segment）？它們有什么區別？
簡單來說：
- 節區（Section）：是 ELF 文件存儲的基本單位，針對鏈接器
- 段（Segment）：是運行時內存的基本單位，針對加載器
一個段通常包含多個功能相似的節區。比如，包含代碼的所有節區會被歸入到一個叫做"TEXT"的段中。
四、深入解剖 ELF文件：逐層剝開
1. ELF頭（ELF Header）
ELF 頭是整個文件的"門面"，包含了文件的基本信息和指向其他部分的指針。用readelf -h命令可以查看：
$ readelf -h /bin/ls
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: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x5850
Start of program headers: 64 (bytes into file)
Start of section headers: 136912 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 13
Size of section headers: 64 (bytes)
Number of section headers: 30
Section header string table index: 29這里面最重要的信息是：
- Entry point address：程序執行的起點地址
- Start of program headers：程序頭表的位置
- Start of section headers：節區頭表的位置
2. 程序頭表（Program Header Table）
程序頭表告訴操作系統如何創建進程映像，用readelf -l命令查看：
$ readelf -l /bin/ls
Program Headers:
Type Offset VirtAddr PhysAddr
FileSiz MemSiz Flags Align
PHDR 0x0000000000000040 0x0000000000000040 0x0000000000000040
0x00000000000002d8 0x00000000000002d8 R 0x8
INTERP 0x0000000000000318 0x0000000000000318 0x0000000000000318
0x000000000000001c 0x000000000000001c R 0x1
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000
0x0000000000004428 0x0000000000004428 R 0x1000
LOAD 0x0000000000005000 0x0000000000005000 0x0000000000005000
0x0000000000012d1c 0x0000000000012d1c R E 0x1000
LOAD 0x0000000000018000 0x0000000000018000 0x0000000000018000
0x0000000000004d40 0x0000000000004d40 R 0x1000
LOAD 0x000000000001d520 0x000000000001e520 0x000000000001e520
0x0000000000001640 0x0000000000002270 RW 0x1000
...最重要的是那些類型為LOAD的段，它們會被加載到內存中。
注意看Flags：
- R表示可讀（Read）
- W表示可寫（Write）
- E表示可執行（Execute）
這就是為什么有的內存區域可執行，有的只能讀不能寫，這些權限在 ELF 文件里就定義好了！
3. 節區頭表（Section Header Table）
節區頭表描述了文件中各個節區的信息，用readelf -S查看：
$ readelf -S /bin/ls
There are 30 section headers, starting at offset 0x21730:
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 0000000000000318 00000318
000000000000001c 0000000000000000 A 0 0 1
[ 2] .note.gnu.build-i NOTE 0000000000000338 00000338
0000000000000024 0000000000000000 A 0 0 4
...
[11] .text PROGBITS 00000000000052a0 000052a0
0000000000012a7c 0000000000000000 AX 0 0 16
...
[23] .data PROGBITS 000000000001e520 0001d520
0000000000000e60 0000000000000000 WA 0 0 32
[24] .bss NOBITS 000000000001f380 0001e380
0000000000001410 0000000000000000 WA 0 0 32
...常見的重要節區包括：
- .text：存放程序的機器代碼
- .data：已初始化的全局變量和靜態變量
- .bss：未初始化的全局變量和靜態變量（不占用文件空間）
- .rodata：只讀數據（如字符串常量）
- .symtab：符號表，存儲程序中定義和引用的函數、變量
- .strtab：字符串表，通常存儲符號名
- .dynamic：動態鏈接信息
五、ELF 文件的生命周期：從編譯到執行
為了徹底搞懂 ELF 文件，我們需要了解它的整個生命周期：
源代碼(.c) --編譯--> 目標文件(.o) --鏈接--> 可執行文件 --加載--> 進程1. 編譯階段：生成目標文件(.o)
當你寫完 C 代碼，運行gcc -c hello.c時，會得到一個hello.o的目標文件。這個文件已經是 ELF 格式的了，但它還不能直接執行，因為里面有很多"坑"等著被填上。
這些"坑"在 ELF 文件中表現為"重定位表"，用readelf -r可以看到：
$ readelf -r hello.o
Relocation section '.rela.text' at offset 0x2d0 contains 2 entries:
Offset Info Type Sym. Value Sym. Name + Addend
000000000013 000a00000004 R_X86_64_PLT32 0000000000000000 printf - 4
000000000023 000b00000004 R_X86_64_PLT32 0000000000000000 exit - 4這表示代碼中調用了printf和exit函數，但編譯器不知道它們在哪兒，所以留了個"坑"等著鏈接器來填。
2. 符號表：程序的"通訊錄"
說到這些函數(printf 、exit)，咱們不得不提 ELF 文件中的"符號表"。簡單來說，符號表就像是程序的"通訊錄"，記錄了程序中所有函數和變量的名字和位置。
來看看符號表長啥樣：
$ readelf -s hello.o
Symbol table '.symtab' contains 12 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND
1: 0000000000000000 0 FILE LOCAL DEFAULT ABS hello.c
2: 0000000000000000 0 SECTION LOCAL DEFAULT 1
...
9: 0000000000000000 41 FUNC GLOBAL DEFAULT 1 main
10: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND printf
11: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND exit瞧，這里面有main函數（我們自己定義的），還有printf和exit（外部函數）。注意它們的Ndx（索引）列：main是1，表示在第1個節區；而printf和exit是UND，表示"未定義"，這就是前面說的"坑"。
這個目標文件的符號表就像一張"半成品通訊錄"，只記錄了自己有什么函數，以及自己需要哪些外部函數，但還不知道那些外部函數在哪里。所以它還不能獨立工作，需要鏈接器來幫忙找到這些外部函數。
3. 動態鏈接：程序的"即插即用"
說到外部函數，就不得不提 ELF 的一個超強功能：動態鏈接。
還記得 Windows 上安裝軟件時經常冒出的"DLL缺失"錯誤嗎？Linux 上也有類似概念，不過實現得更優雅，這就是動態鏈接庫（.so文件）。
動態鏈接的好處簡直不要太多：
- 節省內存：多個程序共享同一個庫
- 節省磁盤：不用把所有代碼都打包進可執行文件
- 方便升級：庫更新后，程序自動用上新版本，不用重新編譯
那么問題來了：程序怎么知道自己需要哪些庫？又是如何找到這些庫的呢？
ELF 文件中有一個特殊的.dynamic節區，專門記錄這些信息：
$ readelf -d /bin/ls | grep NEEDED
0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]這告訴我們，ls命令依賴于這兩個共享庫。如果你想更直觀地看到所有依賴及它們的實際位置，可以用ldd命令：
$ ldd /bin/ls
linux-vdso.so.1 (0x00007ffc961cd000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f27f989e000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f27f96b3000)
...看到沒？ldd不僅告訴你需要哪些庫，還告訴你它們的實際位置和加載地址。
那程序又是怎么找到這些庫的呢？它會按照以下順序查找：
- 環境變量LD_LIBRARY_PATH指定的目錄
- 可執行文件的RPATH屬性指定的目錄
- /etc/ld.so.cache緩存中記錄的位置
- 默認目錄如/lib、/usr/lib等
動態鏈接器（ld.so）會在程序啟動時自動處理這些依賴關系，把所有需要的庫都加載進來，就像樂高積木一樣把程序拼裝完整，非常巧妙！
4. 鏈接階段：生成可執行文件
鏈接器會把多個目標文件和庫文件鏈接在一起，解決那些"坑"（重定位），最終生成可執行文件。
那么鏈接器具體是怎么解決這些"坑"的呢？簡單來說就是做個"牽線搭橋"的活：
- 收集所有目標文件中的符號表，建立一個全局符號表
- 找到所有標記為"未定義"（UND）的符號
- 在全局符號表或者庫文件中尋找這些符號的定義
- 把找到的地址填回原來的"坑"中
比如當鏈接器找到printf函數在 libc.so 中的實際地址后，就會修改原來調用 printf 的指令，讓它指向正確的地址。
鏈接完成后，再看同一個程序的符號表，會發現那些 UND 的符號要么有了實際地址（靜態鏈接），要么指向了動態鏈接的跳轉表（動態鏈接）。
在動態鏈接的情況下，還會在 ELF 文件中記錄運行時需要哪些共享庫，前面已經說過了。
5. 加載階段：從文件到進程
當你執行./program時，操作系統（確切地說是加載器 ld.so ）會做這些事：
- 檢查 ELF 頭的合法性
- 根據程序頭表，將需要的段加載到內存
- 如果是動態鏈接的，還會找到并加載所需的共享庫
- 跳轉到 Entry Point 開始執行
這個過程可以用strace命令觀察：
$ strace ./hello
execve("./hello", ["./hello"], 0x7ffcef8db490 /* 52 vars */) = 0
brk(NULL) = 0x55c84f34c000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
...execve就是創建新進程的系統調用，后面一系列操作就是在加載和準備程序運行環境。
六、ELF實用工具箱：玩轉ELF文件
好了，了解了 ELF 的原理后，來看看有哪些工具可以幫我們操作 ELF 文件：
(1) file：判斷文件類型
$ file /bin/ls(2) readelf：查看ELF文件的所有信息
$ readelf -a /bin/ls # 顯示全部信息(3) objdump：反匯編 ELF 文件
$ objdump -d /bin/ls # 反匯編代碼段(4) nm：列出符號表
$ nm /bin/ls # 顯示符號（函數、變量）(5) ldd：查看動態依賴
$ ldd /bin/ls # 顯示依賴的共享庫(6) strings：提取文件中的字符串
$ strings /bin/ls | grep "GNU" # 查找包含"GNU"的字符串(7) strip：移除ELF文件中的符號表和調試信息
$ strip -s program # 減小文件體積(8) patchelf：修改 ELF 文件的屬性
$ patchelf --set-interpreter /lib64/ld-custom.so program # 修改解釋器七、實際應用：ELF文件的那些神奇玩法
ELF文件的知識不僅僅是理論，來看看一些實際的例子：
1. 程序加固與混淆
想象你開發了一個軟件不想被輕易破解：
# 刪除符號表，讓逆向分析更困難
$ strip --strip-all myprogram
# 對比前后大小
$ ls -lh myprogram*
-rwxr-xr-x 1 user user 236K myprogram
-rwxr-xr-x 1 user user 176K myprogram.stripped看，文件體積一下減少了幾十k，因為符號信息都被刪掉了！
2. 程序補丁與熱修復
假設你想修改程序使用的解釋器路徑：
# 查看當前解釋器
$ readelf -l myprogram | grep interpreter
[Requesting program interpreter: /lib64/ld-linux-x86-64.so.2]
# 修改為自定義解釋器
$ patchelf --set-interpreter /opt/mylibs/ld-linux.so myprogram
# 確認修改成功
$ readelf -l myprogram | grep interpreter
[Requesting program interpreter: /opt/mylibs/ld-linux.so]這樣程序就會使用你自定義的動態鏈接器，而不需要重新編譯！
更酷的是，Linux 還提供了一種不用重啟程序就能熱修復的黑科技——LD_PRELOAD環境變量！它可以讓你悄悄地"替換"程序中的函數實現。
來看一個簡單實用的例子 —— 監控程序的內存分配：
創建一個簡單的內存跟蹤庫: memtrace.c
#define _GNU_SOURCE
#include <stdio.h>
#include <dlfcn.h>
// 原始malloc函數指針
staticvoid* (*real_malloc)(size_t) = NULL;
// 攔截 malloc 函數
void* malloc(size_t size) {
// 延遲初始化原始函數
if (real_malloc == NULL) {
real_malloc = dlsym(RTLD_NEXT, "malloc");
}
// 調用原始malloc
void* ptr = real_malloc(size);
// 打印跟蹤信息
fprintf(stderr, "malloc(%zu) = %p\n", size, ptr);
return ptr;
}編譯成共享庫:
$ gcc -shared -fPIC memtrace.c -o libmemtrace.so -ldl接著使用我們的庫監控任何程序的內存分配：
LD_PRELOAD=./libmemtrace.so ./my_program輸出：
malloc(100) = 0x55e930e2f6b0
malloc(200) = 0x55e930e2f720
malloc(300) = 0x55e930e2f7f0看到了嗎？我們只用了十幾行代碼，就實現了一個能夠監控任何程序內存分配的工具！這個例子的工作原理很簡單：
- 定義一個與系統函數同名的malloc
- 用dlsym(RTLD_NEXT, "malloc")找到真正的 malloc 函數
- 在調用真正的 malloc 前后添加我們的代碼（這里是打印日志）
- 通過LD_PRELOAD讓系統優先加載我們的庫
這種技術經常用于：
- 調試內存問題
- 給程序添加日志
- 修改程序行為而不用改源碼
- 臨時修復運行中的服務
當然，這項技術也常被黑客利用來劫持程序函數，所以理解它不僅能提升編程能力，也對安全防護很重要！
八、總結：ELF 文件的精髓
好了，咱們來總結一下 ELF 文件的核心要點：
(1) ELF是容器：裝載了代碼、數據和各種元數據
(2) 分層結構：ELF 頭、程序頭表、節區、節區頭表
(3) 兩種視角：
- 執行視角：段（Segments）- 加載器關心
- 鏈接視角：節（Sections）- 鏈接器關心
(4) 生命周期：從源代碼到目標文件，再到可執行文件，最后變成進程
當你理解了 ELF 文件的本質，Linux 下的很多問題就迎刃而解了：為什么有些程序不能在不同版本的 Linux 上運行？為什么動態庫版本不匹配會導致程序崩潰？為什么有些惡意軟件難以檢測？——這些問題的答案都藏在 ELF 文件的結構中！
記住，ELF 文件不僅僅是一個格式，它是 Linux 世界中程序的"靈魂容器"，承載著程序從編譯到執行的整個生命周期。
