【正文】 信息分離了。比如對于一個可執(zhí)行文件而言，分離調(diào)試文件是如何操作的。系統(tǒng)使用這一信息來在讀取這個文件的其它數(shù)據(jù)之前決定如何處理它。 PE 文件中的信息基本上是一些高級信息，這些信息是被操作系統(tǒng)或者 應(yīng)用程序用來決定如何處理這個文件的。但是我覺得對結(jié)構(gòu)本身使用 sizeof 運(yùn)算符（譯注：原文為 “function”）更簡單一些，因?yàn)檫@樣的話我就不必記住這個常量的名字 IMAGE_SIZEOF_FILE_HEADER，而只需要記住結(jié)構(gòu)IMAGE_FILE_HEADER 的名字就可以了。 } IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER。 USHORT SizeOfOptionalHeader。 ULONG PointerToSymbolTable。 USHORT NumberOfSections。 在這個例子中， lpFile 表示一個指向可執(zhí)行文件內(nèi)存映像基地址的指針，這就顯出了內(nèi)存映射文件的好處：不需要執(zhí)行文件的 I/O，只需使用指針 pfh 就能存取文件中的信息。我們只需要把這個位置賦值給一個結(jié)構(gòu)，如下： PIMAGE_FILE_HEADER pfh。不幸的是，這個常量并未定義在 之中，于 是我將它定義在了 中，它是一個 DWORD 的大小。 現(xiàn)在把我們的注意力轉(zhuǎn)向 Windows NT PE 文件格式，我們會發(fā)現(xiàn)只要我們得到了文件標(biāo)志的位置，PE 文件之后就會有 4 個字節(jié)相跟隨。但是，在稍微研究一下之后，就能得到原因了：除了操作系統(tǒng)版本規(guī)范的不同之外， Windows 的可執(zhí)行文件和 OS/2 的可執(zhí)行文件實(shí)在沒有什么區(qū)別。對于比較不同文件類型并且返回一個適當(dāng)?shù)奈募N類來說，這個宏就會使這兩件事變得非常簡單。 } else /* 不明文件種類 */ return 0。 else if (*(DWORD *)NTSIGNATURE (lpFile) == IMAGE_NT_SIGNATURE) return IMAGE_NT_SIGNATURE。所以，文件頭部是在DWORD 標(biāo)志之后，還是在 WORD 標(biāo)志處，是由這個標(biāo)志是否 Windows NT 文件標(biāo)志所決定的。同樣，對于 PE 文件格式， Windows NT 使用了一個 DWORD 值。對于 Windows NT 的 PE 文件格式而言，這一標(biāo)志在 PE 文件頭部結(jié)構(gòu)之前。 請注意這個宏所獲得的是 PE 文件標(biāo)志，而并非 PE 文件頭部的偏移量。例如，以下的宏是包含在 源文件之中的： // define NTSIGNATURE(a) ((LPVOID)((BYTE *)a + \ ((PIMAGE_DOS_HEADER)a)e_lfanew)) 在處理 PE 文件信息的時候，我發(fā)現(xiàn)文件之中有些位置需要經(jīng)常查閱。為 Windows NT 開發(fā)的應(yīng)用程序可以通過使用 STUB:鏈接器選項(xiàng)來實(shí)現(xiàn)。s simply not possible.” 當(dāng)為 Windows 構(gòu)建一個應(yīng)用程序的時候，鏈接器將向你的可執(zhí)行文件中鏈接一個名為 的默認(rèn)殘余程序。t run a Windows NT application on OS/2, it39。這種殘余程序通常什么也不做，而只是輸出一行文本，例如： “This program requires Microsoft Windows or greater.”當(dāng)然，用戶可以在此放入任何的殘余程序，這就意味著你可能經(jīng)?？吹较襁@樣的東西： “You can39。對于一個 MSDOS 的可執(zhí)行映像文件，應(yīng)用程序就是從這里執(zhí)行的。對于 Windows NT 的 PE 文件來說， PE 文件頭部是緊跟在 MSDOS 頭部和實(shí)模式程序殘余之后的。 MSDOS 頭部之所以有的時候被稱為 MZ頭部，就是這個緣故。 第一個域 e_magic，被稱為魔術(shù)數(shù)字，它被用于表示一個 MSDOS 兼容的文件類型。 // 保留字 LONG e_lfanew。 // OEM 標(biāo)識符（相對 e_oeminfo） USHORT e_oeminfo。 // 覆蓋號 USHORT e_res[4]。 // 初始的 CS 值（相對偏移量） USHORT e_lfarlc。 // 校驗(yàn)和 USHORT e_ip。 // 初始的 SS 值（相對偏移量） USHORT e_sp。 // 所需的最小附加段 USHORT e_maxalloc。 // 重定義元素個數(shù) USHORT e_cparhdr。 // 文件最后頁的字節(jié)數(shù) USHORT e_cp。換句話說，當(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。在 PE 文件格式中，它并非一個新概念，因?yàn)樗c MSDOS 以來就已有的 MSDOS 頭部是完全一樣的。 注意：請查閱本文末尾關(guān)于如何使用 的那一段。所有的源碼均摘自 模塊的 文件。我將所有這些成分列于圖 1。這些之后是所有的段頭部，段頭部之后跟隨著所有的段實(shí)體。 閑話少敘，讓我們開始吧。 創(chuàng)建這一示例目的有二：首先，我需要測試 的函數(shù)，并且某些情況要求我同時查看多個文件；其次，很多解決 PE 文件格式的工作和直接觀看數(shù)據(jù)有關(guān)。你會在 工程的 中找到這些結(jié)構(gòu)的定義，整套的 開發(fā)文件包含在 PEFile 示例程序之中。 許多單獨(dú)的文件成分定義都 來自于 Microsoft Win32 SDK 開發(fā)包中的 文件，在這個文件中你會發(fā)現(xiàn)用來描述文件頭部和數(shù)據(jù)目錄等各種成分的結(jié)構(gòu)類型定義。 在本文之中， PE 文件格式是以自頂而下的順序解釋的。 介紹 Windows 操作系統(tǒng)家族最近增加的 Windows NT 為開發(fā)環(huán)境和應(yīng)用程序本身帶來了很大的改變，這之中一個最為重大的當(dāng)屬 PE 文件格式了。在本文末尾，你會找到 的函數(shù)導(dǎo)出列表和一個如何使用它們的說明。 為了獲得 PE 文件中所包含的重要信息，我編寫了一個名為 的動態(tài)鏈接庫，本文中所有出現(xiàn)的源碼示例亦均摘自于此。 然而這一的文檔并未提供足夠的信息，所以開發(fā)者們無法很好地弄懂 PE 格式。PE 文件格式詳解 (上 ) 摘要 Windows NT 引入了一種名為 PE 文件格式的新可執(zhí)行文件格式。 PE 文件格式的規(guī)范包含在了MSDN 的 CD 中（ Specs and Strategy, Specifications, Windows NT File Format Specifications），但是它非常之晦澀。本文旨在解決這一問題，它會對整個的 PE 文件格式作一個十分徹底的解釋，另外，本文中還帶有對所有必需結(jié)構(gòu)的 描述以及示范如何使用這些信息的源碼示例。這個 DLL 和它的源代碼都作為 PEFile 示例程序的一部分包含在了 CD中（譯注：示例程序請在 MSDN 中尋找，本站恕不提供），你可以在你自己的應(yīng)用程序中使用這個 DLL；同樣，你亦可以依你所愿地使用并構(gòu)建它的源碼。我覺得你會發(fā)現(xiàn)這些函數(shù)會讓你從容應(yīng)付 PE 文件格式的 。新的 PE 文件格式主要來自于 UNIX 操作系統(tǒng)所通用的 COFF規(guī)范，同時為了保證與舊版本 MSDOS 及 Windows 操作系統(tǒng)的兼容， PE 文件格式也保留了 MSDOS 中那熟悉的 MZ 頭部。在你從頭開始研究文件內(nèi)容的過程之中，本文會詳細(xì)討論 PE 文件的每一個組成部分。但是，在 中缺少對 PE文件結(jié)構(gòu)足夠的定義，在這種情況下，我定義了自己的結(jié)構(gòu)來存取文件數(shù)據(jù)。 本文配套的示例程序除了 示例代碼之外，還有一個單獨(dú)的 Win32 示例應(yīng)用程序，名為。例如，要弄懂導(dǎo)入地址名稱表是如何構(gòu)成的，我就得同時查看 .idata 段頭部、導(dǎo)入映像數(shù)據(jù)目錄、可選頭部以及當(dāng)前的 .idata段實(shí)體，而 就是查看這些信息的最佳示例。 PE 文件結(jié)構(gòu) PE 文件格式被組織為一個線性的數(shù)據(jù)流，它由一個 MSDOS 頭部開始，接著是一個是模式的程序殘余以及一個 PE 文件標(biāo) 志，這之后緊接著 PE 文件頭和可選頭部。文件的結(jié)束處是一些其它的區(qū)域，其中是一些混雜的信息，包括重分配信息、符號表信息、行號信息以及字串表數(shù)據(jù)。 圖 文件映像結(jié)構(gòu) 從 MSDOS 文件頭結(jié)構(gòu)開始，我將按照 PE 文件格式各成分的出現(xiàn)順序依次對其進(jìn)行討論，并且討論的大部分是以示例代碼為基礎(chǔ)來示范如何獲得文件的信息的。這些示例都利用了 Windows NT 最酷的特色之一 ——內(nèi)存映射文件，這一特色允許用戶使用一個簡單的指針來存取文件中所包含的數(shù)據(jù)，因此所有的示例都使用了內(nèi)存映射文件來存取 PE 文件中的數(shù)據(jù)。 MSDOS 頭部 /實(shí)模式頭部 如上所述， PE 文件格式的第一個組成部分是 MSDOS 頭部。保留這個相同結(jié)構(gòu)的最主要原因是，當(dāng)你嘗試在 Windows 以下或 MSDOS 以上的系統(tǒng)下裝載一個文件的時候，操作系統(tǒng)能夠讀取這個文件并明白它是和當(dāng)前系統(tǒng)不相兼容的。 // 魔術(shù)數(shù)字 USHORT e_cblp。 // 文件頁數(shù) USHORT e_crlc。 // 頭部尺寸，以段落為單位 USHORT e_minalloc。 // 所需的最大附加段 USHORT e_ss。 // 初始的 SP 值 USHORT e_csum。 // 初始的 IP 值 USHORT e_cs。 // 重分配表文件地址 USHORT e_ovno。 // 保留字 USHORT e_oemid。 // OEM 信息 USHORT e_res2[10]。 // 新 exe 頭部的文件地址 } IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER。所有 MSDOS 兼容的可執(zhí)行文件都將這個值設(shè)為 0x5A4D，表示 ASCII 字符 MZ。還有許多其它的域?qū)τ?MSDOS 操作系統(tǒng)來說都有用，但是對于 Windows NT 來說，這個結(jié)構(gòu)中只有一個有用的域 ——最 后一個域 e_lfnew，一個 4 字節(jié)的文件偏移量， PE 文件頭部就是由它定位的。 實(shí)模式殘余程序 實(shí)模式殘余程序是一個在裝載時能夠被 MSDOS 運(yùn)行的實(shí)際程序。對于 Windows、 OS/ Windows NT 這些操作系統(tǒng)來說， MSDOS殘余程序就代替了主程序的位置被放在這里。39。39。你可以用一個基于 MSDOS 的有效 程序取代 WINSTUB，并且用 STUB模塊定義語句指示鏈接器，這樣就能夠取代鏈接器的默認(rèn)行為。 PE 文件頭部與標(biāo)志 PE 文件頭部是由 MSDOS 頭部的 e_lfanew 域定位的，這個域只是給出了文件的偏移量，所以要確定 PE 頭部的實(shí)際內(nèi)存映射地址，就需要添加文件的內(nèi)存映射基地址。既然這些位置僅僅是對文件的偏移量，那么用宏來實(shí)現(xiàn)這些定位就比較容易，因?yàn)樗鼈冚^之函數(shù)有更好的表現(xiàn)。那是由于自 Windows 與OS/2 的可執(zhí)行文件開始， .EXE 文件都被賦予了目標(biāo)操作系統(tǒng)的標(biāo)志。在 Windows 和 OS/2 的某些版本中，這一標(biāo)志是文件頭的第一個字。 以上的宏返回了文件標(biāo)志的偏移量，而不管它是哪種類型的可執(zhí)行文件。要解決這個問題，我編寫了 ImageFileType 函數(shù)（如下），它返回了映像文件的類型： // DWORD WINAPI ImageFileType (LPVOID lpFile) { /* 首先出現(xiàn)的是 DOS 文件標(biāo)志 */ if (*(USHORT *)lpFile == IMAGE_DOS_SIGNATURE) { /* 由 DOS 頭部決定 PE 文件頭部的位置 */ if (LOWORD (*(DWORD *)NTSIGNATURE (lpFile)) == IMAGE_OS2_SIGNATURE || LOWORD (*(DWORD *)NTSIGNATURE (lpFile)) == IMAGE_OS2_SIGNATURE_LE) return (DWORD)LOWORD(*(DWORD *)NTSIGNATURE (lpFile))。 else return IMAGE_DOS_SIGNA