我是某个进程的内存空间中加载的DLL。我是此过程中存在的许多 DLL 的一部分，有些是动态加载的，有些是静态加载的。
有一个“数据宝石”让我在这个进程空间的某个地方发现，我们假设它在一个“数据”段中（即不是在一些奇怪的自我修改代码中）。
我需要找到它。我需要搜索内存，例如做一个 memcmp() 但我不知道从哪里开始寻找。也许我可以从 0 到 many-gigs 进行暴力搜索，但这会引发读取访问或仅执行异常，也许我将能够处理这些异常，这样我就不会降低整个过程。但这听起来很狡猾。
有没有更智能的搜索方式？在我的脑海中，我可以查看主进程的数据段，因为有一种方法可以从 NT 标头中获取地址范围，而且我确实知道我已经加载的进程。然后我可以枚举所有加载的 DLL 并查看它们的空间。
谁能建议一种方法，甚至告诉我我是否走在正确的轨道上？
您可以通过EnumProcessModulesusingGetCurrentProcess作为进程句柄来枚举进程中所有已加载的模块。然后对于您可以调用的每个模块GetModuleInformation，它将返回一个MODULEINFO结构，该结构告诉您该模块在内存中的确切位置及其大小。或者，您可以调用GetModuleFileNameEx
并检查磁盘上的模块。
请注意，在进程中读取任意内存（即使是您当前正在运行的内存）也可能会出现问题。例如，如果另一个线程与您的线程同时运行，那么它会在您对其进行迭代时影响模块表。
经过一些测试，Win32 进程可能会使用它通过多种方法获得的内存，我认为这一切都最终使用了 VirtualAlloc 和更高级别的 HeapCreate 等。最后，数据 gem 可能在模块的“数据”段中，或者在堆上，甚至在堆栈上 - 两者都使用 VirtualAlloc 分配。可能还有其他内存分配方法。
当我们查看 Windows 进程时，它会加载一堆 DLL，其中许多将使用它们自己的“堆”和/或直接 VirtualAlloc 调用。其他人将共享主进程的堆。
我已经使用 GetProcessHeaps 枚举了进程的堆，然后 HeapWalk 只专注于 PROCESS_HEAP_ENTRY_BUSY，幸运的是，我找到了我想要的东西。我的“heapwalk”绝不是详尽的搜索。
我还没有找到一种方法，现在对我来说将堆条目（块）链接到特定模块是学术性的。同样，如果我要查看所有 VirtualAlloc，我将不知道如何将分配的块追溯到模块内运行的某些代码。但那一步是学术性的。