⑴ 什么是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 directory ），那你就会在数据目录表中找到一个为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 0x1560在这个段的0x560处。你又发现这个段在文件中以512字节方式对齐并且.code开始于文件0x800处，那现在你知道了可执行程序开始于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） 的成员来找到它。在OS/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：操作系统版本，Loader并没有用它。 MajorImageVersion及MinorImageVersion：程序版本。 MajorSubsystemVersion及MinorSubsystemVersion：子系统版本号，这个域系统支持；例如：如果程序运行于NT下，子系统版本号如果不是4.0的话，对话框不能显示3D风格。 Win32VersionValue：这个值好象总是为0。 SizeOfImage：程序调入后占用内存大小（字节），等于所有段的长度之和。 SizeOfHeaders：所有文件头的长度之和，它等于从文件开始到第一个段的原始数据之间的大小。 CheckSum：校验和。它仅用在驱动程序中，在可执行文件中可能为0。它的计算方法Microsoft不公开，在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_NUMBEROF_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.Cfile://——————–/ //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
