Patch DRIVER_OBJECT.MajorFunction[XXX]

I try to patch external DRIVER_OBJECT structure by replacing
MajorFunction handlers addresses. I use this code:

KeRaiseIrql(HIGH_LEVEL, &OldIrql);

InterceptFunction(IRP_MJ_CREATE, DriverObject, &HookedDevices[
HookedDevicesCount ].fnCreate, HookRoutine);
InterceptFunction(IRP_MJ_PNP, DriverObject, &HookedDevices[
HookedDevicesCount ].fnPnP, HookRoutine);
InterceptFunction(IRP_MJ_POWER, DriverObject, &HookedDevices[
HookedDevicesCount ].fnPower, HookRoutine);
InterceptFunction(IRP_MJ_READ, DriverObject, &HookedDevices[
HookedDevicesCount ].fnRead, HookRoutine);
InterceptFunction(IRP_MJ_WRITE, DriverObject, &HookedDevices[
HookedDevicesCount ].fnWrite, HookRoutine);
InterceptFunction(IRP_MJ_FLUSH_BUFFERS, DriverObject,
&HookedDevices[HookedDevicesCount].fnFlushBuffers, HookRoutine);
InterceptFunction(IRP_MJ_QUERY_INFORMATION, DriverObject,
&HookedDevices[HookedDevicesCount].fnQueryInformation, HookRoutine);
InterceptFunction(IRP_MJ_SET_INFORMATION, DriverObject,
&HookedDevices[HookedDevicesCount].fnSetInformation, HookRoutine);
InterceptFunction(IRP_MJ_DEVICE_CONTROL, DriverObject,
&HookedDevices[HookedDevicesCount].fnDeviceControl, HookRoutine);
InterceptFunction(IRP_MJ_INTERNAL_DEVICE_CONTROL, DriverObject,
&HookedDevices[HookedDevicesCount].fnInternalDeviceControl, HookRoutine);
InterceptFunction(IRP_MJ_SYSTEM_CONTROL, DriverObject,
&HookedDevices[HookedDevicesCount].fnSystemControl, HookRoutine);
InterceptFunction(IRP_MJ_CLEANUP, DriverObject, &HookedDevices[
HookedDevicesCount ].fnCleanup, HookRoutine);
InterceptFunction(IRP_MJ_CLOSE, DriverObject, &HookedDevices[
HookedDevicesCount ].fnClose, HookRoutine);
InterceptFunction(IRP_MJ_SHUTDOWN, DriverObject, &HookedDevices[
HookedDevicesCount ].fnShutdown, HookRoutine);

HookedDevices[HookedDevicesCount].FastIoDispatch =
DriverObject->FastIoDispatch;
if (DriverObject->FastIoDispatch)
DriverObject->FastIoDispatch = HookedFastIo;

HookedDevices[HookedDevicesCount].DriverObject = DriverObject;
HookedDevicesCount++;

KeLowerIrql(OldIrql);

where InterceptFunction is:

VOID
InterceptFunction(
UCHAR MajorFunction,
PDRIVER_OBJECT DriverObject,
PDRIVER_DISPATCH* pfnOldDispatch,
PDRIVER_DISPATCH fnNewDispatch)
{
PDRIVER_DISPATCH* fnTarget;

fnTarget = &(DriverObject->MajorFunction[MajorFunction]);

//hook only if handler exists
if (*fnTarget)
{
if (pfnOldDispatch)
*pfnOldDispatch = *fnTarget;
if (fnNewDispatch)
*fnTarget = fnNewDispatch;
}

For simplicity I realize HookRoutine as:

DbgPrint((“HookRoutine\n”));

Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = STATUS_SUCCESS;

IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;

}

Using this code I hooked DRIVER_OBJECT controlling USB mouse. After
moving mouse system hangs for some time (from 10 seconds to several
minutes). Only after this time delay I can watch a lof of log records in
DbgView. If I restore back original MajorFunction handlers there is no
any time delays.
Why do time delays take place? What should I do to correct this bug?

Dmitriy A. Boiko wrote:

I try to patch external DRIVER_OBJECT structure by replacing
MajorFunction handlers addresses. I use this code:

For simplicity I realize HookRoutine as:

DbgPrint((“HookRoutine\n”));

Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = STATUS_SUCCESS;

IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;
}

Using this code I hooked DRIVER_OBJECT controlling USB mouse. After
moving mouse system hangs for some time (from 10 seconds to several
minutes). Only after this time delay I can watch a lof of log records
in DbgView. If I restore back original MajorFunction handlers there is
no any time delays.
Why do time delays take place? What should I do to correct this bug?

I’m not sure why this surprises you. What were you expecting this code
to do? What you have done here is completely disable whatever device
you have “hooked”. Every request sent to this driver will return
nothing at all, include all requests to read data. What if there was
another driver trying to read data from this device? It’s going to see
that no bytes were returned, and in all likelihood will retry the
request until it gets some data.

Which device did you “hook”?


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

I hooked “/Device/USBPDO-3” device. I’m surprised by time delay. Why
are log records shown in DbgView only after several minutes? Why is system
hanging during this time? The problem is not that no bytes returned. If
original handler is called in HookRoutine the problem still occurs.

Subject: Re: Patch DRIVER_OBJECT.MajorFunction[XXX]
From: Tim Roberts
> Date: Mon, 12 Dec 2005 14:21:11 -0800
> X-Message-Number: 26
> I’m not sure why this surprises you. What were you expecting this code
> to do? What you have done here is completely disable whatever device
> you have “hooked”. Every request sent to this driver will return
> nothing at all, include all requests to read data. What if there was
> another driver trying to read data from this device? It’s going to see
> that no bytes were returned, and in all likelihood will retry the
> request until it gets some data.
>
> Which device did you “hook”?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .

You cannot hook a device. You can only hook a driver since the table is
in the driver object, not the devobj. This means that you are hooking
every USB hub PDO and FDO, essentially screwing up all of usb

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@ulstu.ru
Sent: Monday, December 12, 2005 9:43 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Patch DRIVER_OBJECT.MajorFunction[XXX]

I hooked “/Device/USBPDO-3” device. I’m surprised by time delay. Why
are log records shown in DbgView only after several minutes? Why is
system
hanging during this time? The problem is not that no bytes returned. If
original handler is called in HookRoutine the problem still occurs.

Subject: Re: Patch DRIVER_OBJECT.MajorFunction[XXX]
From: Tim Roberts
> Date: Mon, 12 Dec 2005 14:21:11 -0800
> X-Message-Number: 26
> I’m not sure why this surprises you. What were you expecting this
code
> to do? What you have done here is completely disable whatever device
> you have “hooked”. Every request sent to this driver will return
> nothing at all, include all requests to read data. What if there was
> another driver trying to read data from this device? It’s going to
see
> that no bytes were returned, and in all likelihood will retry the
> request until it gets some data.
>
> Which device did you “hook”?
>
> –
> Tim Roberts, xxxxx@probo.com
> Providenza & Boekelheide, Inc.

--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .


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

You are currently subscribed to ntdev as: unknown lmsubst tag argument:
‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com

I understand it. Of course, I hook all device objects, belonging to the
given driver objects. But that is not my question. I hooked
“/Driver/usbhub”. Why is there this time delay: (USB Mouse Moving) - (time
delay in several minutes) - (showing of log records in DbgView) ?

HookRoutine is:

DbgPrint((“HookRoutine\n”));

Irp->IoStatus.Information = 0;
Irp->IoStatus.Status = STATUS_SUCCESS;

IoCompleteRequest(Irp, IO_NO_INCREMENT);
return STATUS_SUCCESS;

Of course mouse cursor will not move. But DbgPrint!!!

Original Message:

You cannot hook a device. You can only hook a driver since the table is
in the driver object, not the devobj. This means that you are hooking
every USB hub PDO and FDO, essentially screwing up all of usb


mail2web - Check your email from the web at
http://mail2web.com/ .

xxxxx@ulstu.ru wrote:

I understand it. Of course, I hook all device objects, belonging to the
given driver objects. But that is not my question. I hooked
“/Driver/usbhub”. Why is there this time delay: (USB Mouse Moving) - (time
delay in several minutes) - (showing of log records in DbgView) ?

I told you this already. Other drivers are making requests of this
driver, and retrying until they get a response from their own devices.
With your hook installed, they will NEVER GET A RESPONSE. DbgView is a
puny user-mode app; it is always going to be a second-class CPU consumer
compared to kernel drivers. Once it finally gets a shot at the CPU,
DbgView will dump all of the accumulated records.

It’s possible that, had you been using the kernel debugger, you would
have seen the messages closer to real-time.


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

The reliability of such a thing is never guaranteed. For instance, it can
merrily crash on SMP/HT machine.

Hooking is evil.

If you want to filter the USB mouse - use the code based on MOUFILTR
sample.

Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com

----- Original Message -----
From: “Dmitriy A. Boiko”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 12, 2005 9:43 PM
Subject: [ntdev] Patch DRIVER_OBJECT.MajorFunction[XXX]

> I try to patch external DRIVER_OBJECT structure by replacing
> MajorFunction handlers addresses. I use this code:
>
> KeRaiseIrql(HIGH_LEVEL, &OldIrql);
>
> InterceptFunction(IRP_MJ_CREATE, DriverObject, &HookedDevices[
> HookedDevicesCount].fnCreate, HookRoutine);
> InterceptFunction(IRP_MJ_PNP, DriverObject, &HookedDevices[
> HookedDevicesCount].fnPnP, HookRoutine);
> InterceptFunction(IRP_MJ_POWER, DriverObject, &HookedDevices[
> HookedDevicesCount].fnPower, HookRoutine);
> InterceptFunction(IRP_MJ_READ, DriverObject, &HookedDevices[
> HookedDevicesCount].fnRead, HookRoutine);
> InterceptFunction(IRP_MJ_WRITE, DriverObject, &HookedDevices[
> HookedDevicesCount].fnWrite, HookRoutine);
> InterceptFunction(IRP_MJ_FLUSH_BUFFERS, DriverObject,
> &HookedDevices[HookedDevicesCount].fnFlushBuffers, HookRoutine);
> InterceptFunction(IRP_MJ_QUERY_INFORMATION, DriverObject,
> &HookedDevices[HookedDevicesCount].fnQueryInformation, HookRoutine);
> InterceptFunction(IRP_MJ_SET_INFORMATION, DriverObject,
> &HookedDevices[HookedDevicesCount].fnSetInformation, HookRoutine);
> InterceptFunction(IRP_MJ_DEVICE_CONTROL, DriverObject,
> &HookedDevices[HookedDevicesCount].fnDeviceControl, HookRoutine);
> InterceptFunction(IRP_MJ_INTERNAL_DEVICE_CONTROL, DriverObject,
> &HookedDevices[HookedDevicesCount].fnInternalDeviceControl, HookRoutine);
> InterceptFunction(IRP_MJ_SYSTEM_CONTROL, DriverObject,
> &HookedDevices[HookedDevicesCount].fnSystemControl, HookRoutine);
> InterceptFunction(IRP_MJ_CLEANUP, DriverObject, &HookedDevices[
> HookedDevicesCount].fnCleanup, HookRoutine);
> InterceptFunction(IRP_MJ_CLOSE, DriverObject, &HookedDevices[
> HookedDevicesCount].fnClose, HookRoutine);
> InterceptFunction(IRP_MJ_SHUTDOWN, DriverObject, &HookedDevices[
> HookedDevicesCount].fnShutdown, HookRoutine);
>
> HookedDevices[HookedDevicesCount].FastIoDispatch =
> DriverObject->FastIoDispatch;
> if (DriverObject->FastIoDispatch)
> DriverObject->FastIoDispatch = HookedFastIo;
>
> HookedDevices[HookedDevicesCount].DriverObject = DriverObject;
> HookedDevicesCount++;
>
>
> KeLowerIrql(OldIrql);
>
>
>
> where InterceptFunction is:
>
>
> VOID
> InterceptFunction(
> UCHAR MajorFunction,
> PDRIVER_OBJECT DriverObject,
> PDRIVER_DISPATCH* pfnOldDispatch,
> PDRIVER_DISPATCH fnNewDispatch)
> {
> PDRIVER_DISPATCH* fnTarget;
>
> fnTarget = &(DriverObject->MajorFunction[MajorFunction]);
>
> //hook only if handler exists
> if (*fnTarget)
> {
> if (pfnOldDispatch)
> *pfnOldDispatch = *fnTarget;
> if (fnNewDispatch)
> *fnTarget = fnNewDispatch;
> }
>
> For simplicity I realize HookRoutine as:
>
>
> DbgPrint((“HookRoutine\n”));
>
> Irp->IoStatus.Information = 0;
> Irp->IoStatus.Status = STATUS_SUCCESS;
>
> IoCompleteRequest(Irp, IO_NO_INCREMENT);
> return STATUS_SUCCESS;
>
>
> }
>
>
> Using this code I hooked DRIVER_OBJECT controlling USB mouse. After
> moving mouse system hangs for some time (from 10 seconds to several
> minutes). Only after this time delay I can watch a lof of log records in
> DbgView. If I restore back original MajorFunction handlers there is no
> any time delays.
> Why do time delays take place? What should I do to correct this bug?
>
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com