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