大多数在教程中，他们都告诉使用这个工具和那个工具来神奇地应用某些东西并使 XY 工作和运行。我很想知道这些东西是如何工作的，导入重建一般是如何完成的？
例如，在我的情况下，我需要从内存中转储恶意软件，它是手动映射的，但这些导入重建工具通常不支持这样的事情，这就是我想了解它到底是什么的原因。（我知道有一些解决方法可以让它们工作，但我想知道imp reccing背后的逻辑）
那么，回到问题。他们是否为驻留在外部模块中的调用分析代码本身？或者他们是否使用了一些其他/现有/运行时表，这些表通常会揭示原始模块/过程。
我找不到任何关于它的好的文档/描述（除了 Scylla 的整个代码库）
不同的导入重建工具采用不同的启发式方法来找到恶意软件/加壳程序使用的方法，因为手动实现的导入表可以通过多种不同的方法实现（有些根本不保存导入表）。
大多数导入重建工具甚至通常有多种启发式选择。您可以在这些工具的文档和/或文件中了解不同的启发式方法及其含义。ImpRec's 可以作为文本文件找到，而 Scylla's 可以从它的源代码中解释。
通常，导入重构工具需要为每个导入的函数收集两条信息：
在整个固定二进制文件中调用/引用的导入函数在哪里。这可能是指向导入函数的指针变量，也可能是需要根据导入函数地址修改的一段代码。
如果二进制文件在其执行过程中创建了一个手动导入表，则这涉及对其进行迭代，直到到达末尾。在加载二进制文件并达到 OEP 后，通过调用/跳转，通过地址直接指向它或从二进制文件本身完成的引用推断它，查找此类手动导入表通常留给用户。
如果二进制文件避免使用导入表，则必须通过分析从 OEP 开始的代码并识别间接调用或使用存储地址进行的调用来推断所有导入。导入重构工具可以验证目标地址确实是导入函数。
实际上正在调用哪个导入的函数。更常见的是，这是两者中更容易的部分，但加壳工可能会进一步复杂化。要解析导入，导入重建工具显然必须知道每个引用必须解析哪个函数。
如果这些跳转/调用/指向加载库中的相关导入函数，则解析它们非常简单——枚举目标模块中的所有导入并匹配地址。
但是，如果导入的函数被（全部或部分）复制到分配的内存区域，确定实际调用的函数可能会更困难一些。