Hi there, I am working on a test usb filter driver which purpose
is to prevent any keypresses from a keyboard. I am able to
modify the buffer of interrupts which contains the HID keypress
payload, but unable to completely block it from sending the
IRP to the next driver above (HID). I assume the driver above me
would complete and mark the IRP with something so that Windows will know
that the interrupt has been handled, but I’m not sure how to
fake the response when I complete the IRP on my stack.
I need a way to prevent the IRP from going up the hid stack.
Assuming you are a filter between hidusb and the pdo, set the completion routine for the read URB when it is sent down the stack. In the completion routine , format the request again as a read urb and send it down the stack (instead of completing it). A far simpler method to suppress keyboard presses is to filter higher in the stack between kbdhid and kbdclass. You register an input service routine where all you need to do is consume the reported data and never report it to the next service callback. The wdk kbfiltr example gets you 99% of the way there.
@Doron_Holan said:
Assuming you are a filter between hidusb and the pdo, set the completion routine for the read URB when it is sent down the stack. In the completion routine , format the request again as a read urb and send it down the stack (instead of completing it).
A far simpler method to suppress keyboard presses is to filter higher in the stack between kbdhid and kbdclass. You register an input service routine where all you need to do is consume the reported data and never report it to the next service callback. The wdk kbfiltr example gets you 99% of the way there.
Thanks for the response Doron.
My driver is a lower filter for the USB class, it is between
usbccgp and usbhub is the PDO. Is it possible to do it at this layer?
This is an implementation of what you said to do, but when the request
is sent, I receive an USBD_STATUS_FIFO error.
The code below is within a IoInternalDeviceControl completion routine,
intercepting all URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER when
a certain flag is set in the filter driver.
WDFMEMORY memory;
NTSTATUS status = WdfRequestRetrieveOutputMemory(Request, &memory);
if (!NT_SUCCESS(status)) {
break;
}
status = WdfIoTargetFormatRequestForRead(WdfDeviceGetIoTarget(device), Request, memory, NULL, NULL);
if (!NT_SUCCESS(status)) {
break;
}
if (WdfRequestSend(Request, WdfDeviceGetIoTarget(device), WDF_NO_SEND_OPTIONS) == FALSE) {
status = WdfRequestGetStatus(Request);
KdPrint(("Line: %d, URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER WdfRequestSend for READ urb failed, status: 0x%x\n", __LINE__, status));
}
Just as a piece of friendly advice, Doron was the Microsoft engineer in charge of the HID device stack for a number of years. If he suggests a better path for your problem, then it is the better path.
Where, exactly, did you see that error? The USBD errors are only returned inside the URB. If you got an IRP status of C0000010, that’s STATUS_INVALID_DEVICE_REQUEST.
> @Tim_Roberts said: > Just as a piece of friendly advice, Doron was the Microsoft engineer in charge of the HID device stack for a number of years. If he suggests a better path for your problem, then it is the better path. > > Where, exactly, did you see that error? The USBD errors are only returned inside the URB. If you got an IRP status of C0000010, that’s STATUS_INVALID_DEVICE_REQUEST. Hi Tim, sorry for the confusion. Like you said, it is indeed the IRP status STATUS_INVALID_DEVICE_REQUEST. I am not sure where to go on from here, but I’m thinking of implementing a filter on the hid stack instead. Thanks for the advice!