Yikes, a lot of scary things here
-
Why are you hooking kbdclass directly? NEVER do this. You should just install yourself as a class upper filter and process the read irps on your own. This can be done in KMDF, the kbdfiltr example shows how to capture packets using the class callback. Converting this to filter read requests is not that hard
-
You are not even hooking all the keyboards, or maybe even the real physical keyboard. \Device\KeyboardClass0 is not guaranteed to be a physical keyboard, it could be virtual.
-
you still didn’t show the code for NewIrpMjReadFunction which is setting up the completion routine, but that point is moot now. You should not be hooking kbdclass directly which means that you should throw what you have in NewIrpMjReadFunction and start over
-
irp->AssociatedIrp.SystemBuffer is only valid as long as the IRP has not yet completed back to the io manager. This means that after calling IoQueueWorkItem you need to return STATUS_MORE_PROCESSING_REQUIRED. Instead in your code below you return != STATUS_MORE_PROCESSING_REQUIRED which will complete the irp back to the io manager. This means that by the time your work item executes, irp->AssociatedIrp.SystemBuffer has been freed, or ever worse for you, reallocated and means something else entirely. To accomplish this you must queue the read irp into your device extension (and you cannot just use one field, there can be many read irps completing before your work item runs) before queueing the work item and then in the work item routine you must dequeue the read irps, send them over the socket and then complete them.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of barun parichha
Sent: Monday, November 19, 2007 1:21 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Socket in DISPATCH_LEVEL
I am capturing the key events in one machine and sending the buffer
(irp->AssociatedIrp.SystemBuffer) from KbdHookIoCompletion to remote
machine. I am trying to extend keyboard device over IP, where device
keyboard will be at one end whereas the response will be in another
end.
The sample code as follows.
NTSTATUS DriverEntry(PDRIVER_OBJECT DriverObject, PUNICODE_STRING RegistryPath)
{
// install the hook
status = InstallKeyboardDriverHook();
…
…
}
NTSTATUS InstallKeyboardDriverHook()
{
NTSTATUS status;
PDEVICE_OBJECT deviceObject = NULL;
UNICODE_STRING deviceName;
ULONG i=10,total;
DbgPrint(" KbdHook - Installing the Keyboard Driver Hook \n");
RtlInitUnicodeString(&deviceName,L"\Device\KeyboardClass0");
status = IoGetDeviceObjectPointer(&deviceName, FILE_READ_DATA,
&fileObj, &deviceObj);
if(!NT_SUCCESS(status))
{
DbgPrint(“\n KbdHook - Unable to get the keyboard device obj ptr \n”);
return status;
}
driverObj = deviceObj->DriverObject;
OldIrpMjReadFunction = driverObj->MajorFunction[IRP_MJ_READ];
// Hook the new function in the driver object
/* We InterlockedExchange an atomic method
used to replace the READ function pointer
Library Used : Kernel32.dll */
if(OldIrpMjReadFunction)
InterlockedExchange((PLONG)&driverObj->MajorFunction[IRP_MJ_READ],
(LONG)NewIrpMjReadFunction);
return STATUS_SUCCESS;
}
On Nov 19, 2007 4:28 PM, Doron Holan wrote:
> None of this makes sense. Why queue a work item and then continue processing? Why are you hooking another driver’s completion routine? If you are in the keyboard stack you have your own completion routine. You should also post yoru hooking routine which sets up the completion roution. You need to send the output of !analyze -v
>
> d
>
> -----Original Message-----
> From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of barun parichha
> Sent: Sunday, November 18, 2007 10:15 PM
> To: Windows System Software Devs Interest List
>
> Subject: Re: [ntdev] Socket in DISPATCH_LEVEL
>
> I am posting the code here. I guess it’ll not work bcse I am always in
> DISPATCH_LEVEL and workitem will be dequeued only if it gets some
> PASSIVE_LEVEL thread.
>
>
> NTSTATUS KbdHookIoCompletion(PDEVICE_OBJECT DeviceObject, PIRP irp,
> PVOID Context)
> {
> PIO_STACK_LOCATION irpStack;
> PKEYBOARD_INPUT_DATA keyData;
> PIO_COMPLETION_ROUTINE oldCompletionRoutine;
> int numKeys, i,len;
> NTSTATUS status;
> KIRQL oldIrq;
>
> PIO_WORKITEM WorkItemPtr;
> WorkItemPtr = IoAllocateWorkItem(DeviceObject);
> if (WorkItemPtr == NULL)
> {
> DbgPrint(“IoAllocateWorkItem failed\n”);
> return (STATUS_INSUFFICIENT_RESOURCES);
> }
>
> IoQueueWorkItem(
> WorkItemPtr,
> (PIO_WORKITEM_ROUTINE) crit_routine,
> DelayedWorkQueue, //
> (PVOID) WorkItemPtr
> );
>
> DbgPrint(" KbdHookIoCompletionRoutine* \n");
>
> irpStack = IoGetCurrentIrpStackLocation( irp );
> oldCompletionRoutine = irpStack->Context;
>
> // if original IRP function is there, call it
> if ((irp->StackCount > (ULONG)1) && (oldCompletionRoutine != NULL))
> {
> DbgPrint(" KbdHook - Calling Old IO completion routine \n");
> return (oldCompletionRoutine)(DeviceObject, irp, NULL);
> }
> else
> {
> return irp->IoStatus.Status;
> }
>
>
>
>
>
> VOID crit_routine(PDEVICE_OBJECT pdev, PVOID WorkItemPtr)
> {
> NTSTATUS status;
> ULONG total=0;
>
>
> //file creation … to test whether PASSIVE_LEVEL things will work
> UNICODE_STRING fileName;
> HANDLE pHandle;
> IO_STATUS_BLOCK IoB;
> OBJECT_ATTRIBUTES objAttr;
>
> RtlInitUnicodeString(&fileName, L"\DosDevices\c:\temp.txt");
> InitializeObjectAttributes(&objAttr, &fileName, OBJ_CASE_INSENSITIVE
> | OBJ_KERNEL_HANDLE, NULL, NULL);
>
> status = ZwCreateFile(&pHandle, GENERIC_WRITE, &objAttr, &IoB, NULL,
> FILE_ATTRIBUTE_NORMAL, 0, FILE_OVERWRITE_IF,
> FILE_SYNCHRONOUS_IO_NONALERT, NULL, 0);
> if(NT_SUCCESS(status))
> DbgPrint(“File Created”);
> else
> DbgPrint(“File Not Created”);
>
> ZwClose(pHandle);
> IoFreeWorkItem ((PIO_WORKITEM)WorkItemPtr);
> }
>
>
>
>
> On Nov 19, 2007 3:27 PM, Doron Holan wrote:
> > If you did not raise IRQL, you cannot lower it. So kcalling KeLowerIrql without a matching KeRaiseIrql before it in your code is not allowed. The correct way is to use IoQueueWorkItem to get to passive in another thread. Please post the system crash results (!analyze -v) when you try to use work items (or post the code, the mistake may be obvious)
> >
> > d
> >
> > -----Original Message-----
> > From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@gmail.com
> > Sent: Sunday, November 18, 2007 7:55 PM
> > To: Windows System Software Devs Interest List
> > Subject: [ntdev] Socket in DISPATCH_LEVEL
> >
> > How can we run a PASSIVE_LEVEL API in DISPATCH_LEVEL ?
> >
> > I am capturing some information in a DISPATCH_LEVEL routine and I want to send these informations to remote place by socket, which runs in PASSIVE_LEVEL.
> >
> > I tried to use KelowerIrql and also used IoQueueWorkItem , but the system crashes. I guess I am not using the right method.
> >
> > I am new to kernel driver programming, so please excuse me for asking such questions.
> > Any help will be appreciated.
> >
> > Regards,
> > Barun
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
> > —
> > NTDEV is sponsored by OSR
> >
> > For our schedule of WDF, WDM, debugging and other seminars visit:
> > http://www.osr.com/seminars
> >
> > To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
> >
>
>
>
> –
> Barun Kumar Parichha,
> Research Scholar,
> Dept of Computer Science & Engg.
> I.I.T. Madras
> Chennai - 36
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
>
–
Barun Kumar Parichha,
Research Scholar,
Dept of Computer Science & Engg.
I.I.T. Madras
Chennai - 36
—
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer