SetWindowsHookEx()函数 !!!!!!!!! 难道没人能搞定吗!!!!!!!

SetWindowsHookEx()函数中每一个Hook都有一个与之相关联的指针列表，称之为钩子链表，由系统来维护。这个列表的指针指向指定的，应用程序定义的，被Hook子程调用的回调函数，也就是该钩子的各个处理子程。当与指定的Hook类型关联的消息发生时，系统就把这个消息传递到Hook子程。一些Hook子程可以只监视消息，或者修改消息，或者停止消息的前进，避免这些消息传递到下一个Hook子程或者目的窗口。最近安装的钩子放在链的开始，而最早安装的钩子放在最后，也就是后加入的先获得控制权。

 Windows 并不要求钩子子程的卸载顺序一定得和安装顺序相反。每当有一个钩子被卸载，Windows 便释放其占用的内存，并更新整个Hook链表。如果程序安装了钩子，但是在尚未卸载钩子之前就结束了，那么系统会自动为它做卸载钩子的操作。

谁能彻底分析一下钩子，如何才能从内核阻止SetWindowsHookEx()函数的运行。我已经问过多次，但一直没有人能回答这处问题，难到真的没人能回答吗？钩子链表在那里，能控制住吗？比如控制住不让往链表中加入新的回调函数，由此阻止安装钩子。

防止全局钩子的侵入
Author: pjf(jfpan20000@sina.com)
Windows消息钩子一般都很熟悉了。它的用处很多，耳熟能详的就有――利用键盘钩子获取目标进程的键盘输入，从而获得各类密码以达到不可告人的目的。朋友想让他的软件不被别人的全局钩子监视，有没有办法实现呢？答案是肯定的，不过缺陷也是有的:)。
首先简单看看全局钩子如何注入别的进程。
消息钩子是由Win32子系统提供，其核心部分通过NtUserSetWindowsHookEx为用户提供了设置消息钩子的系统服务，用户通过它注册全局钩子。当系统获取某些事件，比如用户按键，键盘driver将扫描码等传入win32k的KeyEvent处理函数，处理函数判断有无相应hook，有则callhook。此时，系统取得Hook对象信息，若目标进程没有装载对应的Dll，则装载之（利用KeUserModeCallback“调用”用户例程，它与Apc调用不同，它是仿制中断返回环境，其调用是“立即”性质的）。
进入用户态的KiUserCallbackDispatcher后，KiUserCallbackDispatcher根据传递的数据获取所需调用的函数、参数等，随后调用。针对上面的例子，为装载hook dll，得到调用的是LoadLibraryExW，随后进入LdrLoadDll，装载完毕后返回，后面的步骤就不叙述了。
从上面的讨论我们可以得出一个最简单的防侵入方案：hook api使得加载失败，不过有一个缺陷：系统并不会因为一次的失败而放弃，每次有消息产生欲call hook时系统都会试图在你的进程加载dll，这对于性能有些微影响，不过应该感觉不到。剩下一个问题就是不是所有的LoadLibraryExW都应拦截，这个容易解决，比如判断返回地址。下面给出一个例子片断，可以添加一些判断使得某些允许加载的hook dll被加载。
这里hook api使用了微软的detours库，随需要修改。

typedef HMODULE (__stdcall *LOADLIB)(
LPCWSTR lpwLibFileName,
HANDLE hFile,
DWORD dwFlags
);

extern \"C\" {
DETOUR_TRAMPOLINE(HMODULE __stdcall Real_LoadLibraryExW(
LPCWSTR lpwLibFileName,
HANDLE hFile,
DWORD dwFlags),
LoadLibraryExW);
}

ULONG user32 = 0;

HMODULE __stdcall Mine_LoadLibraryExW(
LPCWSTR lpwLibFileName,
HANDLE hFile,
DWORD dwFlags)
{
ULONG addr;

_asm mov eax, [ebp+4]
_asm mov addr, eax

if ((user32 & 0xFFFF0000) == (addr & 0xFFFF0000))
{
return 0;
}

HMODULE res = (LOADLIB(Real_LoadLibraryExW)) (
lpwLibFileName,
hFile,
dwFlags );

return res;
}

BOOL ProcessAttach()
{
DetourFunctionWithTrampoline((PBYTE)Real_LoadLibraryExW,
(PBYTE)Mine_LoadLibraryExW);
return TRUE;
}

BOOL ProcessDetach()
{
DetourRemove((PBYTE)Real_LoadLibraryExW,
(PBYTE)Mine_LoadLibraryExW);
return TRUE;
}

CAnti_HookApp::CAnti_HookApp() //在使用用户界面服务前调用ProcessAttach
{
user32 = (ULONG)GetModuleHandle(\"User32.dll\");
ProcessAttach();
}

对使用MS的detours可以HOOK库函数，从而达到目的

首先感谢两位的帮助， 不过我的问题是如何阻止一个程序安装全局钩子，即阻止SetWindowsHookEx()这个函数的成功执行，而不是防止全局钩子侵入一个程序。如同文章中所讲的：系统并不会因为一次的失败而放弃，每次有消息产生欲call hook时系统都会试图在你的进程加载dll，这对于性能有影响。若成功阻止了SetWindowsHookEx()这个函数的成功执行，则对性能就不会有什么影响了。大家再想想办法，谢谢！！！！！！！！

那你就HOOK  SERVICE SHADOW TABLE里的NATIVE API看看......

首先感谢两位的帮助， 不过我的问题是如何阻止一个程序安装全局钩子，即阻止SetWindowsHookEx()这个函数的成功执行，而不是防止全局钩子侵入一个程序。如同文章中所讲的：系统并不会因为一次的失败而放弃，每次有消息产生欲call hook时系统都会试图在你的进程加载dll，这对于性能有影响。若成功阻止了SetWindowsHookEx()这个函数的成功执行，则对性能就不会有什么影响了。大家再想想办法，谢谢！！！！！！！！

我已经回复多次，在内核中hook 这个_NtUserSetWindowsHookEx
顺便看看
http://www.driverdevelop.com/forum/viewthread.php?tid=87345
http://www.driverdevelop.com/forum/html_87401.html?1110773293
或用bmyyyud搜

我看到了你的贴子，可没看明白。楼上兄弟能否讲详细一些，你是如何知道SetWindowsHookEx()对应的内核函数是NtUserWindowsHookEx()？我从W2K的源代码中看到前者是调用了后者，可如何确定其是内核中的实现，因为都是在W2K的源代码中，我认为NtUserWindowsHookEx()也可能是在上层Shell中实现的，另外，你又是如何找到它的中断号的？我反汇编了user32.dll，发现SetWindowsHookEx()最终调用了1212号中断，和你给的不一样，是和不同的版本有关系吗？还有，NtUserWindowsHookEx()的原型是什么，如何进行挂钩？和服务表中函数相同吗？谢谢。

我看到了你的贴子，可没看明白。楼上兄弟能否讲详细一些，你是如何知道SetWindowsHookEx()对应的内核函数是NtUserWindowsHookEx()？我从W2K的源代码中看到前者是调用了后者，可如何确定其是内核中的实现，因为都是在W2K的源代码中，我认为NtUserWindowsHookEx()也可能是在上层Shell中实现的，另外，你又是如何找到它的中断号的？我反汇编了user32.dll，发现SetWindowsHookEx()最终调用了1212号中断，和你给的不一样，是和不同的版本有关系吗？还有，NtUserWindowsHookEx()的原型是什么，如何进行挂钩？和服务表中函数相同吗？谢谢。

NtUserWindowsHookEx在大家所说的影子服务表中，影子服务表对应win32k.sys中的函数，win32k.sys肯定在核心中。因为它经过了sysenter进入核心。其实在NT4以前win32k.sys的东东在用户层，但由于性能问题，最终被移到核心。win32k中的k即kernel之意
至于发现SetWindowsHookEx()最终调用了1212号中断，和你给的不一样，我估计你说的是服务号为1212号，中断号没那么大，其实服务号为1212，服务总数也没那么大，0-0xfff是给ntoskrnl用的，大于0xfff才是给win32k用的，与我给出的不同，肯定和不同的版本有关，我是在Xp sp2下的结果。至于NtUserWindowsHookEx()的原型，通过影子服务表可以查出参数个数，如果要得到具体参数，跟踪一下SetWindowsHookEx()，当它进入核心，即调用sysenter时，edx指向的便为NtUserWindowsHookEx接收的参数

送上50分，欢迎大家参加讨论，争取把这个问题搞明白！谢谢！！！