PE文件格式詳解(下)

預定義段 

 一個Windows NT的應用程序典型地擁有9個預定義段，它們是.text、.bss、.rdata、.data、.rsrc、.edata、.idata、.pdata和.debug。一些應用程序不需要所有的這些段，同樣還有一些應用程序爲了自己特殊的需要而定義了更多的段。這種做法與MS-DOS和Windows 3.1中的代碼段和數據段相似。事實上，應用程序定義一個獨特的段的方法是使用標準編譯器來指示對代碼段和數據段的命名，或者使用名稱段編譯器選項-NT――就和Windows 3.1中應用程序定義獨特的代碼段和數據段一樣。 

以下是一個關於Windows NT PE文件之中一些有趣的公共段的討論。

可執行代碼段，.text 

Windows 3.1和Windows NT之間的一個區別就是Windows NT默認的做法是將所有的代碼段（正如它們在Windows 3.1中所提到的那樣）組成了一個單獨的段，名爲“.text”。既然Windows NT使用了基於頁面的虛擬內存管理系統，那麼將分開的代碼放入不同的段之中的做法就不太明智了。因此，擁有一個大的代碼段對於操作系統和應用程序開發者來說，都是十分方便的。

.text段也包含了早先提到過的入口點。IAT亦存在於.text段之中的模塊入口點之前。（IAT在.text段之中的存在非常有意義，因爲這個表事實上是一系列的跳轉指令，並且它們的跳轉目標位置是已固定的地址。）當Windows NT的可執行映像裝載入進程的地址空間時，IAT就和每一個導入函數的物理地址一同確定了。要在.text段之中查找IAT，裝載器只用將模塊的入口點定位，而IAT恰恰出現於入口點之前。既然每個入口擁有相同的尺寸，那麼向後退查找這個表的起始位置就很容易了。

數據段，.bss、.rdata、.data

.bss段表示應用程序的未初始化數據，包括所有函數或源模塊中聲明爲static的變量。

.rdata段表示只讀的數據，比如字符串文字量、常量和調試目錄信息。

所有其它變量（除了出現在棧上的自動變量）存儲在.data段之中。基本上，這些是應用程序或模塊的全局變量。

資源段，.rsrc

.rsrc段包含了模塊的資源信息。它起始於一個資源目錄結構，這個結構就像其它大多數結構一樣，但是它的數據被更進一步地組織在了一棵資源樹之中。以下的IMAGE_RESOURCE_DIRECTORY結構形成了這棵樹的根和各個結點。

01.//WINNT.H

02. 

03.typedef struct _IMAGE_RESOURCE_DIRECTORY {

04.ULONG Characteristics;

05.ULONG TimeDateStamp;

06.USHORT MajorVersion;

07.USHORT MinorVersion;

08.USHORT NumberOfNamedEntries;

09.USHORT NumberOfIdEntries;

10.} IMAGE_RESOURCE_DIRECTORY, *PIMAGE_RESOURCE_DIRECTORY;

11.　　

請看這個目錄結構，你將會發現其中竟然沒有指向下一個結點的指針。但是，在這個結構中有兩個域NumberOfNamedEntries和NumberOfIdEntries代替了指針，它們被用來表示這個目錄附有多少入口。附帶說一句，我的意思是目錄入口就在段數據之中的目錄後邊。有名稱的入口按字母升序出現，再往後是按數值升序排列的ID入口。

一個目錄入口由兩個域組成，正如下面IMAGE_RESOURCE_DIRECTORY_ENTRY結構所描述的那樣：

1.// WINNT.H

2. 

3.typedef struct _IMAGE_RESOURCE_DIRECTORY_ENTRY {

4.ULONG Name;

5.ULONG OffsetToData;

6.} IMAGE_RESOURCE_DIRECTORY_ENTRY, *PIMAGE_RESOURCE_DIRECTORY_ENTRY;

根據樹的層級不同，這兩個域也就有着不同的用途。Name域被用於標識一個資源種類，或者一種資源名稱，或者一個資源的語言ID。OffsetToData與常常被用來在樹之中指向兄弟結點――即一個目錄結點或一個葉子結點。

葉子結點是資源樹之中最底層的結點，它們定義了當前資源數據的尺寸和位置。IMAGE_RESOURCE_DATA_ENTRY結構被用於描述每個葉子結點：

1.// WINNT.H

2. 

3.typedef struct _IMAGE_RESOURCE_DATA_ENTRY {

4.ULONG OffsetToData;

5.ULONG Size;

6.ULONG CodePage;

7.ULONG Reserved;

8.} IMAGE_RESOURCE_DATA_ENTRY, *PIMAGE_RESOURCE_DATA_ENTRY;

OffsetToData和Size這兩個域表示了當前資源數據的位置和尺寸。既然這一信息主要是在應用程序裝載以後由函數使用的，那麼將OffsetToData作爲一個相對虛擬的地址會更有意義一些。――幸甚，恰好是這樣沒錯。非常有趣的是，所有其它的偏移量，比如從目錄入口到其它目錄的指針，都是相對於根結點位置的偏移量。

要更清楚地瞭解這些內容，請參考圖2。

圖2.一個簡單的資源樹結構

圖2描述了一個非常簡單的資源樹，它包含了僅僅兩個資源對象：一個菜單和一個字串表。更深一層地來說，它們各自都有一個子項。然而，你仍然可以看到資源樹有多麼複雜――即使它像這個一樣只有一點點資源。

在樹的根部，第一個目錄有一個文件中包含的所有資源種類的入口，而不管資源種類有多少。在圖2中，有兩個由樹根標識的入口，一個是菜單的，另一個是字串表的。如果文件中擁有一個或多個對話框資源，那麼根結點會再擁有一個入口，因此，就有了對話框資源的另一個分支。

WINUSER.H中標識了基本的資源種類，我將它們列到了下面：

01.//WINUSER.H

02. 

03./*

04.* 預定義的資源種類

05.*/

06.#define RT_CURSOR MAKEINTRESOURCE(1)

07.#define RT_BITMAP MAKEINTRESOURCE(2)

08.#define RT_ICON MAKEINTRESOURCE(3)

09.#define RT_MENU MAKEINTRESOURCE(4)

10.#define RT_DIALOG MAKEINTRESOURCE(5)

11.#define RT_STRING MAKEINTRESOURCE(6)

12.#define RT_FONTDIR MAKEINTRESOURCE(7)

13.#define RT_FONT MAKEINTRESOURCE(8)

14.#define RT_ACCELERATOR MAKEINTRESOURCE(9)

15.#define RT_RCDATA MAKEINTRESOURCE(10)

16.#define RT_MESSAGETABLE MAKEINTRESOURCE(11)

17.　　

在樹的第一層級，以上列出的MAKEINTRESOURCE值被放置在每個種類入口的Name處，它標識了不同的資源種類。

每個根目錄的入口都指向了樹中第二層級的一個兄弟結點，這些結點也是目錄，並且每個都擁有它們自己的入口。在這一層級，目錄被用來以給定的種類標識每一個資源種類。如果你的應用程序中有多個菜單，那麼樹中的第二層級會爲每個菜單都準備一個入口。

你可能意識到了，資源可以由名稱或整數標識。在這一層級，它們是通過目錄結構的Name域來分辨的。如果如果Name域最重要的位被設置了，那麼其它的31個位就會被用作一個到IMAGE_RESOURCE_DIR_STRING_U結構的偏移量。

1.// WINNT.H

2. 

3.typedef struct _IMAGE_RESOURCE_DIR_STRING_U {

4.USHORT Length;

5.WCHAR NameString[1];

6.} IMAGE_RESOURCE_DIR_STRING_U, *PIMAGE_RESOURCE_DIR_STRING_U;

7.　　

這個結構僅僅是由一個2字節長的Length域和一個UNICODE字符Length組成的。

另一方面，如果Name域最重要的位被清空，那麼它的低31位就被用於表示資源的整數ID。圖2示範的就是菜單資源作爲一個命名的資源，以及字串表作爲一個ID資源。

如果有兩個菜單資源，一個由名稱標識，另一個由資源標識，那麼它們二者就會在菜單資源目錄之後擁有兩個入口。有名稱的資源入口在第一位，之後是由整數標識的資源。目錄域NumberOfNamedEntries和NumberOfIdEntries將各自包含值1，表示當前的1個入口。

在第二層級的下面，資源樹就不再更深一步地擴展分支了。第一層級分支至表示每個資源種類的目錄中，第二層級分支至由標識符表示的每個資源的目錄中，第三層級是被個別標識的資源與它們各自的語言ID之間一對一的映射。要表示一個資源的語言ID，目錄入口結構的Name域就被用來表示資源的主語言ID和子語言ID了。Windows NT的Win32 SDK開發包中列出了默認的值資源，例如對於0x0409這個值來說，0x09表示主語言LANG_ENGLISH，0x04則被定義爲子語言的SUBLANG_ENGLISH_CAN。所有的語言ID值都定義於Windows NT Win32 SDK開發包的文件WINNT.H中。

既然語言ID結點是樹中最後的目錄結點，那麼入口結構的OffsetToData域就是到一個葉子結點（即前面提到過的IMAGE_RESOURCE_DATA_ENTRY結構）的偏移量。

再回過頭來參考圖2，你會發現每個語言目錄入口都對應着一個數據入口。這個結點僅僅表示了資源數據的尺寸以及資源數據的相對虛擬地址。

在資源數據段（.rsrc）之中擁有這麼多結構有一個好處，就是你可以不存取資源本身而直接可以從這個段收集很多信息。例如，你可以獲得有多少種資源、哪些資源（如果有的話）使用了特別的語言ID、特定的資源是否存在以及單獨種類資源的尺寸。爲了示範如何利用這一信息，以下的函數說明了如何決定一個文件中包含的不同種類的資源：

01.// PEFILE.C

02. 

03.int WINAPI GetListOfResourceTypes(LPVOID lpFile, HANDLE hHeap, char**pszResTypes)

04.{

05.PIMAGE_RESOURCE_DIRECTORY prdRoot;

06.PIMAGE_RESOURCE_DIRECTORY_ENTRY prde;

07.char *pMem;

08.int nCnt, i;

09./* 獲得資源樹的根目錄 */

10.if ((prdRoot = (PIMAGE_RESOURCE_DIRECTORY)ImageDirectoryOffset

11.(lpFile, IMAGE_DIRECTORY_ENTRY_RESOURCE)) == NULL)

12.return 0;

13./* 在堆上分配足夠的空間來包括所有類型 */

14.nCnt = prdRoot->NumberOfIdEntries * (MAXRESOURCENAME + 1);

15.*pszResTypes = (char *)HeapAlloc(hHeap, HEAP_ZERO_MEMORY,

16.nCnt);

17.if ((pMem = *pszResTypes) == NULL)

18.return 0;

19./* 將指針指向第一個資源種類的入口 */

20.prde = (PIMAGE_RESOURCE_DIRECTORY_ENTRY)((DWORD)prdRoot +

21.sizeof (IMAGE_RESOURCE_DIRECTORY));

22./* 在所有的資源目錄入口類型中循環 */

23.for (i = 0; i < prdRoot->NumberOfIdEntries; i++)

24.{

25.if (LoadString(hDll, prde->Name, pMem, MAXRESOURCENAME))

26.pMem += strlen(pMem) + 1;

27.prde++;

28.}

29.return nCnt;

30.}

31.　　

這個函數將一個資源種類名稱的列表寫入了由pszResTypes標識的變量中。請注意，在這個函數的核心部分，LoadString是使用各自資源種類目錄入口的Name域來作爲字符串ID的。如果你查看PEFILE.RC，你會發現我定義了一系列的資源種類的字符串，並且它們的ID與它們在目錄入口中的定義完全相同。PEFILE.DLL還有有一個函數，它返回了.rsrc段中的資源對象總數。這樣一來，從這個段中提取其它的信息，藉助這些函數或另外編寫函數就方便多了。

導出數據段，.edata

.edata段包含了應用程序或DLL的導出數據。在這個段出現的時候，它會包含一個到達導出信息的導出目錄。

01.// WINNT.H

02. 

03.typedef struct _IMAGE_EXPORT_DIRECTORY {

04.ULONG Characteristics;

05.ULONG TimeDateStamp;

06.USHORT MajorVersion;

07.USHORT MinorVersion;

08.ULONG Name;

09.ULONG Base;

10.ULONG NumberOfFunctions;

11.ULONG NumberOfNames;

12.PULONG *AddressOfFunctions;

13.PULONG *AddressOfNames;

14.PUSHORT *AddressOfNameOrdinals;

15.} IMAGE_EXPORT_DIRECTORY, *PIMAGE_EXPORT_DIRECTORY;

16.　　

導出目錄中的Name域標識了可執行模塊的名稱。NumberOfFunctions域和NumberOfNames域表示模塊中有多少導出的函數以及這些函數的名稱。

AddressOfFunctions域是一個到導出函數入口列表的偏移量。AddressOfNames域是到一個導出函數名稱列表起始處偏移量的地址，這個列表是由null分隔的。AddressOfNameOrdinals是一個到相同導出函數順序值（每個值2字節長）列表的偏移量。

三個AddressOf...域是當模塊裝載時進程地址空間中的相對虛擬地址。一旦模塊被裝載，那麼要獲得進程地質空間中的確切地址的話，就應該在相對虛擬地址上加上模塊的基地址。可是，在文件被裝載前，仍然可以決定這一地址：只要從給定的域地址中減去段頭部的虛擬地址（VirtualAddress），再加上段實體的偏移量（PointerToRawData），這個結果就是映像文件中的偏移量了。以下的例子解說了這一技術：

01.// PEFILE.C

02. 

03.int WINAPI GetExportFunctionNames(LPVOID lpFile, HANDLE hHeap, char**pszFunctions)

04.{

05.IMAGE_SECTION_HEADER sh;

06.PIMAGE_EXPORT_DIRECTORY ped;

07.char *pNames, *pCnt;

08.int i, nCnt;

09./* 獲得.edata域中的段頭部和指向數據目錄的指針 */

10.if ((ped = (PIMAGE_EXPORT_DIRECTORY)ImageDirectoryOffset

11.(lpFile, IMAGE_DIRECTORY_ENTRY_EXPORT)) == NULL)

12.return 0;

13.GetSectionHdrByName (lpFile, &sh, ".edata");

14./* 決定導出函數名稱的偏移量 */

15.pNames = (char *)(*(int *)((int)ped->AddressOfNames -

16.(int)sh.VirtualAddress + (int)sh.PointerToRawData +

17.(int)lpFile) - (int)sh.VirtualAddress +

18.(int)sh.PointerToRawData + (int)lpFile);

19./* 計算出要爲所有的字符串分配多少內存 */

20.pCnt = pNames;

21.for (i = 0; i < (int)ped->NumberOfNames; i++)

22.while (*pCnt++);

23.nCnt = (int)(pCnt.pNames);

24./* 在堆上爲函數名稱分配內存 */

25.*pszFunctions = HeapAlloc (hHeap, HEAP_ZERO_MEMORY, nCnt);

26./* 將所有字符串複製到緩衝區 */

27.CopyMemory((LPVOID)*pszFunctions, (LPVOID)pNames, nCnt);

28.return nCnt;

29.}

請注意，在這個函數之中，變量pNames是由決定偏移量地址和當前偏移量位置的方法來賦值的。偏移量的地址和偏移量本身都是相對虛擬地址，因此在使用之前必須進行轉換――函數之中體現了這一點。雖然你可以編寫一個類似的函數來決定順序值或函數入口點，但是我爲什麼不爲你做好呢？――GetNumberOfExportedFunctions、GetExportFunctionEntryPoints和GetExportFunctionOrdinals已經存在於PEFILE.DLL之中了。

導入數據段，.idata

.idata段是導入數據，包括導入庫和導入地址名稱表。雖然定義了IMAGE_DIRECTORY_ENTRY_IMPORT，但是WINNT.H之中並無相應的導入目錄結構。作爲代替，其中有若干其它的結構，名爲IMAGE_IMPORT_BY_NAME、IMAGE_THUNK_DATA與IMAGE_IMPORT_DESCRIPTOR。在我個人看來，我實在不知道這些結構是如何和.idata段發生關聯的，所以我花了若干個小時來破譯.idata段實體並且得到了一個更簡單的結構，我名之爲IMAGE_IMPORT_MODULE_DIRECTORY。

01.// PEFILE.H

02. 

03.typedef struct tagImportDirectory

04.{

05.DWORD dwRVAFunctionNameList;

06.DWORD dwUseless1;

07.DWORD dwUseless2;

08.DWORD dwRVAModuleName;

09.DWORD dwRVAFunctionAddressList;

10.} IMAGE_IMPORT_MODULE_DIRECTORY, *PIMAGE_IMPORT_MODULE_DIRECTORY;

和其它段的數據目錄不同的是，這個是作爲文件中的每個導入模塊重複出現的。你可以將它看作模塊數據目錄列表中的一個入口，而不是一個整個數據段的數據目錄。每個入口都是一個指向特定模塊導入信息的目錄。

IMAGE_IMPORT_MODULE_DIRECTORY結構中的一個域dwRVAModuleName是一個相對虛擬地址，它指向模塊的名稱。結構中還有兩個dwUseless參數，它們是爲了保持段的對齊。PE文件格式規範提到了一些東西，關於導入標記、時間/日期標誌以及主/次版本，但是在我的實驗中，這兩個域自始而終都是空的，所以我仍然認爲它們沒有什麼用處。

基於這個結構的定義，你便可以獲得可執行文件中導入的所有模塊和函數名稱了。以下的函數示範瞭如何獲得特定的PE文件中的所有導入函數名稱：

01.//PEFILE.C

02. 

03.int WINAPI GetImportModuleNames(LPVOID lpFile, HANDLE hHeap, char **pszModules)

04.{

05.PIMAGE_IMPORT_MODULE_DIRECTORY pid;

06.IMAGE_SECTION_HEADER idsh;

07.BYTE *pData;

08.int nCnt = 0, nSize = 0, i;

09.char *pModule[1024];

10.char *psz;

11.pid = (PIMAGE_IMPORT_MODULE_DIRECTORY)ImageDirectoryOffset

12.(lpFile, IMAGE_DIRECTORY_ENTRY_IMPORT);

13.pData = (BYTE *)pid;

14./* 定位.idata段頭部 */

15.if (!GetSectionHdrByName(lpFile, &idsh, ".idata"))

16.return 0;

17./* 提取所有導入模塊 */

18.while (pid->dwRVAModuleName)

19.{

20./* 爲絕對字符串偏移量分配緩衝區 */

21.pModule[nCnt] = (char *)(pData +

22.(pid->dwRVAModuleName-idsh.VirtualAddress));

23.nSize += strlen(pModule[nCnt]) + 1;

24./* 增至下一個導入目錄入口 */

25.pid++;

26.nCnt++;

27.}

28./* 將所有字符串賦值到一大塊的堆內存中 */

29.*pszModules = HeapAlloc(hHeap, HEAP_ZERO_MEMORY, nSize);

30.psz = *pszModules;

31.for (i = 0; i < nCnt; i++)

32.{

33.strcpy(psz, pModule[i]);

34.psz += strlen (psz) + 1;

35.}

36.return nCnt;

37.}

這個函數非常好懂，然而有一點值得指出――注意while循環。這個循環當pid->dwRVAModuleName爲0的時候終止，這就暗示了在IMAGE_IMPORT_MODULE_DIRECTORY結構列表的末尾有一個空的結構，這個結構擁有一個0值，至少dwRVAModuleName域爲0。這便是我在對文件的實驗中以及之後在PE文件格式中研究的行爲。

這個結構中的第一個域dwRVAFunctionNameList是一個相對虛擬地址，這個地址指向一個相對虛擬地址的列表，這些地址是文件中的一些文件名。如下面的數據所示，所有導入模塊的模塊和函數名稱都列於.idata段數據中了：

01.E6A7 0000 F6A7 0000 08A8 0000 1AA8 0000 ................

02.28A8 0000 3CA8 0000 4CA8 0000 0000 0000 (...<...L.......

03.0000 4765 744F 7065 6E46 696C 654E 616D ..GetOpenFileNam

04.6541 0000 636F 6D64 6C67 3332 2E64 6C6C eA..comdlg32.dll

05.0000 2500 4372 6561 7465 466F 6E74 496E ..%.CreateFontIn

06.6469 7265 6374 4100 4744 4933 322E 646C directA.GDI32.dl

07.6C00 A000 4765 7444 6576 6963 6543 6170 l...GetDeviceCap

08.7300 C600 4765 7453 746F 636B 4F62 6A65 s...GetStockObje

09.6374 0000 D500 4765 7454 6578 744D 6574 ct....GetTextMet

10.7269 6373 4100 1001 5365 6C65 6374 4F62 ricsA...SelectOb

11.6A65 6374 0000 1601 5365 7442 6B43 6F6C ject....SetBkCol

12.6F72 0000 3501 5365 7454 6578 7443 6F6C or..5.SetTextCol

13.6F72 0000 4501 5465 7874 4F75 7441 0000 or..E.TextOutA..

以上的數據是EXEVIEW.EXE示例程序.idata段的一部分。這個特別的段表示了導入模塊列表和函數名稱列表的起始處。如果你開始檢查數據中的這個段，你應該認出一些熟悉的Win32 API函數以及模塊名稱。從上往下讀的話，你可以找到GetOpenFileNameA，緊接着是COMDLG32.DLL。然後你能發現CreateFontIndirectA，緊接着是模塊GDI32.DLL，以及之後的GetDeviceCaps、GetStockObject、GetTextMetrics等等。

這樣的式樣會在.idata段中重複出現。第一個模塊是COMDLG32.DLL，第二個是GDI32.DLL。請注意第一個模塊只導出了一個函數，而第二個模塊導出了很多函數。在這兩種情況下，函數和模塊的排列的方法是首先出現一個函數名，之後是模塊名，然後是其它的函數名（如果有的話）。

以下的函數示範瞭如何獲得指定模塊的所有函數名。

01.// PEFILE.C

02. 

03.int WINAPI GetImportFunctionNamesByModule(LPVOID lpFile, HANDLE hHeap,

04.char *pszModule, char **pszFunctions)

05.{

06.PIMAGE_IMPORT_MODULE_DIRECTORY pid;

07.IMAGE_SECTION_HEADER idsh;

08.DWORD dwBase;

09.int nCnt = 0, nSize = 0;

10.DWORD dwFunction;

11.char *psz;

12./* 定位.idata段的頭部 */

13.if (!GetSectionHdrByName(lpFile, &idsh, ".idata"))

14.return 0;

15.pid = (PIMAGE_IMPORT_MODULE_DIRECTORY)ImageDirectoryOffset

16.(lpFile, IMAGE_DIRECTORY_ENTRY_IMPORT);

17.dwBase = ((DWORD)pid. idsh.VirtualAddress);

18./* 查找模塊的pid */

19.while (pid->dwRVAModuleName && strcmp (pszModule,

20.(char *)(pid->dwRVAModuleName+dwBase)))

21.pid++;

22./* 如果模塊未找到，就退出 */

23.if (!pid->dwRVAModuleName)

24.return 0;

25./* 函數的總數和字符串長度 */

26.dwFunction = pid->dwRVAFunctionNameList;

27.while (dwFunction && *(DWORD *)(dwFunction + dwBase) &&

28.*(char *)((*(DWORD *)(dwFunction + dwBase)) + dwBase+2))

29.{

30.nSize += strlen ((char *)((*(DWORD *)(dwFunction +

31.dwBase)) + dwBase+2)) + 1;

32.dwFunction += 4;

33.nCnt++;

34.}

35./* 在堆上分配函數名稱的空間 */

36.*pszFunctions = HeapAlloc (hHeap, HEAP_ZERO_MEMORY, nSize);

37.psz = *pszFunctions;

38./* 向內存指針複製函數名稱 */

39.dwFunction = pid->dwRVAFunctionNameList;

40.while (dwFunction && *(DWORD *)(dwFunction + dwBase) &&

41.*((char *)((*(DWORD *)(dwFunction + dwBase)) + dwBase+2)))

42.{

43.strcpy (psz, (char *)((*(DWORD *)(dwFunction + dwBase)) +

44.dwBase+2));

45.psz += strlen((char *)((*(DWORD *)(dwFunction + dwBase))+

46.dwBase+2)) + 1;

47.dwFunction += 4;

48.}

49.return nCnt;

50.}

51.　　

就像GetImportModuleNames函數一樣，這一函數依靠每個信息列表的末端來獲得一個置零的入口。這在種情況下，函數名稱列表就是以零結尾的。

最後一個域dwRVAFunctionAddressList是一個相對虛擬地址，它指向一個虛擬地址表。在文件裝載的時候，這個虛擬地址表會被裝載器置於段數據之中。但是在文件裝載前，這些虛擬地址會被一些嚴密符合函數名稱列表的虛擬地址替換。所以在文件裝載之前，有兩個同樣的虛擬地址列表，它們指向導入函數列表。

調試信息段，.debug

調試信息位於.debug段之中，同時PE文件格式也支持單獨的調試文件（通常由.DBG擴展名標識）作爲一種將調試信息集中的方法。調試段包含了調試信息，但是調試目錄卻位於早先提到的.rdata段之中。這其中每個目錄都涉及了.debug段之中的調試信息。調試目錄的結構IMAGE_DEBUG_DIRECTORY被定義爲：

01.// WINNT.H

02. 

03.typedef struct _IMAGE_DEBUG_DIRECTORY {

04.ULONG Characteristics;

05.ULONG TimeDateStamp;

06.USHORT MajorVersion;

07.USHORT MinorVersion;

08.ULONG Type;

09.ULONG SizeOfData;

10.ULONG AddressOfRawData;

11.ULONG PointerToRawData;

12.} IMAGE_DEBUG_DIRECTORY, *PIMAGE_DEBUG_DIRECTORY;

這個段被分爲單獨的部分，每個部分爲不同種類的調試信息數據。對於每個部分來說都是一個像上邊一樣的調試目錄。不同的調試信息種類如下：

1.// WINNT.H

2. 

3.#define IMAGE_DEBUG_TYPE_UNKNOWN 0

4.#define IMAGE_DEBUG_TYPE_COFF 1

5.#define IMAGE_DEBUG_TYPE_CODEVIEW 2

6.#define IMAGE_DEBUG_TYPE_FPO 3

7.#define IMAGE_DEBUG_TYPE_MISC 4

8.　　

每個目錄之中的Type域表示該目錄的調試信息種類。如你所見，在上邊的表中，PE文件格式支持很多不同的調試信息種類，以及一些其它的信息域。對於那些來說，IMAGE_DEBUG_TYPE_MISC信息是唯一的。這一信息被添加到描述可執行映像的混雜信息之中，這些混雜信息不能被添加到PE文件格式任何結構化的數據段之中。這就是映像文件中最合適的位置，映像名稱則肯定會出現在這裏。如果映像導出了信息，那麼導出數據段也會包含這一映像名稱。

每種調試信息都擁有自己的頭部結構，該結構定義了它自己的數據。這些結構都列於WINNT.H之中。關於IMAGE_DEBUG_DIRECTORY一件有趣的事就是它包括了兩個標識調試信息的域。第一個是AddressOfRawData，爲相對文件裝載的數據虛擬地址；另一個是PointerToRawData，爲數據所在PE文件之中的實際偏移量。這就使得定位指定的調試信息相當容易了。

作爲最後的例子，請你考慮以下的函數代碼，它從IMAGE_DEBUG_MISC結構中提取了映像名稱。

01.//PEFILE.C

02. 

03.int WINAPI RetrieveModuleName(LPVOID lpFile, HANDLE hHeap, char **pszModule)

04.{

05.PIMAGE_DEBUG_DIRECTORY pdd;

06.PIMAGE_DEBUG_MISC pdm = NULL;

07.int nCnt;

08.if (!(pdd = (PIMAGE_DEBUG_DIRECTORY)ImageDirectoryOffset(lpFile,

09.IMAGE_DIRECTORY_ENTRY_DEBUG)))

10.return 0;

11.while (pdd->SizeOfData)

12.{

13.if (pdd->Type == IMAGE_DEBUG_TYPE_MISC)

14.{

15.pdm = (PIMAGE_DEBUG_MISC)((DWORD)pdd->PointerToRawData + (DWORD)lpFile);

16.nCnt = lstrlen(pdm->Data) * (pdm->Unicode ? 2 : 1);

17.*pszModule = (char *)HeapAlloc(hHeap, HEAP_ZERO_MEMORY, nCnt+1);

18.CopyMemory(*pszModule, pdm->Data, nCnt);

19.break;

20.}

21.pdd ++;

22.}

23.if (pdm != NULL)

24.return nCnt;

25.else

26.return 0;

27.}

你看到了，調試目錄結構使得定位一個特定種類的調試信息變得相對容易了些。只要定位了IMAGE_DEBUG_MISC結構，提取映像名稱就如同調用CopyMemory函數一樣簡單。

如上所述，調試信息可以被剝離到單獨的.DBG文件中。Windows NT SDK包含了一個名爲REBASE.EXE的程序可以實現這一目的。例如，以下的語句可以將一個名爲TEST.EXE的調試信息剝離：

rebase -b 40000 -x c:\samples\testdir test.exe

調試信息被置於一個新的文件中，這個文件名爲TEST.DBG，位於c:\samples\testdir之中。這個文件起始於一個單獨的IMAGE_SEPARATE_DEBUG_HEADER結構，接着是存在於原可執行映像之中的段頭部的一份拷貝。在段頭部之後，是.debug段的數據。也就是說，在段頭部之後，就是一系列的IMAGE_DEBUG_DIRECTORY結構及其相關的數據了。調試信息本身保留了如上所描述的常規映像文件調試信息。

PE文件格式總結

Windows NT的PE文件格式向熟悉Windows和MS-DOS環境的開發者引入了一種全新的結構。然而熟悉UNIX環境的開發者會發現PE文件格式與COFF規範很相像（如果它不是以COFF爲基礎的話）。

整個格式的組成：一個MS-DOS的MZ頭部，之後是一個實模式的殘餘程序、PE文件標誌、PE文件頭部、PE可選頭部、所有的段頭部，最後是所有的段實體。

可選頭部的末尾是一個數據目錄入口的數組，這些相對虛擬地址指向段實體之中的數據目錄。每個數據目錄都表示了一個特定的段實體數據是如何組織的。

PE文件格式有11個預定義段，這是對Windows NT應用程序所通用的，但是每個應用程序可以爲它自己的代碼以及數據定義它自己獨特的段。

.debug預定義段也可以分離爲一個單獨的調試文件。如果這樣的話，就會有一個特定的調試頭部來用於解析這個調試文件，PE文件中也會有一個標誌來表示調試數據被分離了出去。

PEFILE.DLL函數描述

PEFILE.DLL主要由一些函數組成，這些函數或者被用來獲得一個給定的PE文件中的偏移量，或者被用來把文件中的一些數據複製到一個特定的結構中去。每個函數都有一個需求――第一個參數是一個指針，這個指針指向PE文件的起始處。也就是說，這個文件必須首先被映射到你進程的地址空間中，然後映射文件的位置就可以作爲每個函數第一個參數的lpFile的值來傳入了。

我意在使函數的名稱使你能夠一見而知其意，並且每個函數都隨一個詳細描述其目的的註釋而列出。如果在讀完函數列表之後，你仍然不明白某個函數的功能，那麼請參考EXEVIEW.EXE示例來查明這個函數是如何使用的。以下的函數原型列表可以在PEFILE.H中找到：

01.// PEFILE.H

02. 

03./* 獲得指向MS-DOS MZ頭部的指針 */

04.BOOL WINAPI GetDosHeader(LPVOID, PIMAGE_DOS_HEADER);

05. 

06./* 決定.EXE文件的類型 */

07.DWORD WINAPI ImageFileType(LPVOID);

08. 

09./* 獲得指向PE文件頭部的指針 */

10.BOOL WINAPI GetPEFileHeader(LPVOID, PIMAGE_FILE_HEADER);

11. 

12./* 獲得指向PE可選頭部的指針 */

13.BOOL WINAPI GetPEOptionalHeader(LPVOID, PIMAGE_OPTIONAL_HEADER);

14. 

15./* 返回模塊入口點的地址 */

16.LPVOID WINAPI GetModuleEntryPoint(LPVOID);

17. 

18./* 返回文件中段的總數 */

19.int WINAPI NumOfSections(LPVOID);

20. 

21./* 返回當可執行文件被裝載入進程地址空間時的首選基地址 */

22.LPVOID WINAPI GetImageBase(LPVOID);

23. 

24./* 決定文件中一個特定的映像數據目錄的位置 */

25.LPVOID WINAPI ImageDirectoryOffset(LPVOID, DWORD);

26. 

27./* 獲得文件中所有段的名稱 */

28.int WINAPI GetSectionNames(LPVOID, HANDLE, char **);

29. 

30./* 複製一個特定段的頭部信息 */

31.BOOL WINAPI GetSectionHdrByName(LPVOID, PIMAGE_SECTION_HEADER, char *);

32. 

33./* 獲得由空字符分隔的導入模塊名稱列表 */

34.int WINAPI GetImportModuleNames(LPVOID, HANDLE, char **);

35. 

36./* 獲得一個模塊由空字符分隔的導入函數列表 */

37.int WINAPI GetImportFunctionNamesByModule(LPVOID, HANDLE, char *, char **);

38. 

39./* 獲得由空字符分隔的導出函數列表 */

40.int WINAPI GetExportFunctionNames(LPVOID, HANDLE, char **);

41. 

42./* 獲得導出函數總數 */

43.int WINAPI GetNumberOfExportedFunctions(LPVOID);

44. 

45./* 獲得導出函數的虛擬地址入口點列表 */

46.LPVOID WINAPI GetExportFunctionEntryPoints(LPVOID);

47. 

48./* 獲得導出函數順序值列表 */

49.LPVOID WINAPI GetExportFunctionOrdinals(LPVOID);

50. 

51./* 決定資源對象的種類 */

52.int WINAPI GetNumberOfResources (LPVOID);

53. 

54./* 返回文件中所使用的所有資源對象的種類 */

55.int WINAPI GetListOfResourceTypes(LPVOID, HANDLE, char **);

56. 

57./* 決定調試信息是否已從文件中分離 */

58.BOOL WINAPI IsDebugInfoStripped(LPVOID);

59. 

60./* 獲得映像文件名稱 */

61.int WINAPI RetrieveModuleName(LPVOID, HANDLE, char **);

62. 

63./* 決定文件是否是一個有效的調試文件 */

64.BOOL WINAPI IsDebugFile(LPVOID);

65. 

66./* 從調試文件中返回調試頭部 */

67.BOOL WINAPI GetSeparateDebugHeader(LPVOID, PIMAGE_SEPARATE_DEBUG_HEADER);

68.　　除了以上所列的函數之外，本文中早先提到的宏也定義在了PEFILE.H中，完整的列表如下：

69./* PE文件標誌的偏移量 */

70.#define NTSIGNATURE(a) ((LPVOID)((BYTE *)a + \

71.((PIMAGE_DOS_HEADER)a)->e_lfanew))

72. 

73./* MS操作系統頭部標識了雙字的NT PE文件標誌；PE文件頭部就緊跟在這個雙字之後 */

74.#define PEFHDROFFSET(a) ((LPVOID)((BYTE *)a + \

75.((PIMAGE_DOS_HEADER)a)->e_lfanew + \

76.SIZE_OF_NT_SIGNATURE))

77. 

78./* PE可選頭部緊跟在PE文件頭部之後 */

79.#define OPTHDROFFSET(a) ((LPVOID)((BYTE *)a + \

80.((PIMAGE_DOS_HEADER)a)->e_lfanew + \

81.SIZE_OF_NT_SIGNATURE + \

82.sizeof(IMAGE_FILE_HEADER)))

83. 

84./* 段頭部緊跟在PE可選頭部之後 */

85.#define SECHDROFFSET(a) ((LPVOID)((BYTE *)a + \

86.((PIMAGE_DOS_HEADER)a)->e_lfanew + \

87.SIZE_OF_NT_SIGNATURE + \

88.sizeof(IMAGE_FILE_HEADER) + \

89.sizeof(IMAGE_OPTIONAL_HEADER)))

90.　　

要使用PEFILE.DLL，你只用包含PEFILE.H文件並在應用程序中鏈接到這個DLL即可。所有的這些函數都是互斥性的函數，但是有些函數的功能可以相互支持以獲得文件信息。例如，GetSectionNames可以用於獲得所有段的名稱，這樣一來，爲了獲得一個擁有獨特段名稱（在編譯期由應用程序開發者定義的）的段頭部，你就需要首先獲得所有名稱的列表，然後再對那個準確的段名稱調用函數GetSectionHeaderByName了。現在，你可以享受我爲你帶來的這一切了！