Intercept raw disk access

Christian_Ondracek · January 14, 2014, 9:31am

We got a working filter driver (not a minifilter driver), already developed some years ago and handle IRP_MJ_CREATE as well as IRP_MJ_CLEANUP our own. IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE is hooked as well but currently not used as our needs are handled fine in CREATE and CLEANUP.

What we are looking for at the moment is getting informed when someone tries to open a physical device directly like with

HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
0,
FILE_SHARE_READ |
FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
0);

or in general reads/writes disk sectors directly.

What I tried so far was using the FileObject obtained from the currentIrpStack IN MJ_IRP_CREATE callback and looking over its members for something usefull.
Unfortunately I was only able to get the name from the mounted device associated, by using the VPB->RealDevice giving me somthing like \Device\HarddiskVolume1 when querying with ObQueryNameString.
And the FileName contained in the UNICODE_STRING associated with the FileObject that gives me somethign like \Windows\system32\ f.e.:

NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION nextIrpStack)
{
PFILE_OBJECT fileObject = currentIrpStack->FileObject;
// …
}

Im still new to Windows File drivers but I thought IRP_MJ_CREATE should be send down also if someone opens a raw volume and also has a valid FileObject passed into containing the volumes path.

Interestingly when i openend \PhysicalDrive0 with my test program, our driver notified nothing about it, or at least the name of the FileName was empty.

So concerning my question:
Is there any change getting to know if PhysicalDrive0 was accessed direclty by examaning the FileObject in MJ_IRP_CREATE.

What would someone do in general to intercept raw disk access when being a filter driver (so not being at the bottom of the driver stack)?

Thanks for any suggestions.

amitr0-2 · January 14, 2014, 10:38am

the problem here, i believe is, that you are attaching to the FS, where as
the create Op is coming for the disk device, which is not part of the FS
stack. you will need to attach to volumes and disk to get this create.

On Tue, Jan 14, 2014 at 8:01 PM, wrote:

> We got a working filter driver (not a minifilter driver), already
> developed some years ago and handle IRP_MJ_CREATE as well as IRP_MJ_CLEANUP
> our own. IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE is hooked as well but
> currently not used as our needs are handled fine in CREATE and CLEANUP.
>
> What we are looking for at the moment is getting informed when someone
> tries to open a physical device directly like with
>
> HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
> 0,
> FILE_SHARE_READ |
> FILE_SHARE_WRITE,
> NULL,
> OPEN_EXISTING,
> 0,
> 0);
>
> or in general reads/writes disk sectors directly.
>
> What I tried so far was using the FileObject obtained from the
> currentIrpStack IN MJ_IRP_CREATE callback and looking over its members for
> something usefull.
> Unfortunately I was only able to get the name from the mounted device
> associated, by using the VPB->RealDevice giving me somthing like
> \Device\HarddiskVolume1 when querying with ObQueryNameString.
> And the FileName contained in the UNICODE_STRING associated with the
> FileObject that gives me somethign like \Windows\system32\ f.e.:
>
> NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP
> Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION nextIrpStack)
> {
> PFILE_OBJECT fileObject = currentIrpStack->FileObject;
> // …
> }
>
> Im still new to Windows File drivers but I thought IRP_MJ_CREATE should be
> send down also if someone opens a raw volume and also has a valid
> FileObject passed into containing the volumes path.
>
> Interestingly when i openend \PhysicalDrive0 with my test program, our
> driver notified nothing about it, or at least the name of the FileName was
> empty.
>
> So concerning my question:
> Is there any change getting to know if PhysicalDrive0 was accessed
> direclty by examaning the FileObject in MJ_IRP_CREATE.
>
> What would someone do in general to intercept raw disk access when being a
> filter driver (so not being at the bottom of the driver stack)?
>
> Thanks for any suggestions.
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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
>

–

- ab

Peter_Scott · January 14, 2014, 12:24pm

Actually you will see these opens as opens where the fileobject’s name
is NULL. When the name is NULL the open is targeted for the volume.

Pete

On 1/14/2014 8:38 AM, A B wrote:

the problem here, i believe is, that you are attaching to the FS,
where as the create Op is coming for the disk device, which is not
part of the FS stack. you will need to attach to volumes and disk to
get this create.

On Tue, Jan 14, 2014 at 8:01 PM, > mailto:xxxxx> wrote:
>
> We got a working filter driver (not a minifilter driver), already
> developed some years ago and handle IRP_MJ_CREATE as well as
> IRP_MJ_CLEANUP our own. IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE
> is hooked as well but currently not used as our needs are handled
> fine in CREATE and CLEANUP.
>
> What we are looking for at the moment is getting informed when
> someone tries to open a physical device directly like with
>
> HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
> 0,
> FILE_SHARE_READ |
> FILE_SHARE_WRITE,
> NULL,
> OPEN_EXISTING,
> 0,
> 0);
>
> or in general reads/writes disk sectors directly.
>
> What I tried so far was using the FileObject obtained from the
> currentIrpStack IN MJ_IRP_CREATE callback and looking over its
> members for something usefull.
> Unfortunately I was only able to get the name from the mounted
> device associated, by using the VPB->RealDevice giving me somthing
> like \Device\HarddiskVolume1 when querying with ObQueryNameString.
> And the FileName contained in the UNICODE_STRING associated with
> the FileObject that gives me somethign like \Windows\system32\ f.e.:
>
> NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP
> Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION
> nextIrpStack)
> {
> PFILE_OBJECT fileObject = currentIrpStack->FileObject;
> // …
> }
>
> Im still new to Windows File drivers but I thought IRP_MJ_CREATE
> should be send down also if someone opens a raw volume and also
> has a valid FileObject passed into containing the volumes path.
>
> Interestingly when i openend \PhysicalDrive0 with my test
> program, our driver notified nothing about it, or at least the
> name of the FileName was empty.
>
> So concerning my question:
> Is there any change getting to know if PhysicalDrive0 was accessed
> direclty by examaning the FileObject in MJ_IRP_CREATE.
>
> What would someone do in general to intercept raw disk access when
> being a filter driver (so not being at the bottom of the driver
> stack)?
>
> Thanks for any suggestions.
>
>
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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
>
>
>
>
> –
>
> - ab
> — NTFSD is sponsored by OSR OSR is hiring!! Info at
> http://www.osr.com/careers For our schedule of debugging and file
> system 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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295</mailto:xxxxx>

OSR_Community_User · January 14, 2014, 1:03pm

Yes, but volume is \.\C: or \?\Volume{guid}.

\.\PhysicalDrive%d is handled by disk.sys without the FSDs.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com
“Peter Scott” wrote in message news:xxxxx@ntfsd…

Actually you will see these opens as opens where the fileobject’s name is NULL. When the name is NULL the open is targeted for the volume.

Pete

On 1/14/2014 8:38 AM, A B wrote:

the problem here, i believe is, that you are attaching to the FS, where as the create Op is coming for the disk device, which is not part of the FS stack. you will need to attach to volumes and disk to get this create.

On Tue, Jan 14, 2014 at 8:01 PM, wrote:

We got a working filter driver (not a minifilter driver), already developed some years ago and handle IRP_MJ_CREATE as well as IRP_MJ_CLEANUP our own. IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE is hooked as well but currently not used as our needs are handled fine in CREATE and CLEANUP.

What we are looking for at the moment is getting informed when someone tries to open a physical device directly like with

HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
0,
FILE_SHARE_READ |
FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
0);

or in general reads/writes disk sectors directly.

What I tried so far was using the FileObject obtained from the currentIrpStack IN MJ_IRP_CREATE callback and looking over its members for something usefull.
Unfortunately I was only able to get the name from the mounted device associated, by using the VPB->RealDevice giving me somthing like \Device\HarddiskVolume1 when querying with ObQueryNameString.
And the FileName contained in the UNICODE_STRING associated with the FileObject that gives me somethign like \Windows\system32\ f.e.:

NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION nextIrpStack)
{
PFILE_OBJECT fileObject = currentIrpStack->FileObject;
// …
}

Im still new to Windows File drivers but I thought IRP_MJ_CREATE should be send down also if someone opens a raw volume and also has a valid FileObject passed into containing the volumes path.

Interestingly when i openend \PhysicalDrive0 with my test program, our driver notified nothing about it, or at least the name of the FileName was empty.

So concerning my question:
Is there any change getting to know if PhysicalDrive0 was accessed direclty by examaning the FileObject in MJ_IRP_CREATE.

What would someone do in general to intercept raw disk access when being a filter driver (so not being at the bottom of the driver stack)?

Thanks for any suggestions.

—
NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

–

- ab
— NTFSD is sponsored by OSR OSR is hiring!! Info at http://www.osr.com/careers For our schedule of debugging and file system 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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295

OSR_Community_User · January 14, 2014, 1:06pm

> Actually you will see these opens as opens where the fileobject’s name is NULL.

When the name is NULL the open is targeted for the volume.

If you are opening “??\C:”, then yes, you get FILE_OBJECT with an empty name going to NTFS.sys. If you are opening “\.\PhysicalDrive#”, then you get FILE_OBJECT with an empty name going to disk.sys, which is below file system stack.

Peter_Scott · January 14, 2014, 1:08pm

Sorry, you are correct. I missed that the OP had specified that naming
convention.

Pete

On 1/14/2014 11:02 AM, Maxim S. Shatskih wrote:

Yes, but volume is \.\C <file:>: or \?\Volume{guid
> <file:>}.
> \.\PhysicalDrive%d <file:> is handled by
> disk.sys without the FSDs.
>
> –
> Maxim S. Shatskih
> Microsoft MVP on File System And Storage
> xxxxx@storagecraft.com mailto:xxxxx
> http://www.storagecraft.com
>
> “Peter Scott” > mailto:xxxxx> wrote in message
> news:xxxxx@ntfsd…
>
> Actually you will see these opens as opens where the fileobject’s
> name is NULL. When the name is NULL the open is targeted for the
> volume.
>
> Pete
>
> On 1/14/2014 8:38 AM, A B wrote:
>> the problem here, i believe is, that you are attaching to the FS,
>> where as the create Op is coming for the disk device, which is
>> not part of the FS stack. you will need to attach to volumes and
>> disk to get this create.
>>
>>
>> On Tue, Jan 14, 2014 at 8:01 PM, >> mailto:xxxxx> wrote:
>>
>> We got a working filter driver (not a minifilter driver),
>> already developed some years ago and handle IRP_MJ_CREATE as
>> well as IRP_MJ_CLEANUP our own. IRP_MJ_WRITE, IRP_MJ_READ and
>> IRP_MJ_CLOSE is hooked as well but currently not used as our
>> needs are handled fine in CREATE and CLEANUP.
>>
>> What we are looking for at the moment is getting informed
>> when someone tries to open a physical device directly like with
>>
>> HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
>> 0,
>> FILE_SHARE_READ |
>> FILE_SHARE_WRITE,
>> NULL,
>> OPEN_EXISTING,
>> 0,
>> 0);
>>
>> or in general reads/writes disk sectors directly.
>>
>> What I tried so far was using the FileObject obtained from
>> the currentIrpStack IN MJ_IRP_CREATE callback and looking
>> over its members for something usefull.
>> Unfortunately I was only able to get the name from the
>> mounted device associated, by using the VPB->RealDevice
>> giving me somthing like \Device\HarddiskVolume1 when querying
>> with ObQueryNameString.
>> And the FileName contained in the UNICODE_STRING associated
>> with the FileObject that gives me somethign like
>> \Windows\system32\ f.e.:
>>
>> NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP
>> Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION
>> nextIrpStack)
>> {
>> PFILE_OBJECT fileObject = currentIrpStack->FileObject;
>> // …
>> }
>>
>> Im still new to Windows File drivers but I thought
>> IRP_MJ_CREATE should be send down also if someone opens a raw
>> volume and also has a valid FileObject passed into containing
>> the volumes path.
>>
>> Interestingly when i openend \PhysicalDrive0 with my test
>> program, our driver notified nothing about it, or at least
>> the name of the FileName was empty.
>>
>> So concerning my question:
>> Is there any change getting to know if PhysicalDrive0 was
>> accessed direclty by examaning the FileObject in MJ_IRP_CREATE.
>>
>> What would someone do in general to intercept raw disk access
>> when being a filter driver (so not being at the bottom of the
>> driver stack)?
>>
>> Thanks for any suggestions.
>>
>>
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system 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
>>
>>
>>
>>
>> –
>>
>> - ab
>> — NTFSD is sponsored by OSR OSR is hiring!! Info at
>> http://www.osr.com/careers For our schedule of debugging and file
>> system 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
>
> –
> Kernel Drivers
> Windows File System and Device Driver Consulting
> www.KernelDrivers.com
> 866.263.9295
>
>
> —
> NTFSD is sponsored by OSR
>
> OSR is hiring!! Info at http://www.osr.com/careers
>
> For our schedule of debugging and file system 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

–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></file:></file:></file:>

Scott_Noone_OSR · January 14, 2014, 1:44pm

There are two paths for opens of “\.\PhysicalDrive%d”:

If you ask for data access, the O/S will attempt to mount the drive
(disks have VPBs too) and ultimately mount the raw file system. File system
filters *can* see the subsequent I/O operations, though the I/O happens in a
separate instance from the one mounted over the volume.
If you don’t ask for data access, then the mount process will be bypassed
and the open will be sent directly to disk. This path does indeed completely
bypass the FS stack.

-scott
OSR

“Maxim S. Shatskih” wrote in message
news:xxxxx@ntfsd…
Yes, but volume is file://./C: or \?\Volume{guid}.

\.\PhysicalDrive%d is handled by disk.sys without the FSDs.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

“Peter Scott” wrote in message
news:xxxxx@ntfsd…

Actually you will see these opens as opens where the fileobject’s name is
NULL. When the name is NULL the open is targeted for the volume.

Pete

On 1/14/2014 8:38 AM, A B wrote:

the problem here, i believe is, that you are attaching to the FS, where as
the create Op is coming for the disk device, which is not part of the FS
stack. you will need to attach to volumes and disk to get this create.

On Tue, Jan 14, 2014 at 8:01 PM, wrote:
We got a working filter driver (not a minifilter driver), already developed
some years ago and handle IRP_MJ_CREATE as well as IRP_MJ_CLEANUP our own.
IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE is hooked as well but currently
not used as our needs are handled fine in CREATE and CLEANUP.

What we are looking for at the moment is getting informed when someone tries
to open a physical device directly like with

HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
0,
FILE_SHARE_READ |
FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
0);

or in general reads/writes disk sectors directly.

What I tried so far was using the FileObject obtained from the
currentIrpStack IN MJ_IRP_CREATE callback and looking over its members for
something usefull.
Unfortunately I was only able to get the name from the mounted device
associated, by using the VPB->RealDevice giving me somthing like
\Device\HarddiskVolume1 when querying with ObQueryNameString.
And the FileName contained in the UNICODE_STRING associated with the
FileObject that gives me somethign like \Windows\system32\ f.e.:

NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP
Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION nextIrpStack)
{
PFILE_OBJECT fileObject = currentIrpStack->FileObject;
// …
}

Im still new to Windows File drivers but I thought IRP_MJ_CREATE should be
send down also if someone opens a raw volume and also has a valid FileObject
passed into containing the volumes path.

Interestingly when i openend \PhysicalDrive0 with my test program, our
driver notified nothing about it, or at least the name of the FileName was
empty.

So concerning my question:
Is there any change getting to know if PhysicalDrive0 was accessed direclty
by examaning the FileObject in MJ_IRP_CREATE.

What would someone do in general to intercept raw disk access when being a
filter driver (so not being at the bottom of the driver stack)?

Thanks for any suggestions.

—
NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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

–

- ab
— NTFSD is sponsored by OSR OSR is hiring!! Info at
http://www.osr.com/careers For our schedule of debugging and file system
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
– Kernel Drivers Windows File System and Device Driver Consulting
www.KernelDrivers.com 866.263.9295

OSR_Community_User · January 15, 2014, 1:19am

My impression (and someone correct me if I’m wrong) was that you needed
admin privileges to open a raw disk. Therefore, it cannot be a problem,
since no end user would be allowed to have admin privileges. And if the
user has admin privileges, there is little they could gain by opening the
raw device since they can (if I’m recalling correctly the limitations) do
anything they want anyway.
joe

We got a working filter driver (not a minifilter driver), already
developed some years ago and handle IRP_MJ_CREATE as well as
IRP_MJ_CLEANUP our own. IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE is
hooked as well but currently not used as our needs are handled fine in
CREATE and CLEANUP.

What we are looking for at the moment is getting informed when someone
tries to open a physical device directly like with

HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
0,
FILE_SHARE_READ |
FILE_SHARE_WRITE,
NULL,
OPEN_EXISTING,
0,
0);

or in general reads/writes disk sectors directly.

What I tried so far was using the FileObject obtained from the
currentIrpStack IN MJ_IRP_CREATE callback and looking over its members for
something usefull.
Unfortunately I was only able to get the name from the mounted device
associated, by using the VPB->RealDevice giving me somthing like
\Device\HarddiskVolume1 when querying with ObQueryNameString.
And the FileName contained in the UNICODE_STRING associated with the
FileObject that gives me somethign like \Windows\system32\ f.e.:

NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP
Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION nextIrpStack)
{
PFILE_OBJECT fileObject = currentIrpStack->FileObject;
// …
}

Im still new to Windows File drivers but I thought IRP_MJ_CREATE should be
send down also if someone opens a raw volume and also has a valid
FileObject passed into containing the volumes path.

Interestingly when i openend \PhysicalDrive0 with my test program, our
driver notified nothing about it, or at least the name of the FileName was
empty.

So concerning my question:
Is there any change getting to know if PhysicalDrive0 was accessed
direclty by examaning the FileObject in MJ_IRP_CREATE.

What would someone do in general to intercept raw disk access when being a
filter driver (so not being at the bottom of the driver stack)?

Thanks for any suggestions.

NTFSD is sponsored by OSR

OSR is hiring!! Info at http://www.osr.com/careers

For our schedule of debugging and file system 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 · January 15, 2014, 1:23am

Also Vista+ will fail the writes to \.\PhysicalDrive%d if they hit the defined partitions.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntfsd…
>
> My impression (and someone correct me if I’m wrong) was that you needed
> admin privileges to open a raw disk. Therefore, it cannot be a problem,
> since no end user would be allowed to have admin privileges. And if the
> user has admin privileges, there is little they could gain by opening the
> raw device since they can (if I’m recalling correctly the limitations) do
> anything they want anyway.
> joe
>
>> We got a working filter driver (not a minifilter driver), already
>> developed some years ago and handle IRP_MJ_CREATE as well as
>> IRP_MJ_CLEANUP our own. IRP_MJ_WRITE, IRP_MJ_READ and IRP_MJ_CLOSE is
>> hooked as well but currently not used as our needs are handled fine in
>> CREATE and CLEANUP.
>>
>> What we are looking for at the moment is getting informed when someone
>> tries to open a physical device directly like with
>>
>> HANDLE hDevice = CreateFileW(L"\\.\PhysicalDrive0",
>> 0,
>> FILE_SHARE_READ |
>> FILE_SHARE_WRITE,
>> NULL,
>> OPEN_EXISTING,
>> 0,
>> 0);
>>
>> or in general reads/writes disk sectors directly.
>>
>> What I tried so far was using the FileObject obtained from the
>> currentIrpStack IN MJ_IRP_CREATE callback and looking over its members for
>> something usefull.
>> Unfortunately I was only able to get the name from the mounted device
>> associated, by using the VPB->RealDevice giving me somthing like
>> \Device\HarddiskVolume1 when querying with ObQueryNameString.
>> And the FileName contained in the UNICODE_STRING associated with the
>> FileObject that gives me somethign like \Windows\system32\ f.e.:
>>
>> NTSTATUS Irp_Mj_Create_CB( PDEVICE_OBJECT HookDevice, IN PIRP
>> Irp,PIO_STACK_LOCATION currentIrpStack,PIO_STACK_LOCATION nextIrpStack)
>> {
>> PFILE_OBJECT fileObject = currentIrpStack->FileObject;
>> // …
>> }
>>
>> Im still new to Windows File drivers but I thought IRP_MJ_CREATE should be
>> send down also if someone opens a raw volume and also has a valid
>> FileObject passed into containing the volumes path.
>>
>> Interestingly when i openend \PhysicalDrive0 with my test program, our
>> driver notified nothing about it, or at least the name of the FileName was
>> empty.
>>
>> So concerning my question:
>> Is there any change getting to know if PhysicalDrive0 was accessed
>> direclty by examaning the FileObject in MJ_IRP_CREATE.
>>
>> What would someone do in general to intercept raw disk access when being a
>> filter driver (so not being at the bottom of the driver stack)?
>>
>> Thanks for any suggestions.
>>
>>
>>
>>
>> —
>> NTFSD is sponsored by OSR
>>
>> OSR is hiring!! Info at http://www.osr.com/careers
>>
>> For our schedule of debugging and file system 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
>>
>
>
>