Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Home NTDEV

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging


The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.


Check out The OSR Learning Library at: https://www.osr.com/osr-learning-library/


KMDF USB Filter Driver, intercepting interrupts from lower driver

new_kernel_dev999new_kernel_dev999 Member Posts: 5

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.

Comments

  • Doron_HolanDoron_Holan Member - All Emails Posts: 10,828
    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.
    d
  • new_kernel_dev999new_kernel_dev999 Member Posts: 5

    @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));
    }
    
  • Tim_RobertsTim_Roberts Member - All Emails Posts: 14,832

    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, [email protected]
    Software Wizard Emeritus

  • new_kernel_dev999new_kernel_dev999 Member Posts: 5
    > @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!
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Kernel Debugging 13-17 May 2024 Live, Online
Developing Minifilters 1-5 Apr 2024 Live, Online
Internals & Software Drivers 11-15 Mar 2024 Live, Online
Writing WDF Drivers 20-24 May 2024 Live, Online