Re: Writing USB packet monitoring tool using WDF framework

embedinfo <> wrote:
>
>I am new to PC driver development. I would like to write USB packet
>monitoring tool. Based on my reading I have decided to write USB upper
>filter class driver.

Upper filter to which class?

>As a first step I added few DbgPrint messages all over the filter
>function and registered filter as Upper filter class to USB stack.

Do you mean USB class, {36FC9E60-...}? Remember, that class includes host
controllers, hubs, composite devices, and many other devices. Anything
that appears in Device Manager under "Universal Serial Bus controllers".
You're going to be intercepting ALL communications heading into ANY of
those devices.

>But after rebooting machine I just see following IOCTL being called:
>
>"IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME" and some invalid IOCTL with
>hex code ("0x220408")

It's not invalid:
00220408 = IOCTL_USB_GET_NODE_INFORMATION
00220408 = IOCTL_USB_GET_ROOT_HUB_NAME

>I was expecting "IOCTL_INTERNAL_USB_SUBMIT_URB" call which is not
>called at all.

It sounds like you may have intercepted IRP_MJ_DEVICE_CONTROL instead of
IRP_MJ_INTERNAL_DEVICE_CONTROL. Is that possible?

>Can any one tell me if this is the right way to write USB packet
>monitoring tool?

It's one way to do it. Are you aware there are already quite a number of
tools that do this, including some that are free?
--
Tim Roberts,
Providenza & Boekelheide, Inc.

embedinfo <> wrote:
>>
>> It's not invalid:
>> * 00220408 = IOCTL_USB_GET_NODE_INFORMATION
>> * 00220408 = IOCTL_USB_GET_ROOT_HUB_NAME
>
>Actually I checked these IOCTL hex code in OSR online, and I could not
>find any explanation about these. Where can I find explanation about
>these IOCTLs?

Google will point you to the MSDN pages. Mostly, these are for internal
communication between the hubs and host controller and should not be of
interest.


>> It sounds like you may have intercepted IRP_MJ_DEVICE_CONTROL instead of
>> IRP_MJ_INTERNAL_DEVICE_CONTROL. *Is that possible?
>>
>Even I am not sure about this. I am planning to connect WinDbg and
>track the caller.

??? YOU wrote the filter driver, right? Only YOU know which requests you
asked to intercept. You need WdfRequestTypeDeviceControlInternal, not
WdfRequestTypeDeviceControl.
--
Tim Roberts,
Providenza & Boekelheide, Inc.

> Yes. I used couple of them and this activity I have chosen this
> activity myself to get a feel of Windows Driver programming. Any help
> would be greatly appreciated.

choose something else. this is going to be a very complicated project and
not work the way you think it does. the usb stack has a few short cuts in
terms of URB processing and filters do not see the URB traffic for the most
part.

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"embedinfo" <> wrote in message
news:1f961133-fcca-42d2-8f7b-...
> Hi Robert,
>
> Thanks for quick response. Please find answers to the questions with
> some more queries inline:
>
> On Nov 14, 9:50 am, Tim Roberts <t...@probo.com> wrote:
>> embedinfo <embedi...@gmail.com> wrote:
>>
>> >I am new to PC driver development. I would like to write USB packet
>> >monitoring tool. Based on my reading I have decided to write USB upper
>> >filter class driver.
>>
>> Upper filter to which class? {36FC9E60...
>
> I am writing upper filter to USB class.
>>
>> >As a first step I added few DbgPrint messages all over the filter
>> >function and registered filter as Upper filter class to USB stack.
>>
>> Do you mean USB class, {36FC9E60-...}? Remember, that class includes
>> host
>> controllers, hubs, composite devices, and many other devices. Anything
>> that appears in Device Manager under "Universal Serial Bus controllers".
>> You're going to be intercepting ALL communications heading into ANY of
>> those devices.
>
> Is this the right appraoch? Please suggest any better way!
>>
>> >But after rebooting machine I just see following IOCTL being called:
>>
>> >"IOCTL_INTERNAL_USB_GET_CONTROLLER_NAME" and some invalid IOCTL with
>> >hex code ("0x220408")
>>
>> It's not invalid:
>> 00220408 = IOCTL_USB_GET_NODE_INFORMATION
>> 00220408 = IOCTL_USB_GET_ROOT_HUB_NAME
>
> Actually I checked these IOCTL hex code in OSR online, and I could not
> find any explanation about these. Where can I find explanation about
> these IOCTLs?
>>
>> >I was expecting "IOCTL_INTERNAL_USB_SUBMIT_URB" call which is not
>> >called at all.
>>
>> It sounds like you may have intercepted IRP_MJ_DEVICE_CONTROL instead of
>> IRP_MJ_INTERNAL_DEVICE_CONTROL. Is that possible?
>>
> Even I am not sure about this. I am planning to connect WinDbg and
> track the caller.
>
>> >Can any one tell me if this is the right way to write USB packet
>> >monitoring tool?
>>
>> It's one way to do it. Are you aware there are already quite a number of
>> tools that do this, including some that are free?
>
> Yes. I used couple of them and this activity I have chosen this
> activity myself to get a feel of Windows Driver programming. Any help
> would be greatly appreciated.
>> --
>> Tim Roberts, t...@probo.com
>> Providenza & Boekelheide, Inc.
>

the latter. it is complicated no matter what framework you use.
commercially available usb sniffers play some dirty tricks and use
undocumented features. they are not products that were released overnight
either, they took years to develop and run properly. as a learning exercise
I would pick something simpler

d

--

This posting is provided "AS IS" with no warranties, and confers no rights.


"embedinfo" <> wrote in message
news:57a0eb11-5e74-4dc9-8812-...
> On Nov 17, 2:24 am, "Doron Holan [MSFT]"
> <doron.ho...@online.microsoft.com> wrote:
>> > Yes. I used couple of them and this activity I have chosen this
>> > activity myself to get a feel of Windows Driver programming. Any help
>> > would be greatly appreciated.
>>
>> choose something else.
>
> Can you suggest better way to do this? Does it mean that this task
> will be complecated using WDF frame work? or even with WDM model? or
> is it complecated for begginer like me?
>
> Then what technique is used in commercially available USB sniffers do
> use? Any inputs will be helpful.
>
> Thanks
>
>
> this is going to be a very complicated project and
>> not work the way you think it does. the usb stack has a few short cuts
>> in
>> terms of URB processing and filters do not see the URB traffic for the
>> most
>> part.
>>
>> d
>>
>>