KeUserModeCallback函数

内核调用用户#

正常的系统调用过程为Ring3->Ring0->Ring3，而KeUserModeCallback提供了一种Ring0->Ring3->Ring0的方式，即从内核去用户层执行代码。

KeUserModeCallback (
    IN ULONG ApiNumber,					//对应函数在KernelCallback表中的索引
    IN PVOID InputBuffer,				//ApiNumber不同（即调用的函数不同），此参数对应不同的结构
    IN ULONG InputLength,
    OUT PVOID *OutputBuffer,			        //执行后输出的结果
    IN PULONG OutputLength
    )

KeUserModeCallback是ntoskrnl.exe导出的，系统中很多回调机制都是通过KeUserModeCallback实现的。
其参数ApiNumber是需要执行的回调函数在KernelCallback回调函数表中的索引，这张回调函数表的地址存放在PEB->KernelCallback中的每一个函数都有不同的用处，在windbg中好看如下。

其对应的回调函数表为：

第二个参数InputBuffer会根据ApiNumber索引回调函数的不同而指向不同的结构体，第四个参数OutputBuffer指向的缓冲区中是执行完回调函数后返回的信息。

KeUserModeCallback的执行流程#

一般是含有GDI系统服务的win32k.sys调用KeUserModeCallback，所以一般要HOOKKeUserModeCallback时都会通过IAThook win32k.sys的导入表中对KeUserModeCallback的调用。接着会调用nt!KiCallUserMode--->KiServiceExit--->sysexit进入应用层中，然后在应用层执行的第一个函数就是ntdll!KiUserCallbackDispatcher。
、
为什么调用堆栈中没有显示调用了nt!KiServiceExit呢，因为其是通过nt！KiCallUserMode执行jmp执行调用的。

应用层执行的第一个函数就是ntdll!KiUserCallbackDispatcher，此函数会根据从内核中传入的ApiNumber也就是回调函数在KernelCallback回调函数表中的索引调用对应的回调函数，执行完对应的回调函数调用User32！XyCallbackReturn,此函数会在内部执行int 0x2e,通过中断门返回内核。

接着回到内核中后执行的第一个函数就是nt!KiCallbackReturn,然后会继续返回到nt!KeUserModeCallback中。

总结一般其调用过程就是这样

win32k.sys --->nt!KeUserModeCallback --->nt!KiCallUserMode--->KiServiceExit--->sysexit     //Ring0--->Ring3

ntdll!KiUserCallbackDispatcher--->对应KernelCallback表中的回调函数                           //Ring3

对应KernelCallback表中的回调函数--->User32！XyCallbackReturn--->int 0x2e                     //Ring3--->Ring0

nt!KiCallbackReturn--->nt!KeUserModeCallback                                               //Ring0

KeUserModeCallback的应用#

全局钩子#

我们通常利用SetWindwosHook设置全局消息钩子来实现dll注入，其实其就是利用nt!KeUserModeCallback函数来完成函数的调用的。
当我们在一个应用程序中调用SetWindowsHook安装全局消息钩子并设置hook回调函数后，如果我们这时候打开另一个程序，如果此程序是一个GUI程序，其在加载过程中会产生一些消息，这样系统就会尝试调用我们刚刚注册的全局消息回调函数，如果发现此回调函数对应的dll还没有加载其就会尝试加载此dll，从而实现dll的注入。

这其实就是内核通过调用nt!KeUserModeCallback 函数，然后进入到用户层后调用KernelCallback回调函数表中的位于USER32.dll模块中的USER32!_ClientLoadLibrary函数，此函数会进一步调用kernel32！LoadLibraryEx加载需要加载的dll文件。
对应的nt!KeUserModeCallback 的InputBuffer参数结构为，

typedef struct DLLHOOK
{
DWORD      dwBufferSize;        	//结构长度
DWORD      dwAdditionalData;    
DWORD      dwFixupsCount;        
LPVOID     pbFree                
DWORD      offCbkPtrs;           
DWORD      bFixed;                
UNICODE_STRING lpDLLPath;         	//加载的Dll名字
union
{
DWORD      lpfnNotify                   // 调用函数相对于模块的RVA
UNICODE_STRING lpInitFunctionName;      // 调用函数名
}
DWORD      offCbk[2];              
};

所以只有GDI程序，即加载user32.dll的程序才能使用全局消息钩子注入dll了。我们可以通过IAThook win32k.sys的KeUserModeCallback函数并判断dll的名字来达到防止全局消息钩子注入。

WH_JOURNALRECORD消息记录钩子#

我们可以调用SetWindowsHook来设置WH_JOURNALRECORD消息记录钩子，这要求我们提供一个回调函数，且此回调函数和设置WN_JOURNALRECORD消息钩子的进程是在同一进程地址空间中，那么当其他进程产生鼠标或者键盘消息的时候是如何发送到此回调函数中处理的呢。实际上其也是利用KeUserModeCallback函数。

产生消息的进程通过调用USER32.dll中的PeekMessage()将消息发送到内核中，然后在内核中会调用KeUserModeCallback函数并将消息传递给他，之后会调用PEB->KernelCallback回调函数表中的USER32!_fnHkOPTINLPEVENTMSG（）。这个函数会调用我们设置的那个用户层的消息回调函数。

如果我们想对消息记录钩子进行拦截就可以IAThook win32k.sys中导入的KeUserModeCallback函数。

WM_COPYDATA进程间通讯#

我们可以利用WM_COPYDATA进行进程间通讯，通过SendMessage发送WM_COPYDATA消息给目标进程的窗口过程并传递COPYDATASTRUCT结构传递信息，然后目标进程的窗口过程会处理接收到的WM_COPYDATA消息并接收到COPYDATASTRUCT结构。其原理是通过将COPYDATASTRUCT结构复制到内核中，然后调用KeUserModeCallback函数并接着调用USER32!_fnCOPYDATA函数并将COPYDATASTRUCT结构从内核层复制到接收进程的用户层，然后调用其对应的窗口过程。