在我意识到您可能有更简单的解决方案可用之前，我已经写了一篇关于转储可执行文件和 DLL 的一些微妙之处的冗长答案。既然你说它正在从网络下载 DLL，也许你可以从网络流量中读取 DLL 的原始内容？如果流量和 DLL 未加密，这应该很容易（例如，您可以使用 Ethereal）。如果流量已加密（例如，通过 HTTPS）但 DLL 未加密，也许您可​​以在 HTTPS 库中放置一个断点来检索未加密的流量。如果 DLL 与网络流量的加密或不加密是分开加密的，或者不管网络流量是否加密，那么这些想法不会给你一个未加密的 DLL，所以你可能不得不退回到在某些时候动态地将 DLL 转储出内存的想法。观点。因此，

鉴于 EXE 和 DLL 共享相同的文件格式，并且以相同的方式加载到进程的地址空间中，用于将 EXE 转出内存的相同工具和过程也适用于将 DLL 转出内存。存在许多工具，例如 Scylla、LordPE、ImpRec 及其转储插件等。您可以在Tuts4You上找到列表。

将可执行映像从内存中转储的一个复杂问题是，如果您希望最终结果是一个可以运行的工作 EXE（或者在这种情况下，一个可以加载到内存中的工作 DLL），您需要小心倾倒的准确时间。当程序执行时，它们倾向于修改全局数据结构以表明事物已经被初始化。例如，程序可能会检查存储在全局数据部分中的某个指针值是否为 NULL，如果是，则分配内存并用分配覆盖该 NULL 指针。因此，如果您在发生这种情况后转储 EXE 或 DLL，下次运行程序或加载 DLL 时，该全局数据项将指向内存中不再存在的一块内存。转储的程序可能会因此而崩溃。那' s 为什么手动解包如此专注于找到“原始入口点”或 OEP：您希望在打包程序完成其业务后，在程序开始覆盖其数据部分之前暂停执行。另一个相关问题是搬迁；如果进程映像被加载到其首选地址以外的基地址，Windows 的加载程序将修改进程映像。如果您在应用重定位后转储，您的转储将反映这些更改。

（请注意，重建工作的 EXE 或 DLL 并不总是目标。例如，如果您只想快速查看 IDA 中的 EXE 或 DLL 的内容，您可以随时停止该进程并转储 EXE 或 DLL。这比重新创建工作映像涉及的步骤更少，因此更容易。）

我提出这一点的原因是，根据 DLL 注入的方式，操作系统可能会处理重定位并在注入其他进程后立即调用 DLL 的入口点。如果您想转储 DLL 并获得工作映像，由于我在前两段中描述的内容，这对您不利。

如果注入程序用于在受害进程中CreateRemoteThread强制调用LoadLibrary，那么它一定已经将 DLL 写入磁盘，因此您可以直接复制它而不必担心转储的确切时间。

如果注入程序使用其他方法，如反射 DLL 注入，则意味着它绕过操作系统的加载程序并手动修复 DLL（处理重定位、加载导入和转发导出）。在解密 DLL 之后，但在应用刚才提到的修复程序之前，您需要将 DLL 从注入程序中转储出来。你可能会通过设置一个断点开始WriteProcessMemory，并NtWriteVirtualMemory在注射过程中要尽量找到代码执行DLL注入和工作往回走，找到该DLL从网络检索和固定起来。找到后，在修复 DLL 映像的代码之前设置一个断点，然后将尚未修复的 DLL 转储到磁盘上。

这些只是我的高层次想法。更具体的问题可以产生更具体的答案。

不需要 IDA 或任何其他调试器。假设你知道哪个进程有注入，有两种可能的方式：

1. 打开进程黑客，双击进程并进入内存选项卡。查找具有 RWX 权限的内存部分（有时是 RX，但主要是 RWX）。双击它，看看它是否像一个 dll（以“MZ”魔法开头）。或 shell 代码（“55 8b”通常是函数序言）。将此内存部分保存到磁盘并记住它在进程内存中的起始地址是什么。使用pe_unmapper将其转换回原始 PE 格式（pe_unmapper FILE_NAME START_ADDRESS）

2. 使用进程转储程序