PE文件结构(二)
|
七、节目录（Section directories）
--------------------------------- 节由两个主要部分组成：首先，是一个节描述(IMAGE_SECTION_HEADER[意为“节头”]类型的)，然后是原始的节数据。因此，我们会在数据目录后发现一“NumberOfSections”个节头组成的数组，它们按照各节的RVA排序。 节头包括： 1）一个IMAGE_SIZEOF_SHORT_NAME (8)（意为“短名的大小”）个字节的数组，形成节的名称（ASCII形式）。如果所有的8位都被用光，该字符串就没有0结束符！典型的名称象“.data”或“.text”或“.bss”形式。开头的“.”不是必须的，名称也可能为“CODE”或“IAT”或类似的形式。 请注意：并不是所有的名称都和节中的内容相关。一个名叫“.code”的节可能包含也可能不包含可执行代码；它还可能只包含输入地址表；它也可能包含代码“和”地址表“和”未初始化数据。要找到节中的信息，你必须通过可选头的数据目录来查询它。既不要过分相信它的名称，也不要以为节的原始数据会从节的开头就开始。 2）IMAGE_SECTION_HEADER（“节头”）的下一个成员是一个32位的、“PhysicalAddress（物理地址）”和“VirtualSize（虚拟大小）”组成的共用体。在目标文件中，它是内容重定位到的地址；在可执行文件中，它是内容的大小。事实上，此域似乎没被使用；因为有的链接器输入大小，有的链接器输入地址，我还发现有一个链接器输入0，而所有的可执行文件都运行如风。 3）下一个成员是“VirtualAddress（虚拟地址）”，是一个32位的值，用来保存载入RAM（内存）后，节中数据的RVA。 4）然后，我们到了32位的“SizeOfRawData”（意味“原始数据大小”），它表示节中数据被大约到下一个“FileAlignment”的整数倍时节的大小。 5）下一个是“PointerToRawData”（意味“原始数据指针”，32位），它特别有用，因为它是从文件的开头到节中数据的偏移量。如果它为0，那么节的数据就不包含在文件中，并且要在载入时才定。 6-9）然后，我们得到“PointerToRelocations”（意味“重定位指针”，32位）和“PointerToLinenumbers”（意味“行数指针”，也是32位），以及“NumberOfRelocations”（意味“重定位数”，16位）和“NumberOfLinenumbers”（意味“行数数”，也是16位）。所以这些都是只用于目标文件的信息。可执行文件拥有一个特殊的基址重定位目录，并且行数信息（如果真的存在的话）通常包含在有一个特殊目的的调试段中或者别的什么地方。 10）节头的最后一个成员是32位的“Characteristics”（意味“特性”），它是一串描述节的内存如何被处理的标志： 如果位5 IMAGE_SCN_CNT_CODE（含有代码的节)被置1，表示节中包含可执行代码。 如果位6 IMAGE_SCN_CNT_INITIALIZED_DATA（含有初始化数据的节)被置1，表示节中包含执行开始前即取得已定义值的数据。换言之：文件中节的数据就是有意义的。 如果位7 IMAGE_SCN_CNT_UNINITIALIZED_DATA（含有未初始化数据的节)被置1， 表示节中包含未初始化数据，并需于执行开始前被初始化为全0。这通常是BSS节。 如果位9 IMAGE_SCN_LNK_INFO（链接器信息节)被置1， 表示节中不包含映象数据，只有一些注释、描述或者其他的文档。这些信息是目标文件的一部分，并有可能是提供给链接器的信息，比如需要哪些库文件。 如果位11 IMAGE_SCN_LNK_REMOVE（链接可删除节)被置1，表示数据是目标文件的、被预定于可执行文件被链接后丢弃掉的节的一部分。常和位9连用。 如果位12 IMAGE_SCN_LNK_COMDAT（链接通用块节)被置1， 表示节中包含“common block data”（通用块数据），也即某种形式的打包函数。 如果位15 IMAGE_SCN_MEM_FARDATA（内存远程数据节)被置1，表示我们拥有远程数据----意味着什么。此位的含义不明。 如果位17 IMAGE_SCN_MEM_PURGEABLE（内存可清除节)被置1， 表示节中的数据可清除----但我认为它和“可丢弃”不是一回事，可丢弃拥有自己的标志位，参见后面。同样，它也明显的不是用来指示16位信息的，因为它也有一个IMAGE_SCN_MEM_16BIT定义。此位的含义不明。 如果位18 IMAGE_SCN_MEM_LOCKED（内存被锁节)被置1， 表示节不应该被从内存中移除？抑或表明没有重定位信息？此位的含义不明。 如果位19 IMAGE_SCN_MEM_PRELOAD（内存预载入节)被置1，表示节在执行开始前应该被页载入？此位的含义不明。 位20至23 指定我没有找到信息的对齐。诸如#defines IMAGE_SCN_ALIGN_16BYTES之类。我曾经见过的唯一值为0，是16位的缺省对齐。 我怀疑它们是库之类文件的目标对齐。 如果位24 IMAGE_SCN_LNK_NRELOC_OVFL（链接扩展重定位节)被置1，表示节中包含一些我不知道的扩展重定位。 如果位25 IMAGE_SCN_MEM_DISCARDABLE（内存可丢弃节)被置1，表示节中的数据在进程启动后就不需要了。它是，举例来说，含有重定位信息的情况。我曾经见过它也用于只执行一次的驱动和服务程序的启动例程，还用于输入目录。 如果位26 IMAGE_SCN_MEM_NOT_CACHED（内存不缓存节)被置1，表示节中的数据不应该被缓存。不要问我为什么不。这是不是意味着关掉2级缓存？ 如果位27 IMAGE_SCN_MEM_NOT_PAGED（内存不可页换出节)被置1，表示节中的数据不应该页换出。它对驱动程序有意义。 如果位28 IMAGE_SCN_MEM_SHARED（内存共享节)被置1，表示节中的数据在映象文件的所有正在运行的实例中共享。如果它是，例如DLL文件的未初始化数据，那么DLL的所有正在运行的实例程序在任何时候都将拥有相同的变量内容。 注意：只有第一个实例的节被初始化。 含有代码的节总是被共享写时拷贝（copy-on-write）（亦即：如果重定位必不可少，那么共享就不工作）。（译注：“写时拷贝”的译法也许根本就是错误的，但我一时找不到更准确的翻译，也不清楚其具体含义，只能以此充数了。希望知情着指点。） 如果位29 IMAGE_SCN_MEM_EXECUTE（内存可执行节)被置1，表示进程对节的内存有“执行”的存取权限。 如果位30 IMAGE_SCN_MEM_READ（内存可读节)被置1，表示进程对节的内存有“读”的存取权限。 如果位31 IMAGE_SCN_MEM_WRITE（内存可写节)被置1，表示进程对节的内存有“写”的存取权限。 在节头之后，我们就会发现节本身。在文件中，它们按照“FileAlignment”（文件对齐）的字节数对齐（也就是说，在可选头之后和每个节的数据之后将要填充一些字节）并按照它们的RVA排序。在载入后（内存中）， 它们按照“SectionAlignment”（节对齐）的字节数对齐。 试举一例，如果可选头在文件的偏移量981处结束，“FileAlignment”（文件对齐）的值为512，那么第一个节将于1024字节处开始。注意：你可通过“PointerToRawData”（原始数据指针）或者“VirtualAddress”（虚拟地址）的值来找到各节，因此实际上根本没必要在对齐上小题大做。 试画映象文件的全图如下： +-------------------+ | DOS-根 | +-------------------+ | 文件头 | +-------------------+ | 可选头 | |- - - - - - - - - -| | |----------------+ | 数据目录 | | | | | | (指向节中 |-------------+ | | 目录的RVA) | | | | |---------+ | | | | | | | +-------------------+ | | | | |-----+ | | | | 节头 | | | | | | (指向节 |--+ | | | | | 边界的RVA) | | | | | | +-------------------+<-+ | | | | | | | <-+ | | | 节数据 1 | | | | | | | <-----+ | +-------------------+<----+ | | | | | 节数据 2 | | | | <--------------+ +-------------------+ 每个节都有一个节头，并且每个数据目录都会指向其中的一个节（几个数据目录有可能指向同一个节，而且也可能有的节没有数据目录指向它们）。 八、节的原始数据（Sections' raw data） -------------------------------------- 1.概述（general） ------- 所有的节在载入内存后都按“SectionAlignment”（节对齐）对齐，在文件中则以“FileAlignment”（文件对齐）对齐。节由节头中的相关项来描述：在文件中你可通过“PointerToRawData”（原始数据指针）来找到，在内存中你可通过“VirtualAddress”（虚拟地址）来找到；长度由“SizeOfRawData”（原始数据长度）决定。 根据节中包含的内容，可分为好几种节。大多数（并非所有）情况下，节中至少由一个数据目录，并在可选头的数据目录数组中有一个指针指向它。 2.代码节（code section） ------------------------ 首先，我将提到代码节。此节，至少，要将“IMAGE_SCN_CNT_CODE”（含有代码节）、“IMAGE_SCN_MEM_EXECUTE”（内存可执行节）和“IMAGE_SCN_MEM_READ”（内存可读节）等标志位设为1，并且“AddressOfEntryPoint”（入口点地址）将指向节中的某个地方，指向开发者希望首先执行的那个函数的开始处。 “BaseOfCode”（代码基址）通常指向这一节的开始处，但是，如果一些非代码字节被放在代码之前的话，它也可能指向节中靠后的某个地方。 通常，除了可执行代码外，本节没有别的东东，并且通常只有一个代码节，但是不要太迷信这一点。 典型的节名有“.text”、“.code”、“AUTO”之类。 3.数据节（data section） ------------------------ 我们要讨论的下一件事情就是已初始化变量；本节包含的是已初始化的静态变量（象“static int i = 5;”）。它将，至少，使“IMAGE_SCN_CNT_INITIALIZED_DATA”（含有已初始化数据节）、“IMAGE_SCN_MEM_READ”（内存可读节）和“IMAGE_SCN_MEM_WRITE”（内存可写节）等标志位被置为1。 一些链接器可能会将常量放在没有可写标志位的它们自己的节中。如果有一部分数据可共享，或者有其它的特定情况，那么可能会有更多的节，且它们的合适的标志位会被设置。 不管是一节，还是多节，它们都将处于从“BaseOfData”（数据基址）到“BaseOfData”+“SizeOfInitializedData”（数据基址+已初始化数据的大小）的范围之内。 典型的名称有“.data”、“.idata”、“DATA”、等等。 4.BSS节（bss section） ---------------------- 其后就是未初始化的数据（一些象“static int k;”之类的静态变量）；本节十分象已初始化的数据，但它的“PointerToRawData”（文件偏移量）却为0，表明它的内容不存储在文件中；并且“IMAGE_SCN_CNT_UNINITIALIZED_DATA”（含有未初始化数据节）而不是“IMAGE_SCN_CNT_INITIALIZED_DATA”（含有已初始化数据节）标志位被置为1，表明在载入时它的内容应该被置为0。这就意味着，在文件中只有节头，没有节身；节身将由加载器创建，并全部为0字节。 它的长度由“SizeOfUninitializedData”（未初始化数据大小）确定。 典型的名称有“.bss”、“BSS”之类。 有些节数据“没有”被数据目录指向。它们的内容和结构是由编译器而不是链接器提供。 （栈段和堆段不是二进制文件中的节，它们是由加载器根据可选头中的栈大小和堆大小项来创建的。） 5.版权（copyright） ------------------- 为了从一个简单的目录节开始讲解，让我们来看一看数据目录“IMAGE_DIRECTORY_ENTRY_COPYRIGHT”（版权目录项）项。它的内容是一个版权信息或ASCII形式的描述字符串（不是以0结尾的），象“Gonkulator control application, copyright (c) 1848 Hugendubel & Cie”这样。这个字符串，通常，是用命令行或者描述文件提供给链接器的。 这个字符串在运行时并不需要，并可能被丢弃。它是不可写的；事实上，应用程序根本不需要存取它。因此，如果已有一个可丢弃的、非可写的节存在，链接器就会找到它；如果没有，就创建一个（命名为“.descr”之类）。然后它就将那个字符串填入该节中并让版权目录项指针指向这个字符串。“IMAGE_SCN_CNT_INITIALIZED_DATA”（含有已初始化数据节）标志位应置为1。 6.输出符号（exported symbols） ------------------------------ （注意：本文的1993年03月12日之前的各个版本中，输出目录的描述有误。文中没有描述中转、只以序数输出、或者使用好几个名称输出等内容。） 下一件最简单的事情是输出目录，是由“IMAGE_DIRECTORY_ENTRY_EXPORT”（输出目录项）指向的。它是一个典型的在DLL中常见到的目录；包含一些输出函数的入口点（以及输出对象等的地址）。当然可执行文件也可能拥有输出符号但一般没有。 包含它们的节应该有“已初始化数据的”和“可读的”特性。这样的节应该是不可丢弃的，因为在运行时，进程有可能调用“GetProcAddress()”来寻找一个函数的入口点。如果单独成节的话，本节通常被称作“.edata”；更常见的是，它被并入象“已初始化数据”之类的节中。 输出表（“IMAGE_EXPORT_DIRECTORY”）的结构由一个头和输出数据，也就是：符号名称、它们的序号和它们的入口点偏移量等构成。 1）首先，我们有一个没被使用并通常为0的、32位的“Characteristics”（特性）。 2）然后是一个32位的“TimeDateStamp”（时间日期戳），大概是提供此表被创建的time_t格式的时间；天呀，它的值并不总是有效（有些链接器将它设置为0）。 3-4）往后我们看到2个16位的、有关版本信息的word单元（“MajorVersion”和“MinorVersion”，含义分别为‘主版本号’和‘小版本号’），同样，它们很多地被设为0。 5）下一个东东是32位的“Name”（名称）；它是一个指向以0结尾的ASCII字符串为DLL名称的RVA。（为防DLL被改名时的错误，名称是必须的----参见输入目录中的“绑定”部分。） 6）然后是32位的“Base”（基址）。稍后我们再讨论。 7）下一个32位值是输出条目的总数（“NumberOfFunctions”，意为‘函数数’）。除了它们的序数外，各条目还可能使用一个或多个名称来输出。接下来的一个32位数字是输出名称的总数（“NumberOfNames”，意为‘名字数’）。 在大多数情况下，每一个输出条目都准确的有一个相应的名称，并且将用这个名称来使用它；但是一个条目可能拥有好几个相关联的名称（那样它们的每一个名称都可访问）；或者它也可能没有名称，此时它只能以它的序数来访问。无名输出项（只有序数）的使用是不鼓励的，因为此时输出DLL的所有版本都必须使用相同的序数法，而这会造成维护的问题。 8）下一个32位值“AddressOfFunctions”（函数地址）是指向输出条目列表的RVA。它指向一个32位值的“NumberOfFunctions”（函数数）数组，数组的每一项都是一个指向输出函数或变量的RVA。 关于此列表有两个怪事：第一，这样一个输出的RVA竟可能会为0，在此情况下，此值没被使用。第二，如果一RVA指向含有输出目录的节，那么它就是一个中转输出。一个中转输出就是指指向另一个二进制文件中的输出项的指针；如果使用了它，就可用另一个二进制文件中的被指向的输出项来代替使用。此时的RVA指向，正如已提到的，输出目录的节中，指向一个以以零结尾的字符串组成的、被指向的DLL的名称和一个用点分开的输出项的名称，象“otherdll.exportname”这样，或者是DLL的名称和输出序数，象“otherdll.#19”这样。 现在到了解释输出序数的时候了。一个输出项的序数就是函数地址数组中的索引值加上上面提到的“Base”（基址）的值的和。在大多数情况下，“Base”（基址）的值为1，这就意味着第一个输出项的序数为1，第二个输出项的序数为2，以此类推。 9-10）“AddressOfFunctions”（函数地址）RVA之后，我们发现二个RVA，一个指向符号名称的32位RVA的数组“AddressOfNames”（名字的地址），另一个指向16位序数“AddressOfNameOrdinals”（名字序数的地址）的数组。两个数组都有“NumberOfNames”（名字数）个元素。 符号名称可能会全部丢失，此时“AddressOfNames”（名字的地址）为0；否则，被指向的数组并行运行，这意味着它们的每个索引中的元素共同拥有。“AddressOfNames”（名字的地址）数组由以0结尾的输出名称的RVA组成；这些名称以一个分类的列表排列（即：数组的第一个成员是按照字母顺序排列的最小的名称的RVA；这使当按名称查找一个输出符号时，搜索的效率更高。） 根据PE规范，“AddressOfNameOrdinals”（名字序数的地址）数组每个名称拥有一个相应的序数，然而，我发现这个数组却将实际的索引包含到“AddressOfFunctions”（函数地址）数组中去。 我将画一个有关这三个表的图： 函数地址 | | | v 带序数‘基址’的输出RVA 带序数‘基址+1’的输出RVA ... 带序数‘基址+函数数-1’的输出RVA 名字地址 名字序数地址 | | | | | | v v 第一个名字的RVA <-> 第一个名字的输出索引 第二个名字的RVA <-> 第二个名字的输出索引 ... ... 第‘名字数’个名字的RVA <-> 第‘名字数’个名字的输出索引 举一些例子是适宜的。 |
转载于:https://blog.51cto.com/heihu/100624
扫一扫
529
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
