你的附件里没有你的DLL文件啊，怎么试啊

没有Dll照样可以运行的，所以我才觉得奇怪

真的好奇怪哦，没觉得哪儿有错，为什么执行时不报 找不到该dll文件错误呢

难道根本没用到输入表？？？尝试把”msvcrt.dll“改为”msvcra.dll",执行会报错啊，又把新加的IMAGE_IMPORT_DESCRIPTOR与其他正常的对换位置，仍然如此，我都迷糊了。。。。期待高手解答

如果用LordPE随便增加一个Dll进去，再把增加的DLL干掉，就会报错了。

增加一个DLL时LordPE会增加一个新节，其它数据还是会如实拷贝过去的，再把增加的DLL干掉也就是原来的数据并没有改变呀，为什么这样做就可以正确加载我原来的DLL了呢

呵呵，好奇怪啊，把lordpe增加的节删除，然后把输入表地址改回原来的136B0,居然正常了，好晕，为什么之前会无视那个IMAGE_IMPORT_DESCRIPTOR，后面还原后反而又看到了呢。。。

经过反复对比，发现问题出在目录表里，用lordpe将"目录信息"里的“输入范围”清0，就会找到你的dll文件了
输入范围的RVA为260，在文件260的地方比一般的EXE文件多一些内容如下：这个输入范围可能汉化不准确，应该叫绑定输入表

上传的附件：

• calc.JPG （35.79kb，105次下载）

搜索绑定输入表会发现很多计算器字眼，哈哈，又学到一点
下面摘自1c5K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8X3S2A6i4K6u0W2j5X3q4A6k6s2g2Q4x3X3g2U0L8$3#2Q4x3V1k6&6L8s2W2%4P5h3&6Q4x3V1k6T1L8r3!0Y4i4K6u0r3K9i4c8W2L8g2)9J5c8U0N6S2k6e0f1&6z5e0u0T1j5U0V1$3y4$3q4S2k6U0y4W2y4$3y4V1y4o6l9H3x3#2)9J5k6h3S2@1L8h3H3`.
绑定输入目录表(The Bound Import Directory)。它包含了可以让加载器判断绑定的地址是否合法的信息。描述它的数据结构是IMAGE_BOUND_IMPORT_DESCRIPTOR，目录表就是这种结构的数组，每一项都对应一个被绑定过的DLL。先看下这个结构：

typedef struct _IMAGE_BOUND_IMPORT_DESCRIPTOR {

    DWORD TimeDateStamp;

    WORD OffsetModuleName;

    WORD NumberOfModuleForwarderRefs;

} IMAGE_BOUND_IMPORT_DESCRIPTOR,*PIMAGE_BOUND_IMPORT_DESCRIPTOR;

    TimeDateStamp。这个成员必须和要引用的DLL的文件头信息相吻合，否则就会加载器去手动计算新IAT，这种情况一般发生在DLL版本不同时或者DLL映像被重定位时。

    OffsetModuleName。包含了以第一个IMAGE_BOUND_IMPORT_DESCRIPTOR为基址，DLL名称字符串(ASCII且以null结束)的偏移（非RVA）。

    NumberOfModuleForwarderRefs。是紧接着本结构后的另一个IMAGE_BOUND_FORWARDER_REF结构数组的元素个数。

typedef struct _IMAGE_BOUND_FORWARDER_REF {

    DWORD TimeDateStamp;

    WORD OffsetModuleName;

    WORD Reserved;

} IMAGE_BOUND_FORWARDER_REF,*PIMAGE_BOUND_FORWARDER_REF;

    这个结构与IMAGE_BOUND_IMPORT_DESCRIPTOR好像一样嘛。。。噢就最后一个字是保留的。这个结构数组干什么用的？你一定已经注意到ModuleForwarder这个词了，还记得我们在输出表中讲到的，函数的输出转送么？就是一个函数自己不实现而是把调用请求转发给另一个DLL中的函数。这里的IMAGE_BOUND_FORWARDER_REF结构就是用来记录接受转发的另一个DLL的校验信息，如果这个DLL还有输出转送，那么在该DLL中也有IMAGE_BOUND_FORWARDER_REF结构描述第三个DLL的校验信息。

回答的真仔细，非常感谢WXXW的细心和耐心

我再仔细看一下LordPE把绑定输入表和IAT表都清空了。