USB or HID lower level filter drivers

OSR_Community_User · March 22, 2011, 12:30am

My current goal is to develop a fairly simple filter driver for HID hardware. It is an HID device connected to the USB. I need to intercept the incoming reports from the device and modify them on the fly. Now I have not decided whether to implement on the USB level or the HID level but currently I am able to get my USB lower level filter driver up and running and am able to see USB_SUBMIT_URB IOCTLs being called.

Please advise,
Thanks in advance.
Safi

Doron_Holan · March 22, 2011, 12:51am

What type of modifications do you want to make? I would think a USB lower filter below usbhid would be the way to go given your initial description .

d

dent from a phine with no keynoard

-----Original Message-----
From: xxxxx@razerzone.com
Sent: Monday, March 21, 2011 9:29 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB or HID lower level filter drivers

My current goal is to develop a fairly simple filter driver for HID hardware. It is an HID device connected to the USB. I need to intercept the incoming reports from the device and modify them on the fly. Now I have not decided whether to implement on the USB level or the HID level but currently I am able to get my USB lower level filter driver up and running and am able to see USB_SUBMIT_URB IOCTLs being called.

Please advise,
Thanks in advance.
Safi

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

OSR_Community_User · March 22, 2011, 1:05am

I need to pass the pointer data from the packet/report to a black box function which gives me new coordinates which I need to write into the packet and send up the stack.

USB level is a bit too low level for me, so the question 1 is,
Why can’t I write a HID lower level filter and do the modifications there? And why not a USB Upper level filter for that matter?

And the question 2 is,
How do I access, read and modify the packets at the USB level?

I am under the impression, that since USB_SUBMIT_URB is METHOD_NEITHER, I ll write a try-except block with ProbeForRead and Probe for write calls. and then try to read the request buffers somehow (something which I have nt been able to nail down yet, and would greatly appreciate your help with.)

Doron_Holan · March 22, 2011, 2:17am

You read (on the way down) or modify (on the way back up in the completion routine) by looking in Parameters.Others.Argument1. don’t look at the encoding of USB_SUBMIT_URB since it is only sent by a KM driver, the normal encoding rules do not apply. Sending the packet to the black box and back to the driver is problematic as lower hid filter, hidusb/hidclass will fail any creates against your filter. Same goes as a lower filter below mouhid as a hid filter. You will need to use a control device or a raw PDO (as demonstrated in kbdfiltr or moufiltr) as the channel to talk to your black box

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@razerzone.com
Sent: Monday, March 21, 2011 10:04 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB or HID lower level filter drivers

I need to pass the pointer data from the packet/report to a black box function which gives me new coordinates which I need to write into the packet and send up the stack.

USB level is a bit too low level for me, so the question 1 is, Why can’t I write a HID lower level filter and do the modifications there? And why not a USB Upper level filter for that matter?

And the question 2 is,
How do I access, read and modify the packets at the USB level?

I am under the impression, that since USB_SUBMIT_URB is METHOD_NEITHER, I ll write a try-except block with ProbeForRead and Probe for write calls. and then try to read the request buffers somehow (something which I have nt been able to nail down yet, and would greatly appreciate your help with.)

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

OSR_Community_User · March 22, 2011, 2:38am

Am I to understand that I need to go down to IRP level to access the data? IAre n’t there any WDF methods to access the URB, say if it is enclosed in a WdfRequest should nt I be able to access it using WdfRequestRetrieveOutputBuffer or something?

Doron_Holan · March 22, 2011, 2:57am

Nope. KMDF does not have an API that understands how to pull a URB properly out of a WDFREQUEST, all of the buffer extraction APIs assume std encoding (since each bus which has a KM IOCTL submit interface like scsi (SRB), usb (URB), 1394 (IRB), Bluetooth (BRB) is custom, it makes little sense for KMDF to understand each one from the POV of pulling the request block out of the request)

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@razerzone.com
Sent: Monday, March 21, 2011 11:37 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB or HID lower level filter drivers

Am I to understand that I need to go down to IRP level to access the data? IAre n’t there any WDF methods to access the URB, say if it is enclosed in a WdfRequest should nt I be able to access it using WdfRequestRetrieveOutputBuffer or something?

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

OSR_Community_User · March 22, 2011, 1:46pm

VOID
DispatchPassThrough(
IN WDFREQUEST arg_objRequest,
IN WDFIOTARGET arg_objTarget
)
/*++
Routine Description:

Passes a request on to the lower driver.

–*/
{
//
// Pass the IRP to the target
//

WDF_REQUEST_SEND_OPTIONS options;
BOOLEAN ret;
NTSTATUS status = STATUS_SUCCESS;

//
// We are not interested in post processing the IRP so
// fire and forget.
//
WDF_REQUEST_SEND_OPTIONS_INIT(&options,
WDF_REQUEST_SEND_OPTION_SEND_AND_FORGET);

ret = WdfRequestSend(arg_objRequest, arg_objTarget, &options);

if (ret == FALSE) {
status = WdfRequestGetStatus (arg_objRequest);
KdPrint( (“WdfRequestSend failed: 0x%x\n”, status));
WdfRequestComplete(arg_objRequest, status);
}

return;
}

VOID
EvtIoInternalDeviceControl (
IN WDFQUEUE arg_objQueue,
IN WDFREQUEST arg_objRequest,
IN size_t arg_dOutputBufferLength,
IN size_t arg_dInputBufferLength,
IN ULONG arg_dIoControlCode
)
{
NTSTATUS status;
WDFDEVICE objDevice;
WDFIOTARGET objIoTarget;
WDFMEMORY objRequestMemory;
PDEVICE_CONTEXT pDeviceContext;
size_t dBytesTransferred = 0;

PURB pUrbBuffer = NULL;
WDF_REQUEST_PARAMETERS objRequestParameters;

UNREFERENCED_PARAMETER(arg_dInputBufferLength);
UNREFERENCED_PARAMETER(arg_dOutputBufferLength);

KdPrint((“TESTDRIVER: MESSAGE: —>EvtIoInternalDeviceControl\n”));

objDevice = WdfIoQueueGetDevice (arg_objQueue);
pDeviceContext = GetDeviceContext ( objDevice );

KdPrint((“TESTDRIVER: MESSAGE: Proceeding to handle I/O Control Request with code 0x%x”, arg_dIoControlCode));

switch (arg_dIoControlCode)
{
case IOCTL_INTERNAL_USB_SUBMIT_URB:

KdPrint((“TESTDRIVER: MESSAGE: IOCTL_INTERNAL_USB_SUBMIT_URB I/O Control Request.\n”));
KdPrint((“TESTDRIVER: MESSAGE: Input Buffer size = %d \n”, arg_dInputBufferLength));
KdPrint((“TESTDRIVER: MESSAGE: Output Buffer size = %d \n”, arg_dOutputBufferLength));

WDF_REQUEST_PARAMETERS_INIT(&objRequestParameters);
WdfRequestGetParameters ( arg_objRequest, &objRequestParameters );

pUrbBuffer = objRequestParameters.Parameters.Others.Arg1;
KdPrint((“TESTDRIVER: MESSAGE: Extracting URB data from the request. Request metadata as follows: \n”));
KdPrint((“TESTDRIVER: MESSAGE: Request Size = 0x%x \t Request Function = 0x%x \t Request Type = 0x%x \n”,
objRequestParameters.Size, objRequestParameters.MinorFunction, objRequestParameters.Type));

KdPrint((“TESTDRIVER: MESSAGE: URB data from the request. URB Header data as follows: \n”));
KdPrint((“TESTDRIVER: MESSAGE: URB Length = 0x%x \t URB Function = 0x%x \t URB Status = 0x%x \n”,
pUrbBuffer->UrbHeader.Length, pUrbBuffer->UrbHeader.Function, pUrbBuffer->UrbHeader.Status));

switch (pUrbBuffer->UrbHeader.Function)
{
case URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER:
KdPrint((“TESTDRIVER: MESSAGE: URB Function decoded to be BULK_OR_INTERRUPT_TRANSFER. \n”));

WdfRequestSetCompletionRoutine ( arg_objRequest, EvtInterruptTransferCompletionRoutine, NULL );

objIoTarget = WdfDeviceGetIoTarget ( objDevice );

if ( objIoTarget != NULL )
{
KdPrint((“TESTDRIVER: MESSAGE: Valid I/O Target. \n”));
DispatchPassThrough ( arg_objRequest, objIoTarget );
}
else
{
KdPrint((“TESTDRIVER: MESSAGE: Invalid Target. \n”));
WdfRequestComplete ( arg_objRequest, STATUS_NOT_IMPLEMENTED );
}

break;

case URB_FUNCTION_ABORT_PIPE:

break;

default:
break;
}

break;

default:
KdPrint ((“TESTDRIVER: MESSAGE: Unhandled I/O Control Request. Passing it to other stack drivers if any.\n”));
break;
}

objIoTarget = WdfDeviceGetIoTarget ( objDevice );
if ( objIoTarget != NULL )
{
KdPrint((“TESTDRIVER: MESSAGE: Valid I/O Target. \n”));
DispatchPassThrough ( arg_objRequest, objIoTarget );
}
else
{
KdPrint((“TESTDRIVER: MESSAGE: Invalid Target. \n”));
WdfRequestComplete ( arg_objRequest, STATUS_NOT_IMPLEMENTED );
}

KdPrint((“TESTDRIVER: MESSAGE: <—EvtIoInternalDeviceControl\n”));
}

VOID
EvtInterruptTransferCompletionRoutine (
IN WDFREQUEST arg_objRequest,
IN WDFIOTARGET arg_objTarget,
IN PWDF_REQUEST_COMPLETION_PARAMS arg_objReqComplnParams,
IN WDFCONTEXT arg_objContext
)
{
NTSTATUS status = STATUS_SUCCESS;
PURB pUrbBuffer = NULL;
size_t dBytesTranferred = 0;

WDF_REQUEST_PARAMETERS objRequestParameters;

UNREFERENCED_PARAMETER(arg_objContext);

KdPrint((“TESTDRIVER: MESSAGE: —>EvtInterruptTransferCompletionRoutine\n”));

WDF_REQUEST_PARAMETERS_INIT(&objRequestParameters);
WdfRequestGetParameters ( arg_objRequest, &objRequestParameters );

pUrbBuffer = objRequestParameters.Parameters.Others.Arg1;

if ( pUrbBuffer->UrbHeader.Function == URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER )
if ( pUrbBuffer->UrbBulkOrInterruptTransfer.TransferBufferLength > 0 && pUrbBuffer->UrbBulkOrInterruptTransfer.TransferBuffer != NULL )
{
//MyCode Here
}

WdfRequestComplete ( arg_objRequest, status );

KdPrint((“TESTDRIVER: MESSAGE: <—EvtInterruptTransferCompletionRoutine\n”));
}

Here is the code that I wrote to read the URBs, I am able to look at the URB, but as soon as I send the request out, things go bad and I get a Blue screen. What am I doing wrong here?

Doron_Holan · March 22, 2011, 1:54pm

Send the output of !analyze -v. god knows where it is blowing up without that. You are setting a completion routine, but always completing the request with failure. Did you mean to send the request down the stack instead?

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@razerzone.com
Sent: Tuesday, March 22, 2011 10:45 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] USB or HID lower level filter drivers