pe文件頭位置如何確定

⑴ 什麼是PE文件分析呀

即對PE文件的分析。

PE 文件格式
對 PE 的一些說明： PE 是 Portable Excutable 的縮寫，是指「可移植可執行」文件，是 32 位 Windows （包括 OS/2 ）可執行文件的標准格式。以前的 16 位 Windows 可執行文件的格式稱為 NE ，即 New Excutable 「新可執行」文件。參考： NE 文件格式

一、簡介

PE文件最前面是一個DOS可執行文件（STUB），這使PE文件成為一個合法的MS-DOS可執行
文件。
DOS文件頭後面是一個32位的PE文件標志0X00004550（IMAGE_NT_SIGNATURE）。
接著就是PE的文件頭了，包含的信息有該程序運行平台、有多少段（sections）、文件
鏈接的時間、它是一個可執行文件（EXE）還是一個動態鏈接庫（DLL）或是其他。
後面緊接著有一個「可選」頭部（這個部分總是存在，但是因為COFF在庫（Libraries）
中用了這個詞，在一可執行模塊中並沒有用這個詞，但是仍被叫做可選的）。這可部分包含程
序載入的更多的信息：開始地址、保留堆棧數量、數據段大小等等。
可選頭中還有一個重要的域是一叫做「數據目錄表」（data directories）的數組；表
中的每一項是一個指向某一個段的指針。例如：如果某程序有一個輸出目錄表（export dire
ctory ），那你就會在數據目錄表中找到一個為IMAGE_DIRECTORY_ENTRY_EXPORT的指針，並且
它將指向某一個段。
可選頭的下面就是「段」（sections）了，通過一個叫做「段頭」（section headers）
的結構索引。實際上，段的內容才是你要真正執行的程序，上面介紹的所有的文件頭及目錄表
等信息就是為了能正確的找到它。
每一個段都有一些有關的標志，例如它包含什麼數據（「初始化數據」或其他），它能
否被共享等，及它數據本身的特徵。大多數情況下（並不是全部），每個段會被一個或多個目
錄表指向，目錄表可通過可選頭的「數據目錄表」的入口找到，就象輸出函數表或基址重定位
表。也有沒有目錄表指向的段，如可執行代碼或初始化數據。
整個文件結構如下：
+-------------------+
| DOS-stub |
+-------------------+
| file-header |
+-------------------+
| optional header |
|- - - - - - - - - -|
| |
| data directories |
| |
+-------------------+
| |
| section headers |
| |
+-------------------+
| |
| section 1 |
| |
+-------------------+
| |
| section 2 |
| |
+-------------------+
| |
| ... |
| |
+-------------------+
| |
| section n |
| |
+-------------------+

下面介紹一下相關虛擬地址（Relative Virtual Addresses）
PE格式文件中經常用到RVA，即相關虛擬地址，用在不知道基地址的情況下表示一個內存
地址。它需要加上基地址才能得到線性地址（Linear address）。
例如：假設一個可執行程序調入內存0x400000處並且程序從RVA 0x1560處開始執行。那
么正確的開始地址是0x401560。如果可執行程序調入0x100000處，則開始地址為0x101560。
因為PE文件的每一個段不必按同樣的邊界對齊方式調入，因此RVA地址的計算變得比較復
雜。例如，在文件中每一個段往往按512個位元組的方式對齊，而在內存中可能以4096位元組的方
式對齊。這方面的介紹可見下面的「SectionAlignment」、「FileAlignment」。舉個例子，
假設你知道一個程序從RVA 0x1560開始執行，你想從那兒反匯編它。你發現內存中的段對齊方
式為4096並且.code段開始於內存RVA 0x1560並且有16384位元組長；那麼你可以知道RVA 0x156
0在這個段的0x560處。你又發現這個段在文件中以512位元組方式對齊並且.code開始於文件0x8
00處，那現在你知道了可執行程序開始於0x800+0x560 = 0xd60處。

二、DOS頭（DOS-stub ）
眾所周知DOS頭的概念是從16位的WINDOWS可執行程序（NE格式）中來的，這個部分主要
用在OS/2可執行程序、自解壓文檔及其他應用程序。在PE格式文件中，大多數程序的這個部分
中只有大約100個位元組的代碼，只輸出一個諸如「this program needs windows NT 」之類的
信息。
你可以通過一個叫做IMAGE_DOS_HEADER的結構來識別一個合法的DOS頭。這個結構的頭兩
個位元組一定是「MZ」（#define IMAGE_DOS_SIGNATURE "MZ"）。怎麼才能找到PE開始的標志呢
？你可以通過該結構的一個叫做「e_lfanew」（offset 60，32bits） 的成員來找到它。在O
S/2及16位WINDOWS程序中這個標志是一個16位的字；在PE程序中，它是一個32位的雙字，值為
0x00004550（#define IMAGE_NT_SIGNATURE 0x00004550）。

typedef struct _IMAGE_DOS_HEADER { // DOS .EXE header
word e_magic; // Magic number
WORD e_cblp; // Bytes on last page of file
WORD e_cp; // Pages in file
WORD e_crlc; // Relocations
WORD e_cparhdr; // Size of header in paragraphs
WORD e_minalloc; // Minimum extra paragraphs needed
WORD e_maxalloc; // Maximum extra paragraphs needed
WORD e_ss; // Initial (relative) SS value
WORD e_sp; // Initial SP value
WORD e_csum; // Checksum
WORD e_ip; // Initial IP value
WORD e_cs; // Initial (relative) CS value
WORD e_lfarlc; // File address of relocation table
WORD e_ovno; // Overlay number
WORD e_res[4]; // Reserved words
WORD e_oemid; // OEM identifier (for e_oeminfo)
WORD e_oeminfo; // OEM information; e_oemid specific
WORD e_res2[10]; // Reserved words
LONG e_lfanew; // File address of new exe header
} IMAGE_DOS_HEADER, *PIMAGE_DOS_HEADER;

三、文件頭（File Header）
通過DOS頭，你可以找到一個叫做IMAGE_FILE_HEADER的結構，如下；下面我分別介紹一
下。

typedef struct _IMAGE_FILE_HEADER {
WORD Machine; //0x04
WORD NumberOfSections; //0x06
DWORD TimeDateStamp; //0x08
DWORD PointerToSymbolTable; //0x0c
DWORD NumberOfSymbols; //0x10
WORD SizeOfOptionalHeader; //0x14
WORD Characteristics; //0x16
} IMAGE_FILE_HEADER, *PIMAGE_FILE_HEADER;

Machine：表示該程序要執行的環境及平台，現在已知的值如下：
IMAGE_FILE_MACHINE_I386（0x14c）
Intel 80386 處理器以上
0x014d
Intel 80486 處理器以上
0x014e
Intel Pentium 處理器以上
0x0160
R3000(MIPS)處理器，高位在前
IMAGE_FILE_MACHINE_R3000(0x162)
R3000(MIPS)處理器，低位在前
IMAGE_FILE_MACHINE_R4000(0x166)
R4000(MIPS)處理器，低位在前
IMAGE_FILE_MACHINE_R10000(0x168)
R10000(MIPS)處理器，低位在前
IMAGE_FILE_MACHINE_ALPHA(0x184)
DEC Alpha AXP處理器
IMAGE_FILE_MACHINE_POWERPC(0x1f0)
IBM Power PC，低位在前
NumberOfSections：段的個數，段的概念我們將在下面介紹。
TimeDateStamp：文件建立的時間。你可用這個值來區分同一個文件的不同的版本，即使
它們的商業版本號相同。這個值的格式並沒有明確的規定，但是很顯然的大多數的C編譯器都
把它定為從1970.1.1 00:00:00以來的秒數（time_t ）。這個值有時也被用做綁定輸入目錄表
，這將在下面介紹。
注意：一些編譯器將忽略這個值。
PointerToSymbolTable 及 NumberOfSymbols：用在調試信息中，我不太清楚它們的用途
，不過發現它們總為0。
SizeOfOptionalHeader：可選頭的長度（sizeof IMAGE_OPTIONAL_HEADER）你可以用它
來檢驗PE文件的正確性。
Characteristics：是一個標志的集合，其中大部分的位用在目標文件（OBJ）或庫文件
（LIB）中：
Bit 0 (IMAGE_FILE_RELOCS_STRIPPED)：置1表示文件中沒有重定向信息。每個段都
有它們自己的重定向信息。這個標志在可執行文件中沒有使用，在可執行文件中是用一個叫做
基址重定向目錄表來表示重定向信息的，這將在下面介紹。
Bit 1 (IMAGE_FILE_EXECUTABLE_IMAGE)：置1表示該文件是可執行文件（也就是說
不是一個目標文件或庫文件）。
Bit 2 (IMAGE_FILE_LINE_NUMS_STRIPPED)：置1表示沒有行數信息；在可執行文件
中沒有使用。
Bit 3 (IMAGE_FILE_LOCAL_SYMS_STRIPPED)：置1表示沒有局部符號信息；在可執行
文件中沒有使用。
Bit 4 (IMAGE_FILE_AGGRESIVE_WS_TRIM)：
Bit 7 (IMAGE_FILE_BYTES_REVERSED_LO)
Bit 15 (IMAGE_FILE_BYTES_REVERSED_HI)：表示文件的位元組順序如果不是機器所期
望的，那麼在讀出之前要進行交換。在可執行文件中它們是不可信的（操作系統期望按正確的
位元組順序執行程序）。
Bit 8 (IMAGE_FILE_32BIT_MACHINE)：表示希望機器為32位機。這個值永遠為1。
Bit 9 (IMAGE_FILE_DEBUG_STRIPPED)：表示沒有調試信息，在可執行文件中沒有使
用。
Bit 10 (IMAGE_FILE_REMOVABLE_RUN_FROM_SWAP)：置1表示該程序不能運行於可移
動介質中（如軟碟機或CD-ROM）。在這種情況下，OS必須把文件拷貝到交換文件中執行。
Bit 11 (IMAGE_FILE_NET_RUN_FROM_SWAP)：置1表示程序不能在網上運行。在這種
情況下，OS必須把文件拷貝到交換文件中執行。
Bit 12 (IMAGE_FILE_SYSTEM)：置1表示文件是一個系統文件例如驅動程序。在可執
行文件中沒有使用。
Bit 13 (IMAGE_FILE_DLL)：置1表示文件是一個動態鏈接庫（DLL）。
Bit 14 (IMAGE_FILE_UP_SYSTEM_ONLY)：表示文件被設計成不能運行於多處理器系
統中。

四、可選頭（Optional Header）
文件頭下面就是可選頭，這是一個叫做IMAGE_OPTIONAL_HEADER的結構。它包含很多關於
PE文件定位的信息。下面分別介紹：
typedef struct _IMAGE_OPTIONAL_HEADER {
//
// Standard fields.
//
WORD Magic; //0x18
BYTE MajorLinkerVersion; //0x1a
BYTE MinorLinkerVersion; //0x1b
DWORD SizeOfCode; //0x1c
DWORD SizeOfInitializedData; //0x20
DWORD SizeOfUninitializedData; //0x24
DWORD AddressOfEntryPoint; //0x28
DWORD BaseOfCode; //0x2c
DWORD BaseOfData; //0x30
//
// NT additional fields.
//
DWORD ImageBase; //0x34
DWORD SectionAlignment; //0x38
DWORD FileAlignment; //0x3c
WORD MajorOperatingSystemVersion; //0x3e
WORD MinorOperatingSystemVersion; //0x40
WORD MajorImageVersion; //0x42
WORD MinorImageVersion; //0x44
WORD MajorSubsystemVersion; //0x46
WORD MinorSubsystemVersion; //0x48
DWORD Win32VersionValue; //0x4c
DWORD SizeOfImage; //0x50
DWORD SizeOfHeaders; //0x54
DWORD CheckSum; //0x58
WORD Subsystem; //0x5c
WORD DllCharacteristics; //0x5e
DWORD SizeOfStackReserve; //0x60
DWORD SizeOfStackCommit; //0x64
DWORD SizeOfHeapReserve; //0x68
DWORD SizeOfHeapCommit; //0x6c
DWORD LoaderFlags; //0x70
DWORD NumberOfRvaAndSizes; //0x74
IMAGE_DATA_DIRECTORY DataDirectory[IMAGE_NUMBEROF_DIRECTORY_ENTRIES];
} IMAGE_OPTIONAL_HEADER, *PIMAGE_OPTIONAL_HEADER;

Magic：這個值好象總是0x010b。
MajorLinkerVersion及MinorLinkerVersion：鏈接器的版本號，這個值不太可靠。
SizeOfCode：可執行代碼的長度。
SizeOfInitializedData：初始化數據的長度（數據段）。
SizeOfUninitializedData：未初始化數據的長度（bss段）。
AddressOfEntryPoint：代碼的入口RVA地址，程序從這兒開始執行。
BaseOfCode：可執行代碼起始位置，意義不大。
BaseOfData：初始化數據起始位置，意義不大。
ImageBase：載入程序首選的RVA地址。這個在址可被Loader改變。
SectionAlignment：段載入後在內存中的對齊方式。
FileAlignment：段在文件中的對齊方式。
MajorOperatingSystemVersion及MinorOperatingSystemVersion：操作系統版本，Load
er並沒有用它。
MajorImageVersion及MinorImageVersion：程序版本。
MajorSubsystemVersion及MinorSubsystemVersion：子系統版本號，這個域系統支持；
例如：如果程序運行於NT下，子系統版本號如果不是4.0的話，對話框不能顯示3D風格。
Win32VersionValue：這個值好象總是為0。
SizeOfImage：程序調入後佔用內存大小（位元組），等於所有段的長度之和。
SizeOfHeaders：所有文件頭的長度之和，它等於從文件開始到第一個段的原始數據之間
的大小。
CheckSum：校驗和。它僅用在驅動程序中，在可執行文件中可能為0。它的計算方法Mic
rosoft不公開，在imagehelp.dll中的CheckSumMappedFile()函數可以計算它。
Subsystem：NT子系統，可能是以下的值：
IMAGE_SUBSYSTEM_NATIVE (1)
不需要子系統。用在驅動程序中。
IMAGE_SUBSYSTEM_WINDOWS_GUI(2)
WIN32 graphical程序（它可用AllocConsole()來打開一個控制台，但是不能在
一開始自動得到）。
IMAGE_SUBSYSTEM_WINDOWS_CUI(3)
WIN32 console程序（它可以一開始自動建立）。
IMAGE_SUBSYSTEM_OS2_CUI(5)
OS/2 console程序（因為程序是OS/2格式，所以它很少用在PE）。
IMAGE_SUBSYSTEM_POSIX_CUI(7)
POSIX console程序。
Windows95程序總是用WIN32子系統，所以只有2和3是合法的值。
DllCharacteristics：Dll狀態。
SizeOfStackReserve：保留堆棧大小。
SizeOfStackCommit：啟動後實際申請的堆棧數，可隨實際情況變大。
SizeOfHeapReserve：保留堆大小。
SizeOfHeapCommit：實際堆大小。
LoaderFlags：好象沒有用。
NumberOfRvaAndSizes：下面的目錄表入口個數，這個值也不可靠，你可用常數IMAGE_N
UMBEROF_DIRECTORY_ENTRIES來代替它，值好象總等於16。
DataDirectory：是一個IMAGE_DATA_DIRECTORY數組，數組元素個數為IMAGE_NUMBEROF_
DIRECTORY_ENTRIES，結構如下：
typedef struct _IMAGE_DATA_DIRECTORY {
DWORD VirtualAddress;
DWORD Size;
} IMAGE_DATA_DIRECTORY, *PIMAGE_DATA_DIRECTORY;
VirtualAddress：起始RVA地址。
Size：長度。
每一個目錄表代表以下的值：
IMAGE_DIRECTORY_ENTRY_EXPORT (0)
IMAGE_DIRECTORY_ENTRY_IMPORT (1)
IMAGE_DIRECTORY_ENTRY_RESOURCE (2)
IMAGE_DIRECTORY_ENTRY_EXCEPTION (3)
IMAGE_DIRECTORY_ENTRY_SECURITY (4)
IMAGE_DIRECTORY_ENTRY_BASERELOC (5)
IMAGE_DIRECTORY_ENTRY_DEBUG (6)
IMAGE_DIRECTORY_ENTRY_COPYRIGHT (7)
IMAGE_DIRECTORY_ENTRY_GLOBALPTR (8)
IMAGE_DIRECTORY_ENTRY_TLS (9)
IMAGE_DIRECTORY_ENTRY_LOAD_CONFIG (10)
IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT (11)
IMAGE_DIRECTORY_ENTRY_IAT (12)

⑵ pe文件的簡介

一個操作系統的可執行文件格式在很多方面是這個系統的一面鏡子。雖然學習一個可執行文件格式通常不是一個程序員的首要任務，但是你可以從這其中學到大量的知識。在這篇文章中，我會給出 Microsoft 的所有基於win32系統（如winnt,win9x）的可移植可執行（PE）文件格式的詳細介紹。在可預知的未來，包括Windows2000, PE文件格式在 MicroSoft 的操作系統中扮演一個重要的角色。如果你在使用 Win32 或 Winnt ，那麼你已經在使用 PE 文件了。甚至你只是在 Windows3.1 下使用 Visual C++編程，你使用的仍然是 PE 文件（Visual C++ 的 32 位MS-DOS擴展組件用這個格式）。簡而言之，PE 格式已經普遍應用，並且在不短的將來仍是不可避免的。現在是時候找出這種新的可執行文件格式為操作系統帶來的東西了。 我最後不會讓你盯住無窮無盡的十六進制Dump，也不會詳細討論頁面的每一個單獨的位的重要性。代替的，我會向你介紹包含在 PE 文件中的概念，並且將他們和你每天都遇到的東西聯系起來。比如，線程局部變數的概念，如下所述：
declspec(thread) int i;
我快要發瘋了，直到我發現它在可執行文件中實現起來是如此的簡單並且優雅。既然你們中的許多人都有使用 16 Windows 的背景，我將把 Win32 PE 文件的構造追溯到和它等價的16 位 NE 文件。
除了一個不同的可執行文件格式， MicroSoft 還引入了一個用它的編譯器和匯編器生成的新的目標模塊格式。這個新的 OBJ 文件格式有許多和PE 文件共同的東東。我做了許多無用功去查找這個新的OBJ 文件格式的文檔。所以我以自己的理解對它進行解析，並且，在這里，除了 PE 文件，我會描述它的一部分。 大家都知道，Windows NT繼承了 VAX? VMS? 和 UNIX? 的傳統。許多 Windows NT 的創始人在進入微軟前都在這些平台上進行設計和編碼。當他們開始設計 Windows NT 時，很自然的，為了最小化項目啟動時間，他們會使用以前寫好的並且已經測試過的工具。用這些工具生成的並且工作的可執行和 OBJ 文件格式叫做 COFF （Common Object File Format 的首字母縮寫）。COFF 的相對年齡可以用八進制的域來指定。COFF 本身是一個好的起點，但是需要擴展到一個現代操作系統如 Windows 95 和 Windows NT 的需要。這個更新的結果就是（PE格式）可移植可執行文件格式。它被稱為可移植的是因為在所有平台（如x86,Alpha,MIPS等等）上實現的WindowsNT 都使用相同的可執行文件格式。當然了，也有許多不同的東西如二進制代碼的CPU指令。重要的是操作系統的裝入器和程序設計工具不需要為任何一種CPU完全重寫就能達到目的。
MicroSoft 拋棄現存的32位工具和可執行文件格式的事實證實了他們想讓 WindowsNT 升級並且運行的更快的決心。為16位Windows編寫的虛擬設備驅動程序用一種不同的32位文件布局--LE文件格式--WindowsNT出現很早以前就存在了。比這更重要的是對 OBJ 文件的替換！在 WindowsNT 的 C編譯器以前，所有的微軟編譯器都用 Intel 的 OMF ( Object Mole Format ) 規范。就像前面提到的，MicroSoft 的 Win32編譯器生成 COFF 格式的 OBJ 文件。一些微軟的競爭者，如 Borland 和 Symentec ，選擇放棄了 COFF 格式並堅持 Intel 的 OMF文件格式。這樣的結果是製作 OBJ 和 LIB 的公司為了使用多個不同的編譯器，不得不為每個不同的編譯器分發這些庫的不同版本（如果他們不這么做）。
PE 文件格式在 winnt.h 頭文件中文檔化了（用最不精確的語言）!大約在 winnt.h 的中間部分標題為Image Format的一個塊。在把 MS-DOS 的 MZ文件頭和 NE 文件頭移入新的PE文件頭之前，這個塊就開始於一個小欄。WINNT.H提供PE文件用到的生鮮數據結構的定義，但只有很少有助於理解這些數據結構和標志變數的注釋。不管誰為PE文件格式寫出這樣的頭文件都肯定是一個信徒無疑（突然持續地冒出Michael J. O'Leary的名字來）。描述名字，連同深嵌的結構體和宏。當你配套winnt.h進行編碼時，類似下面這樣的表達式並不鮮見：
pNTHeader->OptionalHeader.DataDirectory[IMAGE_DIRECTORY_ENTRY_DEBUG]
.VirtualAddress;
為了有助於邏輯的理解這些winnt.h中的信息，閱讀可移植可執行和公共對象文件格式的規格說明，這些在MSDN既看光碟中是可用的，一直包括到2001年8月。
現在讓我們轉換到COFF格式的OBJ文件的主體上來，WINNT.H包括COFF OBJ和LIB的結構化定義和類型定義。不幸的是，我還沒有找到上面提到的可執行文件格式的類似文檔。既然PE文件和COFF OBJ文件是如此的相似，我決定是時間把這些文件帶到重點上來，並且把它們也文檔化。僅僅讀過了關於PE文件的組成，你自己也想Dump一些PE文件來看這些概念。如果你用微軟基於32位WINDOWS的開發工具，DUMPBIN 程序可以將PE文件和COFF OBJ/LIB文件轉化為可讀的形式。在所有的PEDump器中，DUMPBIN是最容易理解的。它恰好有一些很好的選項來反匯編它正解析的文件的代碼塊，Borland用戶可以使用tmp來瀏覽PE文件，但tmp不能解析 COFF OBJ/LIB 文件。這不是一個重要的東西因為Borland的編譯器首先就不生成 COFF 格式的OBJ文件。
我寫了一個PE和COFF OBJ 文件的Dump程序--PEDUMP，我想提供一些比DUMPBIN更加可理解的輸出。雖然它沒有反匯編器以及和LIB庫文件一起工作，它在其他方面和DUMPBIN是一樣的，並且加入了一些新的特性來使它值得被認同。它的源代碼在任何一個MSJ電子公報版上都可以找到，所有我不打算在這里把他全部列出。作為代替，我展示一些從PEDUMP得到的示例輸出來闡明我為它們描述的概念。
譯註：--說實話，我從這這份代碼中幾乎唯一學到的東西就是如何處理命令行，其它的都沒學到。 表 1 PEDUMP.C
file://--------------------/ //PROGRAM:PEDUMP//FILE:PEDUMP.C//AUTHOR:MattPietrek-1993file://--------------------/#include<windows.h>#include<stdio.h>#includeobjmp.h#includeexemp.h#includeextrnvar.h//Globalvariablessethere,ansedinEXEDUMP.CandOBJDUMP.CBOOLfShowRelocations=FALSE;BOOLfShowRawSectionData=FALSE;BOOLfShowSymbolTable=FALSE;BOOLfShowLineNumbers=FALSE;charHelpText[]=PEDUMP-Win32/COFF.EXE/.OBJfilemper-1993MattPietrek Syntax:PEDUMP[switches]filename /Aincludeeverythinginmp /Hincludehexmpofsections /Lincludelinenumberinformation /Rshowbaserelocations /Sshowsymboltable ;//Openupafile,memorymapit,(LPSTRfilename)HANDLEhFile;HANDLEhFileMapping;LPVOIDlpFileBase;PIMAGE_DOS_HEADERdosHeader;hFile=CreateFile(filename,GENERIC_READ,FILE_SHARE_READ,NULL,OPEN_EXISTING,FILE_ATTRIBUTE_NORMAL,0);if(hFile==INVALID_HANDLE_VALUE){printf(Couldn'topenfilewithCreateFile() );return;}hFileMapping=CreateFileMapping(hFile,NULL,PAGE_READONLY,0,0,NULL);if(hFileMapping==0){CloseHandle(hFile);printf(Couldn'() );return;lpFileBase=MapViewOfFile(hFileMapping,FILE_MAP_READ,0,0,0);if(lpFileBase==0)CloseHandle(hFileMapping);CloseHandle(hFile);printf(Couldn'() );return;printf(Dumpoffile%s ,filename);dosHeader=(PIMAGE_DOS_HEADER)lpFileBase;if(dosHeader->e_magic==IMAGE_DOS_SIGNATURE){DumpExeFile(dosHeader);}elseif((dosHeader->e_magic==0x014C)//Doesitlooklikeai386&&(dosHeader->e_sp==0))//COFFOBJfile???//Thetwotestsabovearen'twhattheylooklike.They're//reallycheckingforIMAGE_FILE_HEADER.Machine==i386(0x14C)//andIMAGE_FILE_HEADER.SizeOfOptionalHeader==0;DumpObjFile((PIMAGE_FILE_HEADER)lpFileBase);elseprintf(unrecognizedfileformat );UnmapViewOfFile(lpFileBase);CloseHandle(hFileMapping);CloseHandle(hFile);////thefilenameargument.PSTRProcessCommandLine(intargc,char*argv[])inti;for(i=1;i<argc;i++)strupr(argv);//Isitaswitchcharacter?if((argv[0]=='-')||(argv[0]=='/'))if(argv[1]=='A'){fShowRelocations=TRUE;fShowRawSectionData=TRUE;fShowSymbolTable=TRUE;fShowLineNumbers=TRUE;}elseif(argv[1]=='H')fShowRawSectionData=TRUE;elseif(argv[1]=='L')fShowLineNumbers=TRUE;elseif(argv[1]=='R')fShowRelocations=TRUE;elseif(argv[1]=='S')fShowSymbolTable=TRUE;else//Notaswitchcharacter.Mustbethefilename{returnargv;}intmain(intargc,char*argv[])PSTRfilename;if(argc==1){printf(HelpText);return1;}filename=ProcessCommandLine(argc,argv);if(filename)DumpFile(filename);return0;}

⑶ PE系統的系統文件在哪個文件夾里

選擇「開始→運行」，在運行對話框中鍵入「chkntfs /t:0」，即可將磁碟掃描等待...關於chkdsk這個命令的使用問題 以下文字為Ctangel總結整理，均為日常工作中所遇到的已經經過證實的方法，並非網路復制的純理論的東西。有想轉載請註明出處，謝謝合作。 相信很多網友在電腦使用過程中收到過這樣的提示，任務欄右下角出來一個小提示，說你的某個文件已經損壞，請運行chkdsk修復。其實這個工具是很強大的，不過不好意思對此類問題無效。那麼遇到這個問題該如何解決和這個chkdsk到底能幹什麼用請看我下面闡述。一、遇到任務欄右下角提示有文件損壞要求運行chkdsk修復的情況 比如我的機器提示C:\Documents and Settings\pifd\Local Settings\Application Data\Microsoft\Outlook\test.mxl這個文件損壞，這種情況的產生有三種可能： 1、非正常關機 2、病毒造成的破壞 3、硬碟問題（經常頻繁的出現不同的文件損壞就可以判定為硬碟有壞道了） 這個問題的解決方法是直接進入那個目錄，刪除那個文件，比如我舉的這個例子，我就直接打開我的電腦點進C:\Documents and Settings\pifd\Local Settings\Application Data\Microsoft\Outlook\這個目錄里，把test.mxl刪掉 就好了。可是問題來了，一般它報的文件基本上都在系統的配置文件夾里，Local Settings這一層目錄是隱藏的，那麼您可以選擇在我的電腦的地址欄裡面直接輸入整個目錄然後回車就可以進去了，或者我的電腦之後點擊工具-文件夾選項-查看 裡面有兩個設置 隱藏受保護的系統文件 前面的勾去掉，在選擇下面的顯示所有文件，然後應用確定就可以看到隱藏文件了。 一般情況下刪除完有問題的文件是不會造成軟體故障的，因為它損壞的多半是備份文件或者配置文件這類隨軟體啟動就會改寫的文件。如果影響了該軟體使用，那麼重新安裝這個軟體就好了。二、CHKDSK這個命令到底能幹什麼用？ 這個工具其實挺強大的，可以用來修復磁碟或者卷的問題。我還遇到過機器運行特別慢，重做系統後過了一個月半個月的又特別慢的情況然後用這個命令修復好了。 這個命令的使用，前提是你的系統里這個目錄下windows\system32\autochk.exe有這個文件。不然該命令無法運行。 下面舉例該命令的使用方法 1、機器開機藍屏0X000000ED 這個藍屏代碼是典型的硬碟或者卷的問題造成的藍屏，一般到這時候安全模式也進不去了。那麼這個問題怎麼修復呢，這時候最古老的系統安裝盤就起作用了，是原版的安裝盤哦，可不是ghost的那種，把光碟放入到光碟機，引導啟動系統安裝，到安裝界面的時候選擇按R進入控制台修復，進入控制台之後會停在 C：\windows\提示符下，這里我們就輸入 chkdsk -r就可以開始修復錯誤了，中間會有一段時間運行特別慢，根本就不動，這時候一定要耐心等待千萬不要以為是死機了而重新啟動，修復完成後重新啟動計算機，就可以進入系統了，進入之後建議先殺毒，然後重新啟動測試，如果重新啟動就不會再出了，那就是卷的問題，如果還出這個代碼，那說明硬碟有壞道了，硬體問題，可以換硬碟，或者把初始刪除分成一個小區不使用。 2、這個命令參數很多 /F /R如何選擇 系統出問題會提示你用chkdsk /F 修復，但是我要告訴你，請用/R,因為/R這個參數包含/F的功能，/F修不好的時候/R或許能管用，所以不要浪費時間直接用參數R。 3、使用chkdsk修復的時候提示修復無法完成 至今我只遇到過一次，問題比較嚴重，就是那個機器運行慢的，這時候可以嘗試不帶任何參數的線運行chkdsk。讓它檢測一遍如果它能檢測完，就可以加上參數/R 了，如果還不行，那麼在不帶參數運行之後再加上/F 運行一次。 4、其他 其實除了0X000000ED之外還有一些硬碟引起的藍屏代碼是可以用這個命令修復的。但並不像0X000000ED那樣100%管用。 如果你沒有系統盤裝盤也沒有關系，現在有些PE就帶控制台修復，比如很古老的深山紅葉，還有金手指V6啟動界面上就有這項的。不過運行pe進入控制台修復的時候默認的C盤可是pe的系統盤哦，至於哪個是你的C盤自己找吧，可能是D盤也可能是E盤，在目前提示符下輸入D：或者E:回車，然後輸入dir能列出目錄的就不是，報錯的就是。 注意哦： 系統能啟動的時候運行這個命令。 點擊開始，運行，輸入cmd。在彈出的command窗口中輸入 chkdsk空格（你想要檢測的盤符比如D盤就輸入D:空格 -r 然後回車。會提示是否強制卸下改卷，輸入y回車。很多朋友不知道這是什麼意思，不敢輸入y這里其實不必害怕的。如果是C盤還會提示 因為另一個過程正在使用這個卷，無法運行chkdsk..是否計劃在下次系統重新啟動時檢查這個卷？ 這里也是要輸入y的，然後重啟電腦，啟動系統的時候會像沒正常關機一樣停在一個淺藍色界面上，這里不要按鍵跳過哦，讓它檢測，因為咱們是用的-r參數，所以時間會比每次的長一些，大家仔細觀察就會發現平時不正常關機是檢測修復三步，加上這個-r參數就變成了5步。
請採納答案，支持我一下。

⑷ 免殺 特徵碼定位在了pe文件頭上 怎麼修改

PE頭可以移位的，但一般不能免殺。特徵碼定位在pe頭是定位錯誤，修改定位方式（反向定位，規定定位起始位置）重新定位，再修改吧。

⑸ 文件的文頭是哪個位置

文件頭是位於文件開頭的一段承擔一定任務的數據，一般都在開頭的部分。頭文件作為一種包含功能函數、數據介面聲明的載體文件，用於保存程序的聲明(declaration)，而定義文件用於保存程序的實現 (implementation)。

常見文件的文件頭：

jpg: 255,216

gif: 71,73

bmp: 66,77

png: 137,80

doc: 208,207

docx: 80,75

xls: 208,207

xlsx: 80,75

js: 239,187

swf: 67,87

mp3: 73,68

wma: 48,38

mid: 77,84

rar: 82,97

zip: 80,75

xml: 60,63