PE文件结构(三)
|
为按序数找到一个输出符号，先减去“Base”（基址）值以得到索引值，再根据“AddressOfFunctions”（函数地址）的RVA得到输出项数组，并用索引值去找到数组中的输出RVA。如果结果没有指向输出节中，你就完了。否则，它就指向那里的一个描述输出DLL和（输出项）名称或序数的字符串，之后你就得在那里查找中转输出。
为按名称找到一个输出符号，先跟随“AddressOfNames”（名字的地址）的RVA（如果是0就没有名称）找到输出名称的RVA数组。在列表中搜寻你要找的名称。用该名称在“AddressOfNameOrdinals”（名字序数的地址）数组中的索引，得到和找到的名称相应的16位数字。根据PE规范，这是一个序数，你需先减去“Base”（基址）值以得到输出索引值；但依据我的经验，这就是输出索引值，你不需要再减了。使用输出索引值，你就能在“AddressOfFunctions”（函数地址）数组中找到输出RVA了，要么是输出RVA本身，要么是一个描述中转输出的字符串的RVA。 7.输入符号（imported symbols） ------------------------------ 当编译器发现一个对别的可执行文件（大多数是DLL文件）中的函数调用时，在最简单化的情况下，它会对此情况一无所知，只是简单地输出一个对那个符号的正常调用指令。链接器不得不修正那个符号的地址，就象它为任何其它的外部符号所做的那样。 链接器使用一个输入库来查找从哪个DLL文件输入了哪个符号，并为所有的输入符号都建立存根，每个存根包含一个跳转指令；存根就是实际的调用目标。这些跳转指令实际上将跳往从所谓的输入地址表中提取的一个地址。在更复杂的应用程序（使用“__declspec(dllimport)”时）中，编译器会知道函数是输入的，并直接输出一个位于输入地址表中的地址的调用，绕过跳转。 不管怎样，DLL文件中的函数地址总是必要的，并将于应用程序载入时，由加载器从输出DLL文件的输出目录中提供。加载器知道哪个库中的哪些符号需要被查找以及哪些地址需要通过搜索输入目录来修正。 我最好给你一个例子。有或无__declspec(dllimport)的调用如下所示： 源文件： int symbol(char *); __declspec(dllimport) int symbol2(char*); void foo(void) { int i=symbol("bar"); int j=symbol2("baz"); } 汇编： ... call _symbol ; 没有declspec(dllimport)的 ... call [__imp__symbol2] ; 含有declspec(dllimport)的 ... 在第一种（没有__declspec(dllimport)）情况下，编译器不知道“_symbol”位于一个DLL文件中，因此链接器必须要提供“_symbol”函数。因为此函数不存在，它就为输入符号提供一个存根函数，即一个间接跳转。所有输入存根的集合被称为“转移区”（有时也叫做“跳板”，因为你跳到那里的目的是为了跳到别的地方）。 典型地，此转移区位于代码节中（它不是输入目录的一部分）。每一个函数存根都是一个跳往DLL文件中的实际函数的跳转。转移区的形式象这样： _symbol: jmp [__imp__symbol] _other_symbol: jmp [__imp__other__symbol] ... 这意味着：如果你不指定“__declspec(dllimport)”来使用输入符号，那么链接器将会为它们产生一个由间接跳转所组成的转移区。如果你真指定了“__declspec(dllimport)”，那么编译器就会自己做间接（跳转），转移区也就不需要了。（这也意味着：如果你输入的是变量或其它东西，你就必须指定“__declspec(dllimport)”，因为一个具有jmp指令的存根只合适于函数。） 不管怎样，符号“x”的地址都被存在“__imp_x”的存储单元。所有这样的存储单元一起形成所谓的“输入地址表”，此表是由被用到的各DLL文件中的输入库提供给链接器的。输入地址表就是由下面这种形式的一组地址组成的： __imp__symbol: 0xdeadbeef __imp__symbol2: 0x40100 __imp__symbol3: 0x300100 ... 这个输入地址表是输入目录的一部分，并且被IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）目录指针所指向（尽管有些链接器不设置此目录项，程序也能运行；很明显地，这是因为加载器不使用IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）目录也能解决输入问题）。 这些地址并不被链接器所知；链接器只插入一些伪地址（函数名称的RVA；参见后面的更多信息），这些伪地址会在载入时被加载器用输出DLL文件中的输出目录来修正。输入地址表，以及它是怎样被加载器找到的，将会在本章的后面被详细讲述。 注意:这个介绍是针对C语言规范的；有些别的应用程序构建环境是不使用输入库的，尽管它们都需要建立一个输入地址表，用来让它们的程序访问输入对象和函数。C语言编译器往往使用输入库，因为无论如何讲，这都有利于它们----它们的链接器使用好库。别的环境使用的是例如：一个列出需要的DLL文件名称和函数名称的描述文件（比如“模块定义文件”），或者一个源文件中的声明形式的列表等。 这就是程序的代码如何使用输入函数的；现在我们再来看看输入目录是如何建立以便加载器使用的。 输入目录应该存在于是“已初始化数据”并且“可读”的节中。 输入目录是一个多IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的数组，每个被使用的DLL文件都有一个。（它们的）列表由一个全部用0填充的IMAGE_IMPORT_DESCRIPTOR（输入地址表目录项）结构作为结束。 一个IMAGE_IMPORT_DESCRIPTOR（输入地址表目录项）是一个拥有下列成员的结构体： OriginalFirstThunk（原始第一个换长）（汉译的说明见注释?） 它是一个RVA（32位），指向一个以0结尾的、由IMAGE_THUNK_DATA（换长数据）的RVA构成的数组，其每个IMAGE_THUNK_DATA（换长数据）元素都描述一个函数。此数组永不改变。 TimeDateStamp（时间日期戳） 它是一个具有好几个目的的32位的时间戳。让我们先假设时间戳为0，一些高级的情况将在以后处理。 ForwarderChain（中转链） 它是输入函数列表中第一个中转的、32位的索引。中转也是高级的东东。对初学者先将所有位设为-1。 Name（名称） 它是一个DLL文件的名称（0结尾的ASCII码字符串）的、32位的RVA。 FirstThunk（第一换长） 它也是一个RVA（32位），指向一个0结尾的、由IMAGE_THUNK_DATA（换长数据）的RVA构成的数组，其每个IMAGE_THUNK_DATA（换长数据）元素都描述一个函数。此数组是输入地址表的一部分，并且可以改变。 因此，数组中的每个IMAGE_IMPORT_DESCRIPTOR（输入描述结构）结构体都给出输出DLL文件的名称，并且，除了中转和时间日期戳，它还给出2个指向IMAGE_THUNK_DATA（换长数据）的数组的RVA，都是32位。（每个数组的最后一个成员都全部填充为0字节，以标志结尾。） 目前看来，每个IMAGE_THUNK_DATA（换长数据）都是一个RVA，指向一个描述输入函数的IMAGE_IMPORT_BY_NAME（输入名字）项。 现在，有趣的是两个数组并行运行，也就是说:它们指向同一组IMAGE_IMPORT_BY_NAME（输入名字）。 没有必要失望，我将再画一图。这里是IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的关键内容： 原始第一个换长 第一个换长 | | | | | | V V 0--> 函数1 <--0 1--> 函数2 <--1 2--> 函数3 <--2 3--> foo <--3 4--> mumpitz <--4 5--> knuff <--5 6-->0 0<--6 /* 最后的RVA是0! */ 图当中的名字就是尚未讨论的IMAGE_IMPORT_BY_NAME（输入名字）。每一个都是一个16位的数字（一个提示）跟着一些数量未定的字节，它们都是以0结尾的、输入符号的ASCII码名字。 提示就是指向输出DLL文件名字表的索引（参见上面的输出目录）。那个索引中的名字将被一一尝试，如果没有相符的，再使用二进制搜索来寻找名字。 （有些链接器不愿意查找正确的提示，总是只简单的将其指定为1，或者其它的随意数字。这并无大害，只是使解决名字的第一次尝试总是失败，并迫使每个名字都使用二进制搜索来进行。） 总结一下：如果你想从“knurr”DLL中查找输入函数“foo”的信息，第一步你先找到数据目录中的IMAGE_DIRECTORY_ENTRY_IMPORT（输入目录项）项，得到一个RVA，再在原始节数据中找到那个地址，现在你就得到一个IMAGE_IMPORT_DESCRIPTOR（输入描述结构）数组了。通过查看根据它们的“名称”被指向的字符串，得到和“knurr”DLL有关的这个数组的成员（即一个输入描述结构）。在你找到正确的IMAGE_IMPORT_DESCRIPTOR（输入描述结构）后，顺着它的“OriginalFirstThunk”（原始第一个换长）得到被指向的IMAGE_THUNK_DATA（换长数据）数组；再通过查询RVA找到“foo”函数。 好了，为什么我们有“两”列指向IMAGE_IMPORT_BY_NAME（输入名字）的指针呢？这是因为在运行时，应用程序不需要输入函数的名字，只需要地址。在这里输入地址表又出现了。加载器将从相关的DLL文件的输出目录中查找每一个输入符号，并用DLL文件入口点的线性地址替换“FirstThunk”（ 第一个换长）列表中的IMAGE_THUNK_DATA（换长数据）元素（到现在之前它还是指向IMAGE_IMPORT_BY_NAME（输入名字）的）。 请记住带有象“__imp__symbol”标签的地址列表；被数据目录IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）所指向的输入地址表，就是被“FirstThunk”（ 第一个换长）所指向的列表。[在从好几个DLL文件输入的情况下，输入地址表是包含所有DLL文件的“FirstThunk”（ 第一个换长）数组。目录项IMAGE_DIRECTORY_ENTRY_IAT（输入地址表目录项）可能会丢失，但输入（函数）仍能工作良好。] “OriginalFirstThunk”（ 原始第一个换长）数组保持不变，因此你总能通过“OriginalFirstThunk”（ 原始第一个换长）列表查找原始的输入名字列表。 现在输入已经被用正确的线性地址修正，如下所示： 原始第一个换长 第一个换长 | | | | | | V V 0--> 函数1 0--> 输出函数1 1--> 函数2 1--> 输出函数2 2--> 函数3 2--> 输出函数3 3--> foo 3--> 输出函数foo 4--> mumpitz 4--> 输出函数mumpitz 5--> knuff 5--> 输出函数knuff 6-->0 0<--6 这是简单情况下的基本结构。现在我们将要学习输入目录中的需细讲的东西。 第一，当数组中IMAGE_THUNK_DATA元（换长数据）素的IMAGE_ORDINAL_FLAG（序数标志）位（也是：MSB，参见注释?）被置1时，表示列表中没有符号的名字信息，符号只以序数输入。你可通过查看IMAGE_THUNK_DATA（换长数据）中的低地址word来得到序数。 通过序数输入是不鼓励的，通过名字输入会更安全，因为如果输出DLL文件不是预期的版本时输出序数可能会改变。 第二，有所谓的“绑定输入”。 请思考一下加载器的工作：当它想执行的一个二进制文件需要一个DLL中的函数时，加载器会载入该DLL，找到它的输出目录，查找函数的RVA并计算函数的入口点。然后用这样找到的地址修正“FirstThunk”（ 第一个换长）列表。 假设程序员很聪明，给DLL文件提供的唯一优先载入地址不会发生冲突，那么我们就能认为函数的入口点将总是相同的。它们在链接时能被算出并被补进“FirstThunk”（ 第一个换长）列表中，这就是“绑定输入”所发生的一切。（“绑定”工具就是干这个的，它是Win32 SDK的一部分。） 当然，你得慎重：用户的DLL可能是不同的版本，或者DLL必须重定位，这些都会使先前修正的“FirstThunk”（ 第一个换长）列表不再有效；此时，加载器仍能查寻“OriginalFirstThunk”（ 原始第一个换长）列表，找出输入符号并重新补正“FirstThunk”（ 第一个换长）列表。加载器知道这是必须的，当：1）输出DLL文件的版本不符，或2）输出DLL文件需要重定位时。 确定有没有重定位表对加载器来说不是问题，但该怎样找出版本的不同呢？这时IMAGE_IMPORT_DESCRIPTOR（输入描述结构）的“时间戳”就派上用场了。如果它是0，表明输入列表没有被绑定，加载器总是要修复入口点。否则的话，输入被绑定，“时间戳”必须要和“文件头”中的输出DLL文件的“时间戳”相符；如果不符的话，加载器就认为该二进制文件被绑到一个“错误”的DLL文件上并重新补正输入列表。 这里有另外一个有关输入列表中的“中转”的怪事。一个DLL文件能输出一个不定义在本DLL文件中却需从另一个DLL文件中输入的符号；这样的符号据说就是被中转的（参见上面的输出目录描述）。 现在，很明显的，你不能通过查看那个实际上并不包含入口点信息的DLL文件的时间戳来确定一个符号的入口点是否有效。因此，出于安全的原因，中转符号的入口点必须总是被修正。在二进制文件的输入列表中，中转符号的输入必须被找出，以便加载器能补正它们。 这一点可通过“ForwarderChain”（中转链）来做到。它是一个指向换长列表中的索引值；被索引位置的输入就是一个中转输出，并且此位置的“FirstThunk”（ 第一个换长）列表中的内容就是“下一个”中转输入的索引值，以此类推，直到索引值为-1，就表明已没有其他的中转了。如果根本就没有中转，那么“ForwarderChain”（中转链）的值本身就为-1。 这就是所谓的“老式”绑定。 至此，我们应该总结一下我们目前已掌握的情况 :-) OK，我将认为你已找到了IMAGE_DIRECTORY_ENTRY_IMPORT（输入目录项）并且已根据它找到了它的输入目录，位于某个节中。现在你已处于IMAGE_IMPORT_DESCRIPTOR（输入描述结构）数组的开头了，此类数组的最后一个将以全0字节填充。 要读懂一个IMAGE_IMPORT_DESCRIPTOR（输入描述结构），你得先查看它的“名字”项，根据它的RVA，你就能找到输出DLL文件的名字。下一步你得确定输入是否是绑定的；如果输入是绑定的，“时间戳”就会是非“0”的。如果它们是绑定的，现在就是你通过比较“时间戳”来检查DLL文件的版本是否相符的好机会了。 现在你根据“OriginalFirstThunk”（ 原始第一个换长）的RVA来到了IMAGE_THUNK_DATA（换长数据）数组；过完这些数组（它是0结尾的），它的每个成员都将是一个IMAGE_IMPORT_BY_NAME（输入名字）的RVA（除非它的高位被置1，此时你找不到名字只有序数）。根据那个RVA，并跳过2字节（即‘提示’），现在你就得到一个以0结尾的字符串，这就是输入函数的名字。 在绑定输入时要找到提供的入口点，先根据“FirstThunk”（ 第一个换长）平行的来到“OriginalFirstThunk”（ 原始第一个换长）数组；数组成员就是入口点的线性地址（暂时不考虑中转的话题）。 还有一件我到现在都没有提及的事情：明显地有些链接器在构建输入目录时会产生bug（我就发现一个还在被一个Borland C链接器使用的bug）。这些链接器把IMAGE_IMPORT_DESCRIPTOR（输入描述结构）中的“OriginalFirstThunk”（ 原始第一个换长）设为0，并只建立“FirstThunk”（ 第一个换长）。很明显的，这样的输入目录不能被绑定（否则重修输入的必须信息就会丢失----你根本找不到函数名字）。在这种情况下，你得根据“FirstThunk”（ 第一个换长）数组来取得输入符号名字，你将永远得不到预先补正的入口地址。我已发现一个TIS文件(参考书目[6])，讲述一个在某种程度上和此bug兼容的输入目录，因此那个文件可能就是该bug的起源。 TIS文件规定： IMPORT FLAGS（输入标志） TIME/DATE STAMP（时间/日期戳） MAJOR VERSION - MINOR VERSION（主版本号 - 小版本号） NAME RVA（名字的RVA） IMPORT LOOKUP TABLE RVA（输入查询表的RVA） IMPORT ADDRESS TABLE RVA（输入地址表的RVA） 而别处使用的对应结构是： OriginalFirstThunk（ 原始第一个换长） TimeDateStamp（时间日期戳） ForwarderChain（中转链） Name（名字） FirstThunk（第一个换长） 最后一个关于输入目录的需要细讲的就是所谓的“新式”绑定（在参考书目[3]中讲述），它也可以由“绑定”工具来处理。当使用这种方式时，“时间日期戳”的所有位被置为1，并且没有中转链；此时所有输入符号的地址都将被补正，而不管它们是不是中转的。尽管如此，你还是需要知道DLL的版本，并且你还是需要将序数符号从中转符号中区分开来。为了达到这个目的，IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT（绑定输入目录项）目录被创建了。就我所见，它将不被放在节中，而是被放在头中，处于节头之后第一节之前。（咳，这不是我的发明，我只是讲述它而已！） 这个目录告诉你，每一个已使用的DLL文件的中转输出是从哪些别的DLL文件中来的。 结构是IMAGE_BOUND_IMPORT_DESCRIPTOR（绑定输入描述结构）形式的，包括（按这个顺序）： 一个32位数字，“时间戳”。 一个16位数字，“OffsetModuleName（模块名字偏移量）”，是从目录开头到以0结尾的DLL文件名的偏移量； 一个16位数字，“NumberOfModuleForwarderRefs（模块中转参考的数字）”，给出这个DLL文件为它的中转使用的DLL文件数。 紧随这个结构之后你会发现“NumberOfModuleForwarderRefs（模块中转参考的数字）”结构，告诉你这个DLL文件的中转所来自的DLL文件的名称和版本。这些结构就是“IMAGE_BOUND_FORWARDER_REF（绑定中转参考）”结构的： 一个32位的数字“时间日期戳”（TimeDateStamp）； 一个16位的数字“模块名称偏移量”（OffsetModuleName），它就是从目录开头到中转来自的那个DLL文件的0结尾的名字处的偏移量； 一个16位的未使用单元。 跟在“IMAGE_BOUND_FORWARDER_REF（绑定中转参考）”后的是下一个“IMAGE_BOUND_IMPORT_DESCRIPTOR（绑定输入描述结构）”，以此类推；列表最终以一个全部为0位的IMAGE_BOUND_IMPORT_DESCRIPTOR（绑定输入描述结构）结束。 我对由此（描述）造成的不便表示歉意，但这就是它看起来的样子:-） 现在，如果你有一个新的绑定输入目录，你得载入所有的DLL文件，并使用目录指针IMAGE_DIRECTORY_ENTRY_BOUND_IMPORT（绑定输入目录项）找到IMAGE_BOUND_IMPORT_DESCRIPTOR（绑定输入描述结构），扫描整个IMAGE_BOUND_IMPORT_DESCRIPTOR（绑定输入描述结构），并检查被载入的DLL文件的“时间日期戳”和这个目录中提供的是否相符。如果不符，就将输入目录中“第一换长”（FirstThunk）中的错误全部修改过来。 8.资源（resources） ------------------- 资源，比如对话框、菜单、图标等等，都存储在IMAGE_DIRECTORY_ENTRY_RESOURCE（“资源目录项”）指向的数据目录中。它们处于一个至少“IMAGE_SCN_CNT_INITIALIZED_DATA（已初始化数据内容节）”和“IMAGE_SCN_MEM_READ（内存可读节）”标志位都被置为1的节中。 资源的基础是“资源目录”（IMAGE_RESOURCE_DIRECTORY）；它包含好几个“资源目录项”（IMAGE_RESOURCE_DIRECTORY_ENTRY），其中的每一项反过来又可能指向一个“资源目录”。按照这种方式，你就得到一个以“资源目录项”为树叶的“资源目录”树；它们的树叶指向实际的资源数据。 在实际使用中，情况会稍微简单些。一般你不会遇到不可能理清的特别复杂的树的。 通常，它的层次结构是这样的：一个目录作为根。它指向很多目录，每种资源类型都有一个。这些目录又指向子目录，每个子目录都有一个名字或者ID号并指向这个资源所提供的各种语言的目录；每种语言你都能找到一个资源项，资源项最终指向（具体的）数据。（注意：多语言资源不能在Win95上运行。即使程序有好几种语言，Win95也总是使用相同的资源----我没有查出是哪一种，但我猜测肯定是它最先碰到的那种。多语言资源在NT系统上可以运行。） 没有指针的树大致象这样： ( 根 ) | +----------------+------------------+ | | | 菜单 对话框 图标 | | | +-----+-----+ +-+----+ +-+----+----+ | | | | | | | "main" "popup" 0x10 "maindlg" 0x100 0x110 0x120 | | | | | | | +---+-+ | | | | | | | | default english default def. def. def. german english 一个“资源目录项”（IMAGE_RESOURCE_DIRECTORY）包含： 32位未使用标志，叫做“特征”（Characteristics）； 32位“时间日期戳”（同样按常用的time_t表示法），告诉你资源被创建的时间（如果此项被设置的话）； 16位“主版本号”（MajorVersion）和16位“小版本号”（MinorVersion），以允许你据此维护资源的几个版本； 16位“已命名项目数”（NumberOfNamedEntries）和另一个16位的“ID项目数”（NumberOfIdEntries）。 紧随此结构后的是“已命名项目数”+“ID项目数”两结构体，它们都是“资源目录项”格式，都以名字开头。它们可能指向下一个“资源目录”或者指向实际的资源数据。 一个“资源目录项”由下面组成： 32位单元提供你它所描述的资源的ID或者是目录； 32位的到数据的偏移量或者是到下一个子目录的偏移量。 ID的含义取决于树中的层次；ID可能是一个数字（如果最高位为0）也可能是一个名字（如果最高位为1）。如果是一个名字，它的低31位就是从资源节原始数据的开始到这个名字（名字有16位长并由unicode的宽字符而不是0结尾符作为结束）的偏移量。 如果你位于根目录之中，且如果ID是一个数字的话，那么它指的就是下面的一种资源类型： 1: 光标 2: 位图 3: 图标 4: 菜单 5: 对话框 6: 字串表 7: 字体目录 8: 字体 9: 快捷键 10: 未格式化资源数据 11: 信息表 12: 组光标 14: 组图标 16: 版本信息 任何其它数字都是用户自定义的。任何有类型名的资源类型也是用户自定义的。 如果你处于（树的）下一层当中，此时ID一定是一个数字，且就是资源的一个特例的语言ID号；例如，你可以（同时）拥有澳大利亚英语、加拿大法语和瑞士德语等本地化形式的对话框，并且它们分享同一个资源ID。系统会根据线程的地点来选择要使用的对话框，反过来地点又反映了用户的“区域设置”。（如果资源找不到线程地点，系统将先使用一个中性的子语言资源作为地点，比如它将寻找标准法语而不是用户所拥有的加拿大法语；如果它还是找不到，就使用最小语言ID号的那个实例。必须注意，所有这些只工作于NT系统之上的。） 为便于辨认语言ID，使用宏PRIMARYLANGID()（意为“主语言ID”）和SUBLANGID()（意为“子语言ID”）将它分开为主语言ID和子语言ID，分别使用它的0-9位和10-15位。这些值定义在“winresrc.h”文件中。 语言资源只支持快捷键、对话框、菜单、资源数据或字符串等；其它资源类型必须为LANG_NEUTRAL/SUBLANG_NEUTRAL（中性语言/中性子语言）。 要确定资源目录的下一层是不是另一个目录，你可查看它的偏移量的最高位。如果它是1，剩下的31位就是从资源节原始数据的开始到下一层目录的偏移量，还是按“资源目录”后接“资源目录项”的格式。如果高位为0，它就是从资源节原始数据的开始到资源的原始数据描述，即一个资源数据项的偏移量。资源的原始数据描述包含32位的“OffsetToData”（到数据的偏移量）（指的是到原始数据的偏移量，从资源节原始数据的开头算起），32位的数据的“Size”（大小），32位的“CodePage”（代码页）和一个未使用的32位单元。 （不鼓励使用代码页，你应该使用“语言”的特性来支持多地域。） 原始数据格式依赖于资源类型；详细的介绍可在微软的SDK文档中找到。注意：除了用户自定义资源，资源中的任何字符串总是按UNICODE格式，明显的，用户自定义的资源按的是开发者选定的格式。 |
