【正文】 Windows NT 默認(rèn)的做法是將所有的代碼段（正如它們在 Windows 中所提到的那樣）組成了一個單獨的段，名為 “.text”。一些應(yīng)用程序不需要所有的這些段，同樣還有一些應(yīng)用程序為了自己特殊的需要而定義了更多的段。 /* 返回映像導(dǎo)入目錄的偏移量 */ return (LPVOID)(((int)lpFile + (int)VAImageDir. pshVirtualAddress) + (int)pshPointerToRawData)。amp。 /* 獲得可選頭部和段頭部的偏移量 */ poh = (PIMAGE_OPTIONAL_HEADER)OPTHDROFFSET(lpFile)。 int nSections = NumOfSections(lpFile)。由于這個緣故，如果你需要定位一個指定的數(shù)據(jù)目錄的話，就需要從段頭部和可選頭部中獲得信息。定義了段的特征。PointerToRelocations、 PointerToLinenumbers、 NumberOfRelocations、 NumberOfLinenumbers。 SizeOfRawData。實際的地址由將這個域的值加上可選頭部結(jié)構(gòu)中的 ImageBase 虛擬地址得到。第二個域是一個 union 域，現(xiàn)在已不使用了。Name。 } } return FALSE。 i nSections。以下的函數(shù)示范了如何從一個給定了段名稱的 PE 映像文件中獲得一個段頭部： // BOOL WINAPI GetSectionHdrByName(LPVOID lpFile, IMAGE_SECTION_HEADER *sh, char *szSection) { PIMAGE_SECTION_HEADER psh。 USHORT NumberOfLinenumbers。 ULONG PointerToRawData。 ULONG VirtualSize。 段頭部 PE 文件格式中，所有的段頭部位于可選頭部之后。 PE 文件段 PE 文件規(guī)范由目前為止定義的那些頭部以及一個名為 “段 ”的一般對象組成。如果你要定義一個特定的目錄的話，就需要從可選頭部中的數(shù)據(jù)目錄數(shù)組中決定相對的地址，然后使用虛擬地址來決定該目錄位于哪個段中。 // typedef struct _IMAGE_DATA_DIRECTORY { ULONG VirtualAddress。當(dāng)前的 PE 文件格式定義了 16 種可能的數(shù)據(jù)目錄，這之中的 11 種現(xiàn)在在使用中。 這些值可以使用鏈接器開關(guān) STACKSIZE:與 HEAPSIZE:來設(shè)置。 每個可能的子系統(tǒng)取值列于 的IMAGE_OPTIONAL_HEADER 結(jié)構(gòu)之后。由于創(chuàng)建這些校驗和的算法是私有信息，所以在此不進(jìn)行討論。文件中所有的段實體就開始于這個位置。它首先決定每個段需要多少字節(jié)，并且最后將頁面總數(shù)向上取整至最接近的 SectionAlignment 邊界，然后總數(shù)就是每個段個別需求之和了。例如，考慮一個擁有固定頁尺寸 4096 字節(jié)的系統(tǒng)，如果你有一個 11個段的可執(zhí)行文件，它的每個段都少于 4096 字節(jié)，并且關(guān)于 65536 字節(jié)邊界對齊，那么 SizeOfImage域?qū)辉O(shè)為 11 * 65536 = 720896（ 176 頁）。未知目的，通常不被系統(tǒng)使用，并被鏈接器設(shè)為 0。MinorSubsystemVersion。 用來表示應(yīng)用程序的主版本號；對于 Microsoft Excel 而言，這個值是 4。MinorOperatingSystemVersion。 FileAlignment。SectionAlignment 則規(guī) 定了裝載時段能夠占據(jù)的最小空間數(shù)量 ——就是說，段是關(guān)于 SectionAlignment對齊的。 Windows NT 的 Microsoft Win32 SDK 鏈接器將這個值默認(rèn)設(shè)為 0x00400000，但是你可以使用 BASE:linker 開關(guān)改變這個值。 Windows NT 附加域 添加到 Windows NT PE 文件格式中的附加域為 Windows NT 特定的進(jìn)程行為提供了裝載器的支持，以下為這些域的概述。已載入映像的代碼（ “.text”段）的相對偏移量。 if (poh != NULL) return (LPVOID)pohAddressOfEntryPoint。并且，對于系統(tǒng)黑客來說，這個位置就是導(dǎo)入地址表（ IAT）的末尾。 已初始化的數(shù)據(jù)尺寸。SizeOfCode。MajorLinkerVersion、 MinorLinkerVersion。 為了不讓你對所有這些域感到厭煩，我會僅僅討論有用的 ——就是說，對于探究 PE 文件格式而言有用的。 ULONG NumberOfRvaAndSizes。 ULONG SizeOfStackCommit。 ULONG CheckSum。 USHORT MinorSubsystemVersion。 USHORT MinorOperatingSystemVersion。 // // NT 附加域 // ULONG ImageBase。 ULONG SizeOfUninitializedData。 UCHAR MajorLinkerVersion。 PE 可選頭部 PE 可執(zhí)行文件中接下來的 224 個字節(jié)組成了 PE 可選頭部。 PE 文件頭結(jié)構(gòu)中另一個有用的入口是 NumberOfSections 域，它表示如果你要方便地提取文件信息的話，就需要了解多少個段 ——更明確一點來說，有多少個段頭部和多少個段實體。要使調(diào)試器不在文件中查找的話，就需要用到 IMAGE_FILE_DEBUG_STRIPPED 這個特征，它表示文件的調(diào)試信息是否已經(jīng)被分離了。比如對于一個可執(zhí)行文件而言，分離調(diào)試文件是如何操作的。 PE 文件中的信息基本上是一些高級信息，這些信息是被操作系統(tǒng)或者 應(yīng)用程序用來決定如何處理這個文件的。 } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER。 ULONG PointerToSymbolTable。 在這個例子中， lpFile 表示一個指向可執(zhí)行文件內(nèi)存映像基地址的指針，這就顯出了內(nèi)存映射文件的好處：不需要執(zhí)行文件的 I/O，只需使用指針 pfh 就能存取文件中的信息。不幸的是，這個常量并未定義在 之中，于 是我將它定義在了 中，它是一個 DWORD 的大小。但是，在稍微研究一下之后，就能得到原因了：除了操作系統(tǒng)版本規(guī)范的不同之外， Windows 的可執(zhí)行文件和 OS/2 的可執(zhí)行文件實在沒有什么區(qū)別。 } else /* 不明文件種類 */ return 0。所以，文件頭部是在DWORD 標(biāo)志之后，還是在 WORD 標(biāo)志處，是由這個標(biāo)志是否 Windows NT 文件標(biāo)志所決定的。對于 Windows NT 的 PE 文件格式而言，這一標(biāo)志在 PE 文件頭部結(jié)構(gòu)之前。例如，以下的宏是包含在 源文件之中的： // define NTSIGNATURE(a) ((LPVOID)((BYTE *)a + \ ((PIMAGE_DOS_HEADER)a)e_lfanew)) 在處理 PE 文件信息的時候，我發(fā)現(xiàn)文件之中有些位置需要經(jīng)常查閱。s simply not possible.” 當(dāng)為 Windows 構(gòu)建一個應(yīng)用程序的時候，鏈接器將向你的可執(zhí)行文件中鏈接一個名為 的默認(rèn)殘余程序。這種殘余程序通常什么也不做，而只是輸出一行文本，例如： “This program requires Microsoft Windows or greater.”當(dāng)然，用戶可以在此放入任何的殘余程序，這就意味著你可能經(jīng)?？吹较襁@樣的東西： “You can39。對于 Windows NT 的 PE 文件來說， PE 文件頭部是緊跟在 MSDOS 頭部和實模式程序殘余之后的。 第一個域 e_magic，被稱為魔術(shù)數(shù)字，它被用于表示一個 MSDOS 兼容的文件類型。 // OEM 標(biāo)識符（相對 e_oeminfo） USHORT e_oeminfo。 // 初始的 CS 值（相對偏移量） USHORT e_lfarlc。 // 初始的 SS 值（相對偏移量） USHORT e_sp。 // 重定義元素個數(shù) USHORT e_cparhdr。換句話說，當(dāng)你在 MSDOS 下運(yùn)行一個 Windows NT可執(zhí)行文件時，你會得到這樣一條消息： “This program cannot be run in DOS mode.”如果 MSDOS 頭部不是作 為 PE 文件格式的第一部分的話，操作系統(tǒng)裝載文件的時候就會失敗，并提供一些完全沒用的信息，例如： “The name specified is not recognized as an internal or external mand, operable program or batch file.” MSDOS 頭部占據(jù)了 PE 文件的頭 64 個字節(jié)，描述它內(nèi)容的結(jié)構(gòu)如下： // typedef struct _IMAGE_DOS_HEADER { // DOS 的 .EXE 頭部 USHORT e_magic。 注意：請查閱本文末尾關(guān)于如何使用 的那一段。我將所有這些成分列于圖 1。 閑話少敘，讓我們開始吧。你會在 工程的 中找到這些結(jié)構(gòu)的定義，整套的 開發(fā)文件包含在 PEFile 示例程序之中。 在本文之中， PE 文件格式是以自頂而下的順序解釋的。在本文末尾，你會找到 的函數(shù)導(dǎo)出列表和一個如何使用它們的說明。 然而這一的文檔并未提供足夠的信息，所以開發(fā)者們無法很好地弄懂 PE 格式。 PE 文件格式的規(guī)范包含在了MSDN 的 CD 中（ Specs and Strategy, Specifications, Windows NT File Format Specifications），但是它非常之晦澀。這個 DLL 和它的源代碼都作為 PEFile 示例程序的一部分包含在了 CD中（譯注：示例程序請在 MSDN 中尋找，本站恕不提供），你可以在你自己的應(yīng)用程序中使用這個 DLL；同樣，你亦可以依你所愿地使用并構(gòu)建它的源碼。新的 PE 文件格式主要來自于 UNIX 操作系統(tǒng)所通用的 COFF規(guī)范，同時為了保證與舊版本 MSDOS 及 Windows 操作系統(tǒng)的兼容， PE 文件格式也保留了 MSDOS 中那熟悉的 MZ 頭部。但是，在 中缺少對 PE文件結(jié)構(gòu)足夠的定義，在這種情況下，我定義了自己的結(jié)構(gòu)來存取文件數(shù)據(jù)。例如，要弄懂導(dǎo)入地址名稱表是如何構(gòu)成的，我就得同時查看 .idata 段頭部、導(dǎo)入映像數(shù)據(jù)目錄、可選頭部以及當(dāng)前的 .idata段實體，而 就是查看這些信息的最佳示例。文件的結(jié)束處是一些其它的區(qū)域，其中是一些混雜的信息，包括重分配信息、符號表信息、行號信息以及字串表數(shù)據(jù)。這些示例都利用了 Windows NT 最酷的特色之一 ——內(nèi)存映射文件，這一特色允許用戶使用一個簡單的指針來存取文件中所包含的數(shù)據(jù)，因此所有的示例都使用了內(nèi)存映射文件來存取 PE 文件中的數(shù)據(jù)。保留這個相同結(jié)構(gòu)的最主要原因是，當(dāng)你嘗試在 Windows 以下或 MSDOS 以上的系統(tǒng)下裝載一個文件的時候，操作系統(tǒng)能夠讀取這個文件并明白它是和當(dāng)前系統(tǒng)不相兼容的。 // 文件頁數(shù) USHORT e_crlc。 // 所需的最大附加段 USHORT e_ss。 // 初始的 IP 值 USHORT e_cs。 // 保留字 USHORT e_oemid。 // 新 exe 頭部的文件地址 } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER。還有許多其它的域?qū)τ?MSDOS 操作系統(tǒng)來說都有用，但是對于 Windows NT 來說，這個結(jié)構(gòu)中只有一個有用的域 ——最 后一個域 e_lfnew，一個 4 字節(jié)的文件偏移量， PE 文件頭部就是由它定位的。對于 Windows、 OS/ Windows NT 這些操作系統(tǒng)來說， MSDOS殘余程序就代替了主程序的位置被放在這里。39。 PE 文件頭部與標(biāo)志 PE 文件頭部是由 MSDOS 頭部的 e_lfanew 域定位的，這個域只是給出了文件的偏移量，所以要確定 PE 頭部的實際內(nèi)存映射地址，就需要添加文件的內(nèi)存映射基地址。那是由于自 Windows 與OS/2 的可執(zhí)行文件開始， .EXE 文件都被賦予了目標(biāo)操作系統(tǒng)的標(biāo)志。 以上的宏返回了文件標(biāo)志的偏移量，而不管它是哪種類型的可執(zhí)行文件。 else return IMAGE_DOS_SIGNATURE。 之中定義的四種不同文件類型有： // define IMAGE_DOS