如何解决转发的 WinAPI 的循环依赖？

我试图找到一种方法来解析映射到进程中的特定 API 的内存地址和 DLL 文件名。大多数问题可以通过 DLL 中的导入/导出表以及分析映射模块的导入地址表来解决。这适用于大多数功能。

但这个问题发生在一些人身上转发功能 https://blogs.msdn.microsoft.com/oldnewthing/20060719-24/?p=30473。这种函数的一个例子是DeleteProcThreadAttributeList在我的 Windows 10 系统上。例如，如果我使用这样的函数构建一个测试 32 位进程，或者更好的是，让我们使用 32 位版本cmd.exe from c:\windows\syswow64\cmd.exe图像，然后尝试分析其导入表。原来这个函数是从API Set使用虚拟名称API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL:

要查找它重定向到的实际文件，我执行以下操作：

HMODULE hMM = ::LoadLibraryEx(L"API-MS-WIN-CORE-PROCESSTHREADS-L1-1-2.DLL", 
    NULL, DONT_RESOLVE_DLL_REFERENCES);
WCHAR buffModPath[MAX_PATH];
::GetModuleFileNameEx(::GetCurrentProcess(), hMM, buffModPath, _countof(buffModPath));
::FreeLibrary(hMM);

这给了我buffModPath as C:\Windows\System32\KERNEL32.DLL.

因为我是从 32 位进程调用它，所以我现在检查导出表c:\windows\syswow64\KERNEL32.DLL module:

这表明DeleteProcThreadAttributeList被转发到api-ms-win-core-processthreads-l1-1-0.DeleteProcThreadAttributeList.

好的，然后我再次使用我的方法来解决虚拟的重定向api-ms-win-core-processthreads-l1-1-0.dllAPI集：

HMODULE hMM = ::LoadLibraryEx(L"api-ms-win-core-processthreads-l1-1-0.dll", 
    NULL, DONT_RESOLVE_DLL_REFERENCES);
WCHAR buffModPath[MAX_PATH];
::GetModuleFileNameEx(::GetCurrentProcess(), hMM, buffModPath, _countof(buffModPath));
::FreeLibrary(hMM);

这给了我C:\Windows\System32\KERNEL32.DLL，这让我回到了开始的地方。

那么，如何像操作系统模块加载器那样解决对实际 DLL 地址/入口点的循环依赖呢？

我想无论发生什么如果你GetProcAddress其中一个出口应该是一个黑匣子。

PEB 在 Windows 7+ 中具有 ApiSetMap 成员，其中包含加载程序使用的设置信息。该数据的格式至少改变了3次，但映射不仅仅是从“API-*.dll”到“*32.dll”。

你可以阅读这个概念的微软专利here http://www.patentsencyclopedia.com/app/20140366045.