如何将对 ole32.dll 的调用重定向到我自己的代理 DLL？

Question

我正在尝试检测对 CoCreateInstance< 的所有调用/a> 在我正在启动的某个进程中（理想情况下，我也能够检测到子进程中的调用）。

为了实现这一目标，我使用 Windows 7 上的 Microsoft Visual Studio 2008 创建了一个代理 DLL，它转发标准 ole32.dll 库中除一个调用之外的所有调用，如各种文章中所述，例如 拦截：通过 DLL 重定向进行 Windows 黑客攻击。生成的 DLL 看起来不错，但我无法制作现有程序（我正在使用标准 ActiveX 控件测试容器 (tstcon32.exe) 作为测试应用程序）选择我的代理 DLL。无论我做什么，程序似乎总是根据 进程资源管理器。到目前为止，我尝试了一些方法：

1. 将包含代理 DLL 的目录添加到 PATH 中，然后调用该程序；似乎没有任何效果。
2. 将我的代理 DLL 复制到与调用的程序相同的目录中；没有运气。
3. 在与调用的程序相同的目录中创建一个 .local 文件，如 动态链接库重定向文章并将我的代理 DLL 放入同一目录 - 也不起作用。但后来，我了解到这在更新的 Windows 版本上不再起作用。此外，根据 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs 注册表设置，ole32.dll 是“已知 DLL”，因此 .local<无论如何，基于 /code> 的重定向可能不会起作用。
4. 使用基于清单的重定向，如DLL重定向使用清单问题中所述，但这并没有'似乎也没有任何影响。然而，这种方法似乎并不简单，所以我很可能做错了什么。

是否有人有使用存根 DLL 将调用重定向到标准 DLL（例如 ole32.dll）的经验？您如何强制应用程序获取您的存根 DLL？

Answer 1

我意识到这有点晚了大约 6 个月，但我正在尝试同样的事情并有一些附加说明：

1. 您可以从 HKEY_LOCAL_MACHINE\SYSTEM\ 获取并删除 ole32.dll 的所有权CurrentControlSet\Control\Session Manager\KnownDLLs。这使您可以绕过 Windows 已锁定这些键的事实。
2. 在 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager 中创建值为 0 的键 SafeDllSearch 的方法是 假设更改搜索路径。

应用了这些技术并重新启动后，挂钩仍然不起作用。我更进一步，用我们的一张救援 CD（基于 Windows PE 的环境）启动了一台虚拟机，并覆盖了 system32 中的那个。结果 Windows 无法启动 - 没有符号错误，但我从来没有达到 LogonUI.exe 的程度。我的钩子函数可能被破坏了，所以这可能就是原因。

不管怎样，这产生了一种实际的、有形的钩子效应——尽管是一种尖叫“破碎”的效应！不幸的是，它似乎很难调试，我可能会求助于其他挂钩方法 - 即 IAT 修补。

编辑我执行的另一个实验是自己将 Dll 显式加载到目标进程的地址空间中。执行此操作的代码片段如下所示：

wchar_t* TargetPath = argv[1];
wchar_t DllPath[] = L"N:\\experiments\\ole32.dll";
STARTUPINFOW si;
PROCESS_INFORMATION pi;
memset(&si, 0, sizeof(STARTUPINFOW));
memset(&pi, 0, sizeof(PROCESS_INFORMATION));

// create process suspended
BOOL bResult = CreateProcess(NULL, TargetPath, NULL, NULL, FALSE, 
    CREATE_SUSPENDED, NULL, NULL, &si, &pi);

// write DLL name to remote process
void* RemoteAddr = VirtualAllocEx(pi.hProcess, NULL, sizeof(DllPath)+1, 
    MEM_RESERVE | MEM_COMMIT, PAGE_READONLY);
WriteProcessMemory(pi.hProcess, RemoteAddr, DllPath, sizeof(DllPath), &BytesWritten);

// get handle to LoadLibraryW
PTHREAD_START_ROUTINE pfLoadLibrary = (PTHREAD_START_ROUTINE) 
    GetProcAddress(GetModuleHandle(L"kernel32.dll"), "LoadLibraryW");

// create remote thread calling LoadLibraryW
HANDLE hThread = CreateRemoteThread(pi.hProcess, NULL, 
    0, pfLoadLibrary, RemoteAddr, 0, NULL);

// start remote process
ResumeThread(pi.hThread);

为简洁起见，删除了错误处理。

基本上，目标是在目标有机会从 system32 加载 ole32.dll 之前将我的 ole32.dll 强制加载到目标的地址空间中。就我而言，ole32.dll 稍后会在应用程序的加载例程中加载，因此理论上这应该有效。但实际情况并非如此。我不知道为什么。

更新 我的原始代码失败，因为 DLL 在运行时有未解析的符号警告。 这项技术确实有效 显然，它加载了我的 ole32.dll 和 system32 中的 ole32.dll。为了确保库加载成功，我在上面的代码中添加了一个 LoadLibrary(DllPath) 调用。

Answer 2

也许 winapioverride 可以帮助你。它可以记录所有 win api 调用，无需进行任何编程。因此，它会将 dll 注入到执行日志记录的进程中。如果我没记错的话，甚至在进程实际执行任何代码之前，也可以注入自己的自定义 dll。该文档包含一些有关监视 com 对象的信息。