linux c system函數介紹

system（執行shell 命令）
相關函數
??????? fork，execve，waitpid，popen
表頭文件
??????? ＃i nclude<stdlib.h>
定義函數
??????? int system(const char * string);
函數說明
??????? system()會調用fork()產生子進程，由子進程來調用/bin/sh-c string來執行參數string字符串

所代表的命令，此命>令執行完后隨即返回原調用的進程。在調用system()期間SIGCHLD 信號會被暫時擱

置，SIGINT和SIGQUIT 信號則會被忽略。
返回值
? =-1:出現錯誤?
? =0:調用成功但是沒有出現子進程?
? >0:成功退出的子進程的id
??????? 如果system()在調用/bin/sh時失敗則返回127，其他失敗原因返回-1。若參數string為空指針

(NULL)，則返回非零值>。如果system()調用成功則最后會返回執行shell命令后的返回值，但是此返回值

也有可能為 system()調用/bin/sh失敗所返回的127，因此最好能再檢查errno 來確認執行成功。
附加說明
??????? 在編寫具有SUID/SGID權限的程序時請勿使用system()，system()會繼承環境變量，通過環境變

量可能會造成系統安全的問題。
范例
??????? ＃i nclude<stdlib.h>
main()
{
system("ls -al /etc/passwd /etc/shadow");
}
執行結果：

-rw-r--r-- 1 root root 705 Sep 3 13 :52 /etc/passwd
-r--------- 1 root root 572 Sep 2 15 :34 /etc/shado

例2：

char tmp[];
sprintf(tmp,"/bin/mount -t vfat %s /mnt/usb",dev);
system(tmp);
其中dev是/dev/sda1。

system函數的源碼

#include <sys/types.h>
#include <sys/wait.h>
#include <errno.h>
#include <unistd.h>

int system(const char * cmdstring)

{
??? pid_t pid;
??? int status;
??? if(cmdstring == NULL){
??????? return (1);
??? }

??? if((pid = fork())<0){
??????? status = -1;
??? }
??? else if(pid = 0){
??????? execl("/bin/sh", "sh", "-c", cmdstring, (char *)0);
??????? _exit(127); //子進程正常執行則不會執行此語句
??? }
??? else

????? {
?????? while(waitpid(pid, &status, 0) < 0){
????????? if(errno != EINTER)

??????????? {
???????????? status = -1;
???????????? break;
??????????? }
????????? }
????? }

??? return status;
}
那么如何獲得system的返回值呢??
char buf[10];
char * ps="ps -ef|grep -c root";
FILE *ptr;
int i;

if((ptr = popen(ps, "r")) != NULL)
{
??????? fgets(buf, 10 , ptr);
??????? i = atoi(buf);
??????? pclose(ptr);
}

?

可以man下waitpid查看下如何檢查status的值??

int ret = system("ls -al /etc/passwd /etc/shadow");

? if(WIFSIGNALED(ret))

具體的這些宏查看man waitpid

?

可以返回執行結果的system函數加強版本

在GNU Linux C編程中，要想進行系統命令的執行的話，只提供了system接口，但是此接口并不能得到命

令執行后所輸出的值，而只能夠得到命令是否執行成功的結果。僅僅這樣的功能還是不夠的，有的時候是

要必須通過命令的輸出來判斷下一步的結果或步驟的，那么怎么樣能夠得到system命令執行的結果呢？那

就可以使用到popen函數和fgets函數進行命令的輸出信息的獲取了，實際例子如下：

注意：此接口只能夠獲取命令輸出的最后一行的信息，若有多行輸出信息將不能夠全部獲取到，此封裝接

口只適用于得到命令執行結果的最后一行的信息。

#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>

int super_system(const char * cmd, char *retmsg, int msg_len)
{
??????? FILE * fp;
??????? int res = -1;
??????? if (cmd == NULL || retmsg == NULL || msg_len < 0)
??????? {
??????????????? printf("Err: Fuc:%s system paramer invalid!\n", __func__);
??????????????? return 1;
??????? }
??????? if ((fp = popen(cmd, "r") ) == NULL)
??????? {
??????????????? perror("popen");
??????????????? printf("Err: Fuc:%s popen error: %s\n", __func__, strerror(errno));
??????????????? return 2;
??????? }
??????? else
??????? {
??????????????? memset(retmsg, 0, msg_len);
??????????????? while(fgets(retmsg, msg_len, fp));
??????????????? {
??????????????????????? printf("Fuc: %s fgets buf is %s\n", __func__, retmsg);
??????????????? }
??????????????? if ( (res = pclose(fp)) == -1)
??????????????? {
??????????????????????? printf("Fuc:%s close popen file pointer fp error!\n", __func__);
??????????????????????? return 3;
??????????????? }
??????????????? //drop #012 from system result retmsg.
??????????????? retmsg[strlen(retmsg)-1] = '\0';
??????????????? return 0;
??????? }
}

int main()
{
??? char *cmd = "whoami";
??? char *cmd1 = "initctl list";
??? char retmsg[1024] = {0};
??? int ret = 0;
??? ret? = super_system(cmd, retmsg, sizeof(retmsg));
??? printf("system ret is %d retmsg is \n%s\n", ret, retmsg);
??? return 0;
}

main函數中使用了whoami的命令，執行結果即是當前用戶名。
執行結果：
linuxidc@ufo:~$ ./a.out

Fuc: super_system fgets buf is linuxidc

system ret is 0 retmsg is
linuxidc

自動編譯工具

? ? 在Linux下面，編寫makefile是一件辛苦的事情。因此，為了減輕程序員編寫makefile的負擔，人們發明了autoconf和automake這兩個工具，可以很好地幫我們解決這個問題。
? ? 我們可以通過一個簡單的示例來說明如何使用配置工具。


（1）首先，編寫源文件hello.c。
[cpp] view plaincopy
#include <stdio.h> ?
??
int main(int argc, char** argv[]) ?
{ ?
? ? printf("hello, world!\n"); ?
? ? return 1; ?
} ?
（2）接下來，我們需要創建一個Makefile.am，同時編寫上腳本。
[cpp] view plaincopy
SUBDIRS= ?
??
bin_PROGRAMS=hello ?
hello_SOURCES=hello.c ? ?


（3）直接輸入autoscan，生成文件configure.scan，再改名為configure.in。


修改腳本AC_INIT(FULL-PACKAGE-NAME, VERSION, BUG-REPORT-ADDRESS)
為AC_INIT(hello, 1.0, feixiaoxing@163.com)


同時，在AC_CONFIG_HEADER([config.h])后面添加
AM_INIT_AUTOMAKE(hello, 0.1)


（4）依次輸入aclocal命令、autoheader命令


（5）創建4個文件，分別為README、NEWS、AUTHORS和ChangeLog


（6）依次輸入automake -a、autoconf命令


（7）輸入./configure，生成最終的Makefile


（8）如果需要編譯，輸入make；如果需要安裝， 輸入make install；如果需要發布軟件包，輸入make dist

========

UNIX/LINUX 平臺可執行文件格式分析

本文討論了 UNIX/LINUX 平臺下三種主要的可執行文件格式：a.out（assembler and link editor output 匯編器和鏈接編輯器的輸出）、COFF（Common Object File Format 通用對象文件格式）、ELF（Executable and Linking Format 可執行和鏈接格式）。首先是對可執行文件格式的一個綜述，并通過描述 ELF 文件加載過程以揭示可執行文件內容與加載運行操作之間的關系。隨后依此討論了此三種文件格式，并著重討論 ELF 文件的動態連接機制，其間也穿插了對各種文件格式優缺點的評價。最后對三種可執行文件格式有一個簡單總結，并提出作者對可文件格式評價的一些感想。


可執行文件格式綜述
相對于其它文件類型，可執行文件可能是一個操作系統中最重要的文件類型，因為它們是完成操作的真正執行者。可執行文件的大小、運行速度、資源占用情況以及可擴展性、可移植性等與文件格式的定義和文件加載過程緊密相關。研究可執行文件的格式對編寫高性能程序和一些黑客技術的運用都是非常有意義的。
不管何種可執行文件格式，一些基本的要素是必須的，顯而易見的，文件中應包含代碼和數據。因為文件可能引用外部文件定義的符號（變量和函數），因此重定位信息和符號信息也是需要的。一些輔助信息是可選的，如調試信息、硬件信息等。基本上任意一種可執行文件格式都是按區間保存上述信息，稱為段（Segment）或節（Section）。不同的文件格式中段和節的含義可能有細微區別，但根據上下文關系可以很清楚的理解，這不是關鍵問題。最后，可執行文件通常都有一個文件頭部以描述本文件的總體結構。
相對可執行文件有三個重要的概念：編譯（compile）、連接（link，也可稱為鏈接、聯接）、加載（load）。源程序文件被編譯成目標文件，多個目標文件被連接成一個最終的可執行文件，可執行文件被加載到內存中運行。因為本文重點是討論可執行文件格式，因此加載過程也相對重點討論。下面是LINUX平臺下ELF文件加載過程的一個簡單描述。
1：內核首先讀ELF文件的頭部，然后根據頭部的數據指示分別讀入各種數據結構，找到標記為可加載（loadable）的段，并調用函數 mmap()把段內容加載到內存中。在加載之前，內核把段的標記直接傳遞給 mmap()，段的標記指示該段在內存中是否可讀、可寫，可執行。顯然，文本段是只讀可執行，而數據段是可讀可寫。這種方式是利用了現代操作系統和處理器對內存的保護功能。著名的Shellcode（ 參考資料 17）的編寫技巧則是突破此保護功能的一個實際例子。
2：內核分析出ELF文件標記為 PT_INTERP 的段中所對應的動態連接器名稱，并加載動態連接器。現代 LINUX 系統的動態連接器通常是 /lib/ld-linux.so.2，相關細節在后面有詳細描述。
3：內核在新進程的堆棧中設置一些標記-值對，以指示動態連接器的相關操作。
4：內核把控制傳遞給動態連接器。
5：動態連接器檢查程序對外部文件（共享庫）的依賴性，并在需要時對其進行加載。
6：動態連接器對程序的外部引用進行重定位，通俗的講，就是告訴程序其引用的外部變量/函數的地址，此地址位于共享庫被加載在內存的區間內。動態連接還有一個延遲（Lazy）定位的特性，即只在"真正"需要引用符號時才重定位，這對提高程序運行效率有極大幫助。
7：動態連接器執行在ELF文件中標記為 .init 的節的代碼，進行程序運行的初始化。在早期系統中，初始化代碼對應函數 _init(void)(函數名強制固定)，在現代系統中，則對應形式為
void
__attribute((constructor))
init_function(void)
{
……
}
其中函數名為任意。
8：動態連接器把控制傳遞給程序，從 ELF 文件頭部中定義的程序進入點開始執行。在 a.out 格式和ELF格式中，程序進入點的值是顯式存在的，在 COFF 格式中則是由規范隱含定義。
從上面的描述可以看出，加載文件最重要的是完成兩件事情：加載程序段和數據段到內存；進行外部定義符號的重定位。重定位是程序連接中一個重要概念。我們知道，一個可執行程序通常是由一個含有 main() 的主程序文件、若干目標文件、若干共享庫（Shared Libraries）組成。（注：采用一些特別的技巧，也可編寫沒有 main 函數的程序，請參閱 參考資料 2）一個 C 程序可能引用共享庫定義的變量或函數，換句話說就是程序運行時必須知道這些變量/函數的地址。在靜態連接中，程序所有需要使用的外部定義都完全包含在可執行程序中，而動態連接則只在可執行文件中設置相關外部定義的一些引用信息，真正的重定位是在程序運行之時。靜態連接方式有兩個大問題：如果庫中變量或函數有任何變化都必須重新編譯連接程序；如果多個程序引用同樣的變量/函數，則此變量/函數會在文件/內存中出現多次，浪費硬盤/內存空間。比較兩種連接方式生成的可執行文件的大小，可以看出有明顯的區別。


a.out 文件格式分析
a.out 格式在不同的機器平臺和不同的 UNIX 操作系統上有輕微的不同，例如在 MC680x0 平臺上有 6 個 section。下面我們討論的是最"標準"的格式。
a.out 文件包含 7 個 section，格式如下：
exec header（執行頭部，也可理解為文件頭部）
text segment（文本段）
data segment(數據段)
text relocations(文本重定位段)
data relocations（數據重定位段）
symbol table（符號表）
string table（字符串表）
執行頭部的數據結構：
struct exec {
? ? ? ? unsigned long ? a_midmag; ? ?/* 魔數和其它信息 */
? ? ? ? unsigned long ? a_text; ? ? ?/* 文本段的長度 */
? ? ? ? unsigned long ? a_data; ? ? ?/* 數據段的長度 */
? ? ? ? unsigned long ? a_bss; ? ? ? /* BSS段的長度 */
? ? ? ? unsigned long ? a_syms; ? ? ?/* 符號表的長度 */
? ? ? ? unsigned long ? a_entry; ? ? /* 程序進入點 */
? ? ? ? unsigned long ? a_trsize; ? ?/* 文本重定位表的長度 */
? ? ? ? unsigned long ? a_drsize; ? ?/* 數據重定位表的長度 */
};
文件頭部主要描述了各個 section 的長度，比較重要的字段是 a_entry（程序進入點），代表了系統在加載程序并初試化各種環境后開始執行程序代碼的入口。這個字段在后面討論的 ELF 文件頭部中也有出現。由 a.out 格式和頭部數據結構我們可以看出，a.out 的格式非常緊湊，只包含了程序運行所必須的信息（文本、數據、BSS），而且每個 section 的順序是固定的。這種結構缺乏擴展性，如不能包含"現代"可執行文件中常見的調試信息，最初的 UNIX 黑客對 a.out 文件調試使用的工具是 adb，而 adb 是一種機器語言調試器！
a.out 文件中包含符號表和兩個重定位表，這三個表的內容在連接目標文件以生成可執行文件時起作用。在最終可執行的 a.out 文件中，這三個表的長度都為 0。a.out 文件在連接時就把所有外部定義包含在可執行程序中，如果從程序設計的角度來看，這是一種硬編碼方式，或者可稱為模塊之間是強藕和的。在后面的討論中，我們將會具體看到ELF格式和動態連接機制是如何對此進行改進的。
a.out 是早期UNIX系統使用的可執行文件格式，由 AT&T 設計，現在基本上已被 ELF 文件格式代替。a.out 的設計比較簡單，但其設計思想明顯的被后續的可執行文件格式所繼承和發揚。可以參閱 參考資料 16 和閱讀 參考資料 15 源代碼加深對 a.out 格式的理解。 參考資料 12 討論了如何在"現代"的紅帽LINUX運行 a.out 格式文件。


COFF 文件格式分析
COFF 格式比 a.out 格式要復雜一些，最重要的是包含一個節段表(section table)，因此除了 .text，.data，和 .bss 區段以外，還可以包含其它的區段。另外也多了一個可選的頭部，不同的操作系統可一對此頭部做特定的定義。
COFF 文件格式如下：
File Header(文件頭部)
Optional Header(可選文件頭部)
Section 1 Header(節頭部)
………
Section n Header(節頭部)
Raw Data for Section 1(節數據)
Raw Data for Section n(節數據)
Relocation Info for Sect. 1(節重定位數據)
Relocation Info for Sect. n(節重定位數據)
Line Numbers for Sect. 1(節行號數據)
Line Numbers for Sect. n(節行號數據)
Symbol table(符號表)
String table(字符串表)
文件頭部的數據結構：
struct filehdr
? ?{
? ? unsigned short ?f_magic; ? ?/* 魔數 */
? ? ? ?unsigned short ?f_nscns; ? ?/* 節個數 */
? ? ? ?long ? ? ? ? ? ?f_timdat; ? /* 文件建立時間 */
? ? ? ?long ? ? ? ? ? ?f_symptr; ? /* 符號表相對文件的偏移量 */
? ? ? ?long ? ? ? ? ? ?f_nsyms; ? ?/* 符號表條目個數 */
? ? ? ?unsigned short ?f_opthdr; ? /* 可選頭部長度 */
? ? ? ?unsigned short ?f_flags; ? ?/* 標志 */
? ?};
COFF 文件頭部中魔數與其它兩種格式的意義不太一樣，它是表示針對的機器類型，例如 0x014c 相對于 I386 平臺，而 0x268 相對于 Motorola 68000系列等。當 COFF 文件為可執行文件時，字段 f_flags 的值為 F_EXEC（0X00002），同時也表示此文件沒有未解析的符號，換句話說，也就是重定位在連接時就已經完成。由此也可以看出，原始的 COFF 格式不支持動態連接。為了解決這個問題以及增加一些新的特性，一些操作系統對 COFF 格式進行了擴展。Microsoft 設計了名為 PE（Portable Executable）的文件格式，主要擴展是在 COFF 文件頭部之上增加了一些專用頭部，具體細節請參閱 參考資料 18，某些 UNIX 系統也對 COFF 格式進行了擴展，如 XCOFF（extended common object file format）格式，支持動態連接，請參閱 參考資料 5。
緊接文件頭部的是可選頭部，COFF 文件格式規范中規定可選頭部的長度可以為 0，但在 LINUX 系統下可選頭部是必須存在的。下面是 LINUX 下可選頭部的數據結構：
typedef struct?
{
? char ? magic[2]; /* 魔數 */
? char ? vstamp[2]; /* 版本號 */
? char ? tsize[4]; /* 文本段長度 */
? char ? dsize[4]; /* 已初始化數據段長度 */
? char ? bsize[4]; /* 未初始化數據段長度 */
? char ? entry[4]; /* 程序進入點 */
? char ? text_start[4]; ? ? ? /* 文本段基地址 */
? char ? data_start[4]; ? ? ? /* 數據段基地址 */
}
COFF_AOUTHDR;
字段 magic 為 0413 時表示 COFF 文件是可執行的，注意到可選頭部中顯式定義了程序進入點，標準的 COFF 文件沒有明確的定義程序進入點的值，通常是從 .text 節開始執行，但這種設計并不好。
前面我們提到，COFF 格式比 a.out 格式多了一個節段表，一個節頭條目描述一個節數據的細節，因此 COFF 格式能包含更多的節，或者說可以根據實際需要，增加特定的節，具體表現在 COFF 格式本身的定義以及稍早提及的 COFF 格式擴展。我個人認為，節段表的出現可能是 COFF 格式相對 a.out 格式最大的進步。下面我們將簡單描述 COFF 文件中節的數據結構，因為節的意義更多體現在程序的編譯和連接上，所以本文不對其做更多的描述。此外，ELF 格式和 COFF格式對節的定義非常相似，在隨后的 ELF 格式分析中，我們將省略相關討論。
struct COFF_scnhdr?
{
? char s_name[8]; /* 節名稱 */
? char s_paddr[4]; /* 物理地址 */
? char s_vaddr[4]; /* 虛擬地址 */
? char s_size[4]; /* 節長度 */
? char s_scnptr[4]; /* 節數據相對文件的偏移量 */
? char s_relptr[4]; /* 節重定位信息偏移量 */
? char s_lnnoptr[4]; /* 節行信息偏移量 */
? char s_nreloc[2]; /* 節重定位條目數 */
? char s_nlnno[2]; /* 節行信息條目數 */
? char s_flags[4]; /* 段標記 */
};
有一點需要注意：LINUX系統中頭文件coff.h中對字段s_paddr的注釋是"physical address"，但似乎應該理解為"節被加載到內存中所占用的空間長度"。字段s_flags標記該節的類型，如文本段、數據段、BSS段等。在COFF的節中也出現了行信息，行信息描述了二進制代碼與源代碼的行號之間的對映關系，在調試時很有用。
參考資料 19是一份對COFF格式詳細描述的中文資料，更詳細的內容請參閱 參考資料 20。


ELF文件格式分析
ELF文件有三種類型： 可重定位文件：也就是通常稱的目標文件，后綴為.o。 共享文件：也就是通常稱的庫文件，后綴為.so。 可執行文件：本文主要討論的文件格式，總的來說，可執行文件的格式與上述兩種文件的格式之間的區別主要在于觀察的角度不同：一種稱為連接視圖（Linking View），一種稱為執行視圖（Execution View）。
首先看看ELF文件的總體布局：
ELF header(ELF頭部)
Program header table(程序頭表)
Segment1（段1）
Segment2（段2）
………
Sengmentn（段n）
Setion header table(節頭表，可選)
段由若干個節(Section)構成,節頭表對每一個節的信息有相關描述。對可執行程序而言，節頭表是可選的。 參考資料 1中作者談到把節頭表的所有數據全部設置為0，程序也能正確運行！ELF頭部是一個關于本文件的路線圖（road map），從總體上描述文件的結構。下面是ELF頭部的數據結構：
typedef 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; ? ? ? ? ? ? ? /* ELF頭部長度 */
? Elf32_Half ? ?e_phentsize; ? ? ? ? ? ?/* 程序頭部中一個條目的長度 */
? Elf32_Half ? ?e_phnum; ? ? ? ? ? ? ? ?/* 程序頭部條目個數 ?*/
? Elf32_Half ? ?e_shentsize; ? ? ? ? ? ?/* 節頭部中一個條目的長度 */
? Elf32_Half ? ?e_shnum; ? ? ? ? ? ? ? ?/* 節頭部條目個數 */
? Elf32_Half ? ?e_shstrndx; ? ? ? ? ? ? /* 節頭部字符表索引 */
} Elf32_Ehdr;
下面我們對ELF頭表中一些重要的字段作出相關說明，完整的ELF定義請參閱 參考資料6和 參考資料 7。
e_ident[0]-e_ident[3]包含了ELF文件的魔數，依次是0x7f、'E'、'L'、'F'。注意，任何一個ELF文件必須包含此魔數。 參考資料 3中討論了利用程序、工具、/Proc文件系統等多種查看ELF魔數的方法。e_ident[4]表示硬件系統的位數，1代表32位，2代表64位。e_ident[5]表示數據編碼方式，1代表小印第安排序（最大有意義的字節占有最低的地址），2代表大印第安排序（最大有意義的字節占有最高的地址）。e_ident[6]指定ELF頭部的版本，當前必須為1。e_ident[7]到e_ident[14]是填充符，通常是0。ELF格式規范中定義這幾個字節是被忽略的，但實際上是這幾個字節完全可以可被利用。如病毒Lin/Glaurung.676/666（ 參考資料 1）設置e_ident[7]為0x21,表示本文件已被感染；或者存放可執行代碼（ 參考資料 2）。ELF頭部中大多數字段都是對子頭部數據的描述，其意義相對比較簡單。值得注意的是某些病毒可能修改字段e_entry（程序進入點）的值，以指向病毒代碼，例如上面提到的病毒Lin/Glaurung.676/666。
一個實際可執行文件的文件頭部形式如下：（利用命令readelf）
? 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: ? ? ? ? ? ? ? 0x80483cc
? Start of program headers: ? ? ? ? ?52 (bytes into file)
? Start of section headers: ? ? ? ? ?14936 (bytes into file)
? Flags: ? ? ? ? ? ? ? ? ? ? ? ? ? ? 0x0
? Size of this header: ? ? ? ? ? ? ? 52 (bytes)
? Size of program headers: ? ? ? ? ? 32 (bytes)
? Number of program headers: ? ? ? ? 6
? Size of section headers: ? ? ? ? ? 40 (bytes)
? Number of section headers: ? ? ? ? 34
? Section header string table index: 31
緊接ELF頭部的是程序頭表，它是一個結構數組，包含了ELF頭表中字段e_phnum定義的條目，結構描述一個段或其他系統準備執行該程序所需要的信息。
typedef struct {
? ? ? Elf32_Word ?p_type; /* 段類型 */
? ? ? Elf32_Off ? p_offset; ? ? /* 段位置相對于文件開始處的偏移量 */
? ? ? Elf32_Addr ?p_vaddr; ? /* 段在內存中的地址 */
? ? ? Elf32_Addr ?p_paddr; ? /* 段的物理地址 */
? ? ? Elf32_Word ?p_filesz; /* 段在文件中的長度 */
? ? ? Elf32_Word ?p_memsz; /* 段在內存中的長度 */
? ? ? Elf32_Word ?p_flags; /* 段的標記 */
? ? ? Elf32_Word ?p_align; /* 段在內存中對齊標記 */
? } Elf32_Phdr;
在詳細討論可執行文件程序頭表之前，首先查看一個實際文件的輸出：
? Program Headers:
Type ? ? ? ? ? Offset ? VirtAddr ? PhysAddr ? FileSiz MemSiz ?Flg Align
PHDR ? ? ? ? ? 0x000034 0x08048034 0x08048034 0x000c0 0x000c0 R E 0x4
INTERP ? ? ? ? 0x0000f4 0x080480f4 0x080480f4 0x00013 0x00013 R ? 0x1
? ? ? [Requesting program interpreter: /lib/ld-linux.so.2]
? LOAD ? ? ? ? ? 0x000000 0x08048000 0x08048000 0x00684 0x00684 R E 0x1000
? LOAD ? ? ? ? ? 0x000684 0x08049684 0x08049684 0x00118 0x00130 RW ?0x1000
? DYNAMIC ? ? ? ?0x000690 0x08049690 0x08049690 0x000c8 0x000c8 RW ?0x4
? NOTE ? ? ? ? ? 0x000108 0x08048108 0x08048108 0x00020 0x00020 R ? 0x4
? Section to Segment mapping:
? Segment Sections...
? ?00 ? ??
? ?01 ? ? .interp?
? ?02 ? ? .interp .note.ABI-tag .hash .dynsym .dynstr .gnu.version?
? ? ? ? ? ?.gnu.version_r .rel.dyn .rel.plt .init .plt .text .fini .rodata .eh_frame?
? ?03 ? ? .data .dynamic .ctors .dtors .jcr .got .bss?
? ?04 ? ? .dynamic?
05 ? ? .note.ABI-tag
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 ? ? ? ?080480f4 0000f4 000013 00 ? A ?0 ? 0 ?1
? [ 2] .note.ABI-tag ? ? NOTE ? ? ? ? ? ?08048108 000108 000020 00 ? A ?0 ? 0 ?4
? [ 3] .hash ? ? ? ? ? ? HASH ? ? ? ? ? ?08048128 000128 000040 04 ? A ?4 ? 0 ?4
? [ 4] .dynsym ? ? ? ? ? DYNSYM ? ? ? ? ?08048168 000168 0000b0 10 ? A ?5 ? 1 ?4
? [ 5] .dynstr ? ? ? ? ? STRTAB ? ? ? ? ?08048218 000218 00007b 00 ? A ?0 ? 0 ?1
? [ 6] .gnu.version ? ? ?VERSYM ? ? ? ? ?08048294 000294 000016 02 ? A ?4 ? 0 ?2
? [ 7] .gnu.version_r ? ?VERNEED ? ? ? ? 080482ac 0002ac 000030 00 ? A ?5 ? 1 ?4
? [ 8] .rel.dyn ? ? ? ? ?REL ? ? ? ? ? ? 080482dc 0002dc 000008 08 ? A ?4 ? 0 ?4
? [ 9] .rel.plt ? ? ? ? ?REL ? ? ? ? ? ? 080482e4 0002e4 000040 08 ? A ?4 ? b ?4
? [10] .init ? ? ? ? ? ? PROGBITS ? ? ? ?08048324 000324 000017 00 ?AX ?0 ? 0 ?4
? [11] .plt ? ? ? ? ? ? ?PROGBITS ? ? ? ?0804833c 00033c 000090 04 ?AX ?0 ? 0 ?4
? [12] .text ? ? ? ? ? ? PROGBITS ? ? ? ?080483cc 0003cc 0001f8 00 ?AX ?0 ? 0 ?4
? [13] .fini ? ? ? ? ? ? PROGBITS ? ? ? ?080485c4 0005c4 00001b 00 ?AX ?0 ? 0 ?4
? [14] .rodata ? ? ? ? ? PROGBITS ? ? ? ?080485e0 0005e0 00009f 00 ? A ?0 ? 0 32
? [15] .eh_frame ? ? ? ? PROGBITS ? ? ? ?08048680 000680 000004 00 ? A ?0 ? 0 ?4
? [16] .data ? ? ? ? ? ? PROGBITS ? ? ? ?08049684 000684 00000c 00 ?WA ?0 ? 0 ?4
? [17] .dynamic ? ? ? ? ?DYNAMIC ? ? ? ? 08049690 000690 0000c8 08 ?WA ?5 ? 0 ?4
? [18] .ctors ? ? ? ? ? ?PROGBITS ? ? ? ?08049758 000758 000008 00 ?WA ?0 ? 0 ?4
? [19] .dtors ? ? ? ? ? ?PROGBITS ? ? ? ?08049760 000760 000008 00 ?WA ?0 ? 0 ?4
? [20] .jcr ? ? ? ? ? ? ?PROGBITS ? ? ? ?08049768 000768 000004 00 ?WA ?0 ? 0 ?4
? [21] .got ? ? ? ? ? ? ?PROGBITS ? ? ? ?0804976c 00076c 000030 04 ?WA ?0 ? 0 ?4
? [22] .bss ? ? ? ? ? ? ?NOBITS ? ? ? ? ?0804979c 00079c 000018 00 ?WA ?0 ? 0 ?4
? [23] .comment ? ? ? ? ?PROGBITS ? ? ? ?00000000 00079c 000132 00 ? ? ?0 ? 0 ?1
? [24] .debug_aranges ? ?PROGBITS ? ? ? ?00000000 0008d0 000098 00 ? ? ?0 ? 0 ?8
? [25] .debug_pubnames ? PROGBITS ? ? ? ?00000000 000968 000040 00 ? ? ?0 ? 0 ?1
? [26] .debug_info ? ? ? PROGBITS ? ? ? ?00000000 0009a8 001cc6 00 ? ? ?0 ? 0 ?1
? [27] .debug_abbrev ? ? PROGBITS ? ? ? ?00000000 00266e 0002cc 00 ? ? ?0 ? 0 ?1
? [28] .debug_line ? ? ? PROGBITS ? ? ? ?00000000 00293a 0003dc 00 ? ? ?0 ? 0 ?1
? [29] .debug_frame ? ? ?PROGBITS ? ? ? ?00000000 002d18 000048 00 ? ? ?0 ? 0 ?4
? [30] .debug_str ? ? ? ?PROGBITS ? ? ? ?00000000 002d60 000bcd 01 ?MS ?0 ? 0 ?1
? [31] .shstrtab ? ? ? ? STRTAB ? ? ? ? ?00000000 00392d 00012b 00 ? ? ?0 ? 0 ?1
? [32] .symtab ? ? ? ? ? SYMTAB ? ? ? ? ?00000000 003fa8 000740 10 ? ? 33 ?56 ?4
? [33] .strtab ? ? ? ? ? STRTAB ? ? ? ? ?00000000 0046e8 000467 00 ? ? ?0 ? 0 ?1
對一個ELF可執行程序而言，一個基本的段是標記p_type為PT_INTERP的段，它表明了運行此程序所需要的程序解釋器（/lib/ld-linux.so.2），實際上也就是動態連接器（dynamic linker）。最重要的段是標記p_type為PT_LOAD的段，它表明了為運行程序而需要加載到內存的數據。查看上面實際輸入，可以看見有兩個可LOAD段，第一個為只讀可執行（FLg為R E）,第二個為可讀可寫（Flg為RW）。段1包含了文本節.text，注意到ELF文件頭部中程序進入點的值為0x80483cc，正好是指向節.text在內存中的地址。段二包含了數據節.data，此數據節中數據是可讀可寫的，相對的只讀數據節.rodata包含在段1中。ELF格式可以比COFF格式包含更多的調試信息，如上面所列出的形式為.debug_xxx的節。在I386平臺LINUX系統下，用命令file查看一個ELF可執行程序的可能輸出是：a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped。
ELF文件中包含了動態連接器的全路徑，內核定位"正確"的動態連接器在內存中的地址是"正確"運行可執行文件的保證， 參考資料 13討論了如何通過查找動態連接器在內存中的地址以達到顛覆（Subversiver）動態連接機制的方法。
最后我們討論ELF文件的動態連接機制。每一個外部定義的符號在全局偏移表(Global Offset Table GOT)中有相應的條目,如果符號是函數則在過程連接表(Procedure Linkage Table PLT)中也有相應的條目，且一個PLT條目對應一個GOT條目。對外部定義函數解析可能是整個ELF文件規范中最復雜的，下面是函數符號解析過程的一個描述。
1：代碼中調用外部函數func,語句形式為call 0xaabbccdd,地址0xaabbccdd實際上就是符號func在PLT表中對應的條目地址（假設地址為標號.PLT2）。
2：PLT表的形式如下
? ? ? ? ? .PLT0: pushl ? 4(%ebx) ? ?/* GOT表的地址保存在寄存器ebx中 */
jmp ? ? *8(%ebx)
? ? ? ? ? nop; nop
? ? ? ? ? nop; nop
? .PLT1: jmp ? ? *name1@GOT(%ebx)
? ? ? ? ? pushl ? $offset
? ? ? ? ? jmp ? ? .PLT0@PC
? .PLT2: jmp ? ? *func@GOT(%ebx)
? ? ? ? ? pushl ? $offset
? ? ? ? ? jmp ? ? .PLT0@PC
3：查看標號.PLT2的語句,實際上是跳轉到符號func在GOT表中對應的條目。
4：在符號沒有重定位前，GOT表中此符號對應的地址為標號.PLT2的下一條語句，即是pushl $offset，其中$offset是符號func的重定位偏移量。注意到這是一個二次跳轉。
5：在符號func的重定位偏移量壓棧后,控制跳到PLT表的第一條目，把GOT[1]的內容壓棧，并跳轉到GOT[2]對應的地址。
6：GOT[2]對應的實際上是動態符號解析函數的代碼，在對符號func的地址解析后，會把func在內存中的地址設置到GOT表中此符號對應的條目中。
7：當第二次調用此符號時，GOT表中對應的條目已經包含了此符號的地址，就可直接調用而不需要利用PLT表進行跳轉。
動態連接是比較復雜的，但為了獲得靈活性的代價通常就是復雜性。其最終目的是把GOT表中條目的值修改為符號的真實地址，這也可解釋節.got包含在可讀可寫段中。
動態連接是一個非常重要的進步，這意味著庫文件可以被升級、移動到其他目錄等等而不需要重新編譯程序（當然，這不意味庫可以任意修改，如函數入參的個數、數據類型應保持兼容性）。從很大程度上說，動態連接機制是ELF格式代替a.out格式的決定性原因。如果說面對對象的編程本質是面對接口（interface）的編程，那么動態連接機制則是這種思想的地一個非常典型的應用，具體的講，動態連接機制與設計模式中的橋接（BRIDGE）方法比較類似，而它的LAZY特性則與代理（PROXY）方法非常相似。動態連接操作的細節描述請參閱 參考資料 8，9，10，11。通過閱讀命令readelf、objdump 的源代碼以及 參考資料 14中所提及的相關軟件源代碼，可以對ELF文件的格式有更徹底的了解。


總結
不同時期的可執行文件格式深刻的反映了技術進步的過程，技術進步通常是針對解決存在的問題和適應新的環境。早期的UNIX系統使用a.out格式，隨著操作系統和硬件系統的進步，a.out格式的局限性越來越明顯。新的可執行文件格式COFF在UNIX System VR3中出現，COFF格式相對a.out格式最大變化是多了一個節頭表（section head table），能夠在包含基礎的文本段、數據段、BSS段之外包含更多的段，但是COFF對動態連接和C++程序的支持仍然比較困難。為了解決上述問題，UNIX系統實驗室(UNIX SYSTEM Laboratories USL) 開發出ELF文件格式，它被作為應用程序二進制接口（Application binary Interface ABI）的一部分，其目的是替代傳統的a.out格式。例如，ELF文件格式中引入初始化段.init和結束段.fini（分別對應構造函數和析構函數）則主要是為了支持C++程序。1994年6月ELF格式出現在LINUX系統上，現在ELF格式作為UNIX/LINUX最主要的可執行文件格式。當然我們完全有理由相信，在將來還會有新的可執行文件格式出現。
上述三種可執行文件格式都很好的體現了設計思想中分層的概念，由一個總的頭部刻畫了文件的基本要素，再由若干子頭部/條目刻畫了文件的若干細節。比較一下可執行文件格式和以太數據包中以太頭、IP頭、TCP頭的設計，我想我們能很好的感受分層這一重要的設計思想。 參考資料 21從全局的角度討論了各種文件的格式，并提出一個比較夸張的結論：Everything Is Byte!

總結

以上是生活随笔為你收集整理的Linux 系统编程的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。