为何在手动拆箱时准确地在OEP处倾倒？

#1 楼

但是，知道OEP与IAT有什么关系？由打包程序提供。正是为什么需要进口重建。由于该恶意软件有意破坏了IAT，因此仅保留了一小部分强制性功能，而将大部分API的工作作为解包代码的一部分留给了工作。因此，导入重建将要求我们通过其他方式找到IAT（因为PE定义的IAT不完整/伪造）。导致OEP？还是OEP之后的一两个指令？


转储时，执行与解压缩打包代码有关的所有代码是导入的。否则，OEP可能不是有效的可执行代码。除此之外（与导入重建相关的问题），转储并仅将PE的入口点调整为OEP就是很好的选择。大多数转储工具都允许这样做。


除了回答您的特定问题外，以下是有关IAT操作的打包程序类型以及在转储的PE中获得功能性IAT所需的内容：


如果加壳程序未更改原始导入表，则无需进行导入重建。大多数PE转储者都会在有效时复制原始导入表，或将其与PE转储。
一些打包程序会携带另一个最初隐藏的PE，并且仅对其进行完全解密/解密。这些打包机还将完好无损地携带IAT，而大多数自卸车将自动获得IAT。
一些打包程序将创建自己的替代IAT，并实现自己的API加载/解析版本。对于那些包装商，导入重建实用程序将需要找到该替代方法（或者我们要说是真实的），并从头开始在重建的PE中创建新的IAT（基于原始IAT实际指向的API）。然后，导入重建将查找“ IAT查找”偏移量范围，并确保在加载PE时它们位于相同的位置。因此，将对OEP进行扫描，以查找使用可能被怀疑是此类IAT的偏移表的呼叫。
某些打包程序不会创建单个IAT，而是创建许多小的IAT表，因此您将不再呼叫它们“表格”。在这种情况下，导入重建工具必须遇到足够多的小表，并分别重建它们。在这种情况下，更重要的是不要保留任何代码段，因为仅那些代码段使用的API不会被重建。
另一种类型的打包程序使得解析静态反汇编的API变得更加困难。 （尽管不阻止执行转储的PE），方法是删除导入表的概念，而是在每次进行API调用时解析请求的API。通常，这是通过为任何API分配一个无法轻易识别的键/哈希来完成的，并在每次调用时遍历DLL和Export表，为API生成相同的键/哈希，直到找到正确的键为止。 />这通常意味着导入重建不需要执行和调试转储的PE，但是人工逆向工程师将很难理解正在调用哪些API。

#2 楼

我认为这里有些混乱。


但是知道OEP与IAT有什么关系？ 。但是，您链接的文章将分析打包的可执行文件。通常，恶意软件会在不使用官方IAT的情况下尝试隐藏其导入内容，而是在运行时创建自己的内容。这些工具应该可以帮助您某种程度上重构“正常” IAT。 PE标头和获取IT的地址-然后是IAT的
？我已经见过很多恶意软件，而这种情况很少见。还是在OEP之后输入一两个指令？


，以确保获得正常的有效载荷。通常，分析人员会尝试为此准备一个PE文件（通过重建IAT，建立标头等），以使分析更加舒适。

在本文中，他们试图“修复”二进制文件br />