这里有些背景信息。我正在替换一个dll,该dll通过“AppInit_DLLs”注册表项在dll注入技术中使用。它的目的是存在于每个进程中,并设置钩子到GDI32.dll以收集有关打印的信息。这是一种有点奇特的方式来获取我们想要的结果。这个.dll本身已经超过10年了(使用Visual Studio 97编写),我们希望用比注入dll更少侵入性的东西来替换它。
看起来“SetWindowsHookEx()”可能是我们正在寻找的东西。我遇到了一些问题,但我也与同事讨论过我们是否应该继续追求这个方向。以下是我们无法确定的一些问题:
1.当我们钩取一个dll中的例程(例如GDI32.dll中的StartDoc())时,我们是否真的会在任何其他进程使用该dll中的例程时得到通知?这是我们使用注入的.dll获得的功能,我们需要相同的功能。
2.当触发钩子时,钩子处理过程是在实际调用的进程空间中运行还是在设置钩子的进程空间中运行?我的意见是它必须在调用例程的进程空间中运行。例如,如果程序从GDI32.dll调用StartDoc(),它将把钩子处理过程代码“注入”到其空间中并执行。否则,必须在调用进程和设置钩子的进程之间自动建立一些进程间通信,并且我认为这不可能是真的。此外,由于需要知道其中一个内容是调用进程的名称,因此必须使此钩子处理例程在调用进程的进程空间中运行。如果不是实际运行在该进程中,我不确定如何获取该信息。
3.如果使用.NET托管环境编写钩子处理例程,那么当钩入未使用.NET托管环境的进程时,它会出现问题吗?我们真的想在这里摆脱C++并使用C#,但是如果我们的钩子从未托管的进程中调用,会发生什么情况?如前所述,我认为我们的钩子处理例程将在最初调用已钩住例程的进程中运行。但是,如果这是真的,那么我认为如果该进程没有使用.NET运行时环境,而传入的钩子处理代码正在使用,则我们可能会遇到麻烦。
看起来“SetWindowsHookEx()”可能是我们正在寻找的东西。我遇到了一些问题,但我也与同事讨论过我们是否应该继续追求这个方向。以下是我们无法确定的一些问题:
1.当我们钩取一个dll中的例程(例如GDI32.dll中的StartDoc())时,我们是否真的会在任何其他进程使用该dll中的例程时得到通知?这是我们使用注入的.dll获得的功能,我们需要相同的功能。
2.当触发钩子时,钩子处理过程是在实际调用的进程空间中运行还是在设置钩子的进程空间中运行?我的意见是它必须在调用例程的进程空间中运行。例如,如果程序从GDI32.dll调用StartDoc(),它将把钩子处理过程代码“注入”到其空间中并执行。否则,必须在调用进程和设置钩子的进程之间自动建立一些进程间通信,并且我认为这不可能是真的。此外,由于需要知道其中一个内容是调用进程的名称,因此必须使此钩子处理例程在调用进程的进程空间中运行。如果不是实际运行在该进程中,我不确定如何获取该信息。
3.如果使用.NET托管环境编写钩子处理例程,那么当钩入未使用.NET托管环境的进程时,它会出现问题吗?我们真的想在这里摆脱C++并使用C#,但是如果我们的钩子从未托管的进程中调用,会发生什么情况?如前所述,我认为我们的钩子处理例程将在最初调用已钩住例程的进程中运行。但是,如果这是真的,那么我认为如果该进程没有使用.NET运行时环境,而传入的钩子处理代码正在使用,则我们可能会遇到麻烦。