Looking in USBSnoop and Question.

SAM_Yoon · March 22, 2007, 4:57pm

Hello Gentlemen and ladies,

I am looking into USBSnoop source code and have some questions. I put some snippet of his code as you can see below.

Question is that why is it stealing the IRP_MJ_INTERNAL_DEVICE_CONTROL under this filter driver? Are there more reason than showing the real going down/up data?

Thank you.

<driver.h>
typedef struct _USBSNOOP_GLOBALS
{
// If we successfully attach to the lobby (USBSnpys), we get some
// function pointers that we can call there…
SNOOPIES_FUNCTIONS Snoopies;

// If this is set to something other than 0, we will steal entrypoints
// and hopefully be able to snoop ‘filterly-challenged’ drivers…
ULONG lStealEntrypoints;

// This will point to the patched driver object function pointer table
PDRIVER_OBJECT PatchedTable;

} USBSNOOP_GLOBALS, *PUSBSNOOP_GLOBALS;

<driver.cpp>
struct USBSNOOP_GLOBALS GlobalData;

DriverEntry()
{
…

if(!GlobalData.lStealEntrypoints)
{
DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnp;
DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = DispatchInternalIOCTL;
}

return STATUS_SUCCESS;
}

AddDevice()
{
…

if(GlobalData.lStealEntrypoints)
{
// make a copy of fdo->DriverObject
if(NULL == GlobalData.PatchedTable)
{
GlobalData.PatchedTable = (PDRIVER_OBJECT) ExAllocatePool(PagedPool, sizeof(DRIVER_OBJECT));
if(NULL != GlobalData.PatchedTable)
{
*GlobalData.PatchedTable = *fdo->DriverObject;

// we make some changes to this copy
GlobalData.PatchedTable->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = DispatchInternalIOCTL;
GlobalData.PatchedTable->MajorFunction[IRP_MJ_PNP] = DispatchPnp;

pdx->OriginalDriverObject = fdo->DriverObject;
fdo->DriverObject = GlobalData.PatchedTable;
}
}
}
}
…

return status;
}</driver.cpp></driver.h>

Tim_Roberts · March 22, 2007, 5:10pm

xxxxx@hotmail.com wrote:

Hello Gentlemen and ladies,

I am looking into USBSnoop source code and have some questions. I put some snippet of his code as you can see below.

Question is that why is it stealing the IRP_MJ_INTERNAL_DEVICE_CONTROL under this filter driver? Are there more reason than showing the real going down/up data?

*All* URBs are submitted as IRP_MJ_INTERNAL_DEVICE_CONTROL requests to
the USB host controller. If you are going to snoop on USB requests,
then you monitor IRP_MJ_INTERNAL_DEVICE_CONTROL. In fact, that’s the
ONLY thing you have to monitor.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

Thomas_Divine-2 · March 22, 2007, 5:12pm

> -----Original Message-----

From: xxxxx@lists.osr.com [mailto:bounce-281423-
xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, March 22, 2007 4:57 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Looking in USBSnoop and Question.

Hello Gentlemen and ladies,

I am looking into USBSnoop source code and have some questions. I put
some snippet of his code as you can see below.

Question is that why is it stealing the IRP_MJ_INTERNAL_DEVICE_CONTROL
under this filter driver? Are there more reason than showing the real
going down/up data?
[PCAUSA] The information that needs to be observed is passed amongst drivers
using IRP_MJ_INTERNAL_DEVICE_CONTROL. So, to see the information it is
necessary to filter that path.

A version of USBSnoop that can be built using the WDK 6000 and Visual Studio
2005 is available at:

https://www.pcausa.com/Utilities/UsbSnoop/default.htm

It does not offer bug fixes or improvements to the original. It simply can
be built and debugged with current tools.

Good luck,

Thomas F. Divine

Thank you.

<driver.h>
> typedef struct _USBSNOOP_GLOBALS
> {
> // If we successfully attach to the lobby (USBSnpys), we get some
> // function pointers that we can call there…
> SNOOPIES_FUNCTIONS Snoopies;
>
> // If this is set to something other than 0, we will steal entrypoints
> // and hopefully be able to snoop ‘filterly-challenged’ drivers…
> ULONG lStealEntrypoints;
>
> // This will point to the patched driver object function pointer table
> PDRIVER_OBJECT PatchedTable;
>
> } USBSNOOP_GLOBALS, *PUSBSNOOP_GLOBALS;
>
> <driver.cpp>
> struct USBSNOOP_GLOBALS GlobalData;
>
> DriverEntry()
> {
> …
>
> if(!GlobalData.lStealEntrypoints)
> {
> DriverObject->MajorFunction[IRP_MJ_PNP] = DispatchPnp;
> DriverObject->MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] =
> DispatchInternalIOCTL;
> }
>
> return STATUS_SUCCESS;
> }
>
>
> AddDevice()
> {
> …
>
> if(GlobalData.lStealEntrypoints)
> {
> // make a copy of fdo->DriverObject
> if(NULL == GlobalData.PatchedTable)
> {
> GlobalData.PatchedTable = (PDRIVER_OBJECT)
> ExAllocatePool(PagedPool, sizeof(DRIVER_OBJECT));
> if(NULL != GlobalData.PatchedTable)
> {
> *GlobalData.PatchedTable = *fdo->DriverObject;
>
> // we make some changes to this copy
> GlobalData.PatchedTable-
> >MajorFunction[IRP_MJ_INTERNAL_DEVICE_CONTROL] = DispatchInternalIOCTL;
> GlobalData.PatchedTable->MajorFunction[IRP_MJ_PNP]
> = DispatchPnp;
>
> pdx->OriginalDriverObject = fdo->DriverObject;
> fdo->DriverObject = GlobalData.PatchedTable;
> }
> }
> }
> }
> …
>
> return status;
> }
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer</driver.cpp></driver.h>

SAM_Yoon · March 22, 2007, 5:49pm

OK. I see that. Thank you so much gentlmen, Thomas and Tim.

So the reason was to keep track of IRP_MJ_INTERNAL_DEVICE_CONTROL from the device to returning staus from HUB. Is it right?

Thank you again.

Tim_Roberts · March 22, 2007, 6:08pm

xxxxx@hotmail.com wrote:

OK. I see that. Thank you so much gentlmen, Thomas and Tim.

So the reason was to keep track of IRP_MJ_INTERNAL_DEVICE_CONTROL from the device to returning staus from HUB. Is it right?

Basically. The purpose of USBSnoop is to track all of the USB requests
going to the host controller. The way you do that is by watching
IRP_MJ_INTERNAL_DEVICE_CONTROL requests going down and coming back.

–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

OSR_Community_User · March 22, 2007, 6:09pm

Well, not exactly. It’s not “status”. It’s nearly everything.

IRP_MJ_INTERNAL_DEVICE_CONTROL is one of the most common ways for drivers in the same device stack to communicate. The general pattern for USB function drivers (such as a driver for a USB camera, keyboard, CNC mill, whatever) is that they communicate with the physical USB device by formatting IRP_MJ_INTERNAL_DEVICE_CONTROL requests (that refer to URB structures) and then sending them down the device stack. Provided no filters interfere with the request, the request will generally reach the MS USB stack, which processes the request.

These URB requests are how the function driver and the port driver interact. So it’s not “status”, it’s more like “that’s the USB API”.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, March 22, 2007 5:49 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Looking in USBSnoop and Question.

OK. I see that. Thank you so much gentlmen, Thomas and Tim.

So the reason was to keep track of IRP_MJ_INTERNAL_DEVICE_CONTROL from the device to returning staus from HUB. Is it right?

Thank you again.

Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

Doron_Holan · March 22, 2007, 7:17pm

I think in this case, usbsnoop is trying to work around drivers which send I/O directly to the PDO instead of the attached device (which would be the usbsnoop filter, thus bypassing the snooping) by hooking a dispatch table of some other driver.

d