Intercepting IOCTLs

Hi all,

If I want to intercept an IOCTL call for a lower lever driver and
modify the data returned, after the IOCTL has been processed by the
lower level driver, then would writing a completion routine for
IRP_MJ_DEVICE_CONTROL do?

As far as my knowledge goes, and I am a novice, IOCTL handling is done
in a provate way inside drivers. Thus if the driver below me is
handling it, can I modify the data again and pass it on to the driver
above mine?

For example, lets take a disk sector level encryptor, if the entire
disc is encrypted, right from the boot sector to the last, then the
IOCTL to get the volume information will return garbage values to the
driver disk.sys. So if I want to correct this problem, and intercept
the IOCTL after disk.sys has populated it’s structures incorrectly, is
that possible???

What is the solution to this problem.

Thanks,

  • Developer

> As far as my knowledge goes, and I am a novice, IOCTL handling is done

in a provate way inside drivers. Thus if the driver below me is
handling it, can I modify the data again and pass it on to the driver
above mine?

A completion routine can do this.

Make sure you have read Mr. Oney Wdm 2nd edtion book Chapter ?? - 8 Irp
handling scenarios
and:

http://support.microsoft.com/default.aspx?scid=kb;EN-US;320275

http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q326315

Calvin Guan (Windows DDK MVP)
Staff SW Engineer NetXtreme MINIPORT
Broadcom Corp. Irvine, CA
www.broadcom.com

Well, I have read it calvin, however, I have a doubt. Does the driver
have a different method of fetching the data from the disk (may be the
boot sector) when it gets an IOCTL request. Won’t disk.sys also
ultimately generate an IRP_MJ_READ to fetch the data?

The lower I place the driver in the stack, the lesser number of
different IRPs I need to handle, isn’t that true?

On 8/3/05, Calvin Guan wrote:
> > As far as my knowledge goes, and I am a novice, IOCTL handling is done
> > in a provate way inside drivers. Thus if the driver below me is
> > handling it, can I modify the data again and pass it on to the driver
> > above mine?
>
> A completion routine can do this.
>
> Make sure you have read Mr. Oney Wdm 2nd edtion book Chapter ?? - 8 Irp
> handling scenarios
> and:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;320275
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q326315
>
> Calvin Guan (Windows DDK MVP)
> Staff SW Engineer NetXtreme MINIPORT
> Broadcom Corp. Irvine, CA
> www.broadcom.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer

Yes - a completion routine on an IRP is the appropriate place for your
driver to modify the result returned by a lower-level driver.

However the sector-level encryption example you state is not that
simple.

The disk driver doesn’t just slap the “volume information” into a data
structure - it also interprets it to see the partition tables, etc…
So in that case you would actually want to be filtering *below* the disk
driver so that it wasn’t aware of the encryption either.

Yes completion routine is the right way to go. But you may still need
to think about where in the stack your driver should live.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, August 03, 2005 1:57 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Intercepting IOCTLs

Hi all,

If I want to intercept an IOCTL call for a lower lever driver and
modify the data returned, after the IOCTL has been processed by the
lower level driver, then would writing a completion routine for
IRP_MJ_DEVICE_CONTROL do?

As far as my knowledge goes, and I am a novice, IOCTL handling is done
in a provate way inside drivers. Thus if the driver below me is
handling it, can I modify the data again and pass it on to the driver
above mine?

For example, lets take a disk sector level encryptor, if the entire
disc is encrypted, right from the boot sector to the last, then the
IOCTL to get the volume information will return garbage values to the
driver disk.sys. So if I want to correct this problem, and intercept
the IOCTL after disk.sys has populated it’s structures incorrectly, is
that possible???

What is the solution to this problem.

Thanks,

  • Developer

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

Where you are in the stack changes which I/O request types you need to
handle. However it doesn’t necessarily make it smaller.

I imagine you thinking that if your filter is low enough in the stack
you can write one I/O dispatch routine and one I/O completion routine
and just apply your decryption algorithm to each buffer. That won’t
work. At any layer in the stack you need to understand what requests
can come down and which should get encryption/decryption.

Filtering above the disk driver you could decrypt reads and encrypt
writes, and still need to handle some I/O controls individually.

Filtering below the disk driver you’ll never see an IRP_MJ_READ or
IRP_MJ_WRITE - you’ll see i/o controls and IRP_MJ_SCSI requests and
you’ll need to know for each of those whether the control returns data
from the media (like SCSIOP_READ) and needs decryption, or whether the
data comes from the drive firmware (like SCSIOP_READ_CAPACITY) and
should come back untouched.

-p

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Developer
Sent: Wednesday, August 03, 2005 2:25 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Intercepting IOCTLs

Well, I have read it calvin, however, I have a doubt. Does the driver
have a different method of fetching the data from the disk (may be the
boot sector) when it gets an IOCTL request. Won’t disk.sys also
ultimately generate an IRP_MJ_READ to fetch the data?

The lower I place the driver in the stack, the lesser number of
different IRPs I need to handle, isn’t that true?

On 8/3/05, Calvin Guan wrote:
> > As far as my knowledge goes, and I am a novice, IOCTL handling is
done
> > in a provate way inside drivers. Thus if the driver below me is
> > handling it, can I modify the data again and pass it on to the
driver
> > above mine?
>
> A completion routine can do this.
>
> Make sure you have read Mr. Oney Wdm 2nd edtion book Chapter ?? - 8
Irp
> handling scenarios
> and:
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;320275
>
> http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q326315
>
> Calvin Guan (Windows DDK MVP)
> Staff SW Engineer NetXtreme MINIPORT
> Broadcom Corp. Irvine, CA
> www.broadcom.com
>
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@gmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>



- Developer


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

thanks a ton calvin and peter,

your advice is of great help. Well yes I am trying to code a sector
level disc encryptor, true. Hence the example.

So you think, a better place to palce my driver would be below disk.sys ?

Can you tell me, how I can get my driver loade before disk.sys, which
all registry keys to modify, what makes Windows assume the it should
load mydriver.sys below disk.sys

Considering the complications in the development of a driver below
disk.sys, can you tell me the drivers in the stack below disk.sys. Is
it atapi.sys? I have no idea. Deveice tree doesnt show that properly,
in device tree apati.sys is a diff node and disk.sys is a diff node,
though they both connect to the same device, can you throw some light
on that.

One more thing I want to ask is, that hibernation and crash dumps
follow a different stack, they are directly handled by the driver
diskdump.sys, which is never shown in device tree, *forcing* me to
believe that the driver is an *on demand* loadable one. But, is it
true that even diskdump.sys sends it’s requests to the disk through
apati.sys or what ever driver lies below disk.sys?

Your advice would be of great help to me.

Thanks in advance,

-Developer

On 8/3/05, Peter Wieland wrote:
> Where you are in the stack changes which I/O request types you need to
> handle. However it doesn’t necessarily make it smaller.
>
> I imagine you thinking that if your filter is low enough in the stack
> you can write one I/O dispatch routine and one I/O completion routine
> and just apply your decryption algorithm to each buffer. That won’t
> work. At any layer in the stack you need to understand what requests
> can come down and which should get encryption/decryption.
>
> Filtering above the disk driver you could decrypt reads and encrypt
> writes, and still need to handle some I/O controls individually.
>
> Filtering below the disk driver you’ll never see an IRP_MJ_READ or
> IRP_MJ_WRITE - you’ll see i/o controls and IRP_MJ_SCSI requests and
> you’ll need to know for each of those whether the control returns data
> from the media (like SCSIOP_READ) and needs decryption, or whether the
> data comes from the drive firmware (like SCSIOP_READ_CAPACITY) and
> should come back untouched.
>
> -p
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Developer
> Sent: Wednesday, August 03, 2005 2:25 AM
> To: Windows System Software Devs Interest List
> Subject: Re: [ntdev] Intercepting IOCTLs
>
> Well, I have read it calvin, however, I have a doubt. Does the driver
> have a different method of fetching the data from the disk (may be the
> boot sector) when it gets an IOCTL request. Won’t disk.sys also
> ultimately generate an IRP_MJ_READ to fetch the data?
>
> The lower I place the driver in the stack, the lesser number of
> different IRPs I need to handle, isn’t that true?
>
>
>
> On 8/3/05, Calvin Guan wrote:
> > > As far as my knowledge goes, and I am a novice, IOCTL handling is
> done
> > > in a provate way inside drivers. Thus if the driver below me is
> > > handling it, can I modify the data again and pass it on to the
> driver
> > > above mine?
> >
> > A completion routine can do this.
> >
> > Make sure you have read Mr. Oney Wdm 2nd edtion book Chapter ?? - 8
> Irp
> > handling scenarios
> > and:
> >
> > http://support.microsoft.com/default.aspx?scid=kb;EN-US;320275
> >
> > http://support.microsoft.com/default.aspx?scid=kb;EN-US;Q326315
> >
> > Calvin Guan (Windows DDK MVP)
> > Staff SW Engineer NetXtreme MINIPORT
> > Broadcom Corp. Irvine, CA
> > www.broadcom.com
> >
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as: xxxxx@gmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
>
> –
>
> - Developer
>
> —
> 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
>
> —
> 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
>



- Developer