用importREC修复Import表

1、用ollydbg找到正确的OEP(脱壳和修复导入表都要用到)
2、脱壳在当前进程,如脱壳出来的程序不能运行，提示无法定位程序输入点，需要使用
importREC修复导入表。
3、打开importREC，选正ollydbg正在调试的进程，填入正确的OEP,点ITA AutoSearch，
如oep正确将得到正确提示，点GetImport，得到正确的导入表。点Fix Dump，选择脱壳
出来的保存文件，Done!（修正后的程序为原程序名后加一下划线，原程序不会被修改。）

islq 2005

 

以下是引用：无花果-编程驿站

脱壳高级篇之认识Import表(点击:937)

1、认识Import表 著者: [yAtEs] [Jamesluton@hotmail.com]  译者：hying[CCG]  标题：PE输入表说明  例子：  下载      有很多介绍PE文件的文章，但是我打算写一篇关于输入表的文章，因为它对于破解很有用。      我想解释它的最好的方法是举一个例子，你可以跟着我逐步深入，一步一步的思考，最后你将完全明白，我选择了一个我刚下载下来的小程序，它是用TASM编译的，有一个比较小的输入表，所以我想它应该是个不错的范例。      好了，让我们开始吧。首先我们得找到输入表，它的地址放在PE文件头偏移80处，所以我们用16进制编辑器打开我们的EXE文件，我们先得找到PE文件头的起始点，这很简单，因为它总是以PE,0,0开始，我们可以在偏移100处找到它。在一般的WIN32程序中文件头偏移被放在文件0X3C处，在那我们通常可看到00 01 00 00，由于数据存储时是低位在前，高位在后的，所以翻转过来实际就是00000100，就象前面我们说的。接下来我们就可以在PE文件中找到我们的输入表，100+80=180在偏移180处我们看到0030 0000，翻转一下，它其实应该是00003000，这说明输入表在内存3000处，我们必须把它转换成文件偏移。      一般来说，输入表总是在某个段的起始处，我们可以用PE编辑器来查看虚拟偏移，寻找3000并由此发现原始偏移。很简单的。打开我们看到：  -CODE  00001000 00001000 00000200 00000600  -DATA  00001000 00002000 00000200 00000800  .idata 00001000 00003000 00000200 00000A00  .reloc 00001000 00004000 00000200 00000C00      找一下，我们就发现.idata段的虚拟偏移是3000，原始偏移是A00，3000-A00=2600，我们要记住2600，以便以后转换其它的偏移。如果你没找到输入表的虚拟偏移，那么就找一下最接近的段。      来到偏移A00处，我们就看到被称为IMAGE_IMPORT_DESCRIPTORs（IID）的东东，它用5个字段表示每一个被调用DLL的信息，最后以Null结束。  **************************************************************************  (IID) IMAGE_IMPORT_DESCRIPTOR的结构包含如下5个字段：  OriginalFirstThunk, TimeDateStamp, ForwarderChain, Name, FirstThunk  OriginalFirstThunk  该字段是指向一32位以00结束的RVA偏移地址串，此地址串中每个地址描述一个输入函数，它在输入表中的顺序是不变的。  TimeDateStamp  一个32位的时间标志，有特殊的用处。  ForwarderChain  输入函数列表的32位索引。  Name  DLL文件名（一个以00结束的ASCII字符串）的32位RVA地址。  FirstThunk  该字段是指向一32位以00结束的RVA偏移地址串，此地址串中每个地址描述一个输入函数，它在输入表中的顺序是可变的。  **************************************************************************  好了，你有没有理解？让我们看看我们有多少IID，它们从偏移A00处开始  3C30 0000 / 0000 0000 / 0000 0000 / 8C30 0000 / 6430 0000  {OrignalFirstThunk} {TimeDateStamp} {ForwardChain} {Name} {First Thunk}  5C30 0000 / 0000 0000 / 0000 0000 / 9930 0000 / 8430 0000  {OrignalFirstThunk} {TimeDateStamp} {ForwardChain} {Name} {First Thunk}  0000 0000 / 0000 0000 / 0000 0000 / 0000 0000 / 0000 0000      每三分之一是个分界，我们知道每个IID包含了一个DLL的调用信息，现在我们有2个IID，所以我们估计这个程序调用了2个DLL。甚至我可以打赌，你能推测出我们将能找到什么。      每个IID的第四个字段表示的是名字，通过它我们可以知道被调用的函数名。第一个IID的名字字段是8C30 0000，翻转过来也就是地址0000308C，将它减去2600可以得到原始偏移，308C-2600=A8C，来到文件偏移A8C处，我们看到了什么？啊哈！原来调用的是KERNEL32.dll。      好了，接下来我们就要去找出KERNEL32.dll中被调用的函数。回到第一个IID。      FirstThunk字段包含了被调用的函数名的标志，OriginalFirstThunk仅仅是FirstThunk的备份，甚至有的程序根本没有，所以我们通常看FirstThunk，它在程序运行时被初始化。      KERNEL32.dll的FirstThunk字段值是6430 0000，翻转过来也就是地址00003064，减去2600得A64，在偏移A64处就是我们的IMAGE_THUNK_DATA，它存储的是一串地址，以一串00结束。如下：     A430 0000/B230 0000/C030 0000/CE30 0000/DE30 0000/EA30 0000/F630 0000/0000 0000      通常在一个完整的程序里都将有这些。我们现在有了7个函数调用，让我们来看其中的两个：  DE30 0000翻转后是30DE，减去2600后等于ADE，看在偏移ADE处的字符串是ReadFile，  EA30 0000翻转后是30EA，减去2600后等于AEA，看在偏移AEA处的字符串是WriteFile，      你可能注意到了，在函数名前还有2个这字节的00，它是被作为一个提示。      很简单吧，你可以自己来试一下。回到A00，看第二个DLL的调用  5C30 0000 / 0000 0000 / 0000 0000 / 9930 0000 / 8430 0000  {OrignalFirstThunk} {TimeDateStamp} {ForwardChain} {Name} {First Thunk}      先找它的DLL文件名。9930翻转为3099-2600 =A99，在偏移A99处找到USER32.dll。再看FirstThunk字段值：8430翻转为3084-2600=A84，偏移A84处保存的地址为08310000，翻转后3108-2600=B08，偏移B08处字符串为MessageBoxA。明白了吧，接下来你就可以把这些用在你自己的EXE文件上了。      摘要：      在PE文件头+80偏移处存放着输入表的地址，输入表包含了DLL被调用的每个函数的函数名和FirstThunk，通常还有Forward Chain和TimeStamp。      当运行程序时系统调用GetProcAddress，将函数名作为参数，换取真正的函数入口地址，并在内存中写入输入表。当你对一个程序脱壳时你可能注意到你有了一个已经初始化的FirstThunk。例如，在我的WIN98上，函数GetProcAddress的入口地址是AE6DF7BF，在98上，所有的KERNEL32.dll函数调用地址看上去地址都象：xxxxF7BF，如果你在输入表中看到这些，你可以利用orignal thunk重建它，或者重建这个PE程序。      好了，我已经告诉你它们是如何工作的，我不是专家，如果你发现什么错误，请告诉我。  by  [yAtEs]