Can file system minifilters intercept MFT reads and writes?
I think yes. I was able to intercept reads/writes to MFT in a minifilter. But I’m not sure if those are all the reads/writes to MFT.
is there any way to find out the current location and size of the MFT? i.e. can i open it as i would open any other file? also, is there a way to programmatically locate any mirrored copies?
FSCTL_GET_NTFS_VOLUME_DATA
thanks
amit
On Fri, Apr 1, 2011 at 9:26 AM, wrote:
> is there any way to find out the current location and size of the MFT? i.e.
> can i open it as i would open any other file? also, is there a way to
> programmatically locate any mirrored copies?
>
> —
> NTFSD is sponsored by OSR
>
> 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
>
–
- amitr0
awesome, thanks.
Is there any guaranteed method to intercept ALL $MFT and $MFTMirr reads/writes?
any driver below fs can, example volume, disc etc. however, be aware,
certain drivers implement their own NTFS and such IOs might not get caught
if they are below your drivers location…
On Mon, Apr 4, 2011 at 10:01 PM, wrote:
> Is there any guaranteed method to intercept ALL $MFT and $MFTMirr
> reads/writes?
>
> —
> NTFSD is sponsored by OSR
>
> 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
>
–
- amitr0
Are there any example volume drivers in the WDK? Is there a way to get file name from within the volume driver?
My opinion is that this approach is pretty hacky. The file name is not a
concept of the volume, it only makes sense at file system level. So all
attempts to get the file name without asking the proper layer (the file
system) will be hacks (especially considering that NTFS is not documented).
As far as I know, a file system filter (mini or legacy) will always see all
external access to the file system (requests to the file system) . The file
system will internally read its metadata files (like the MFT) in some cases,
for example when it is trying to mount the volume. It might also write to
the volume directly if it finds in an inconsistent state (if the journal is
not in sync with the file system for example) without going through the top
of the IO stack. However, these are implementation details and they might
(and do) change quite often.
It is conceivable that someone will read the MFT directly from the volume
but in that case the OS will not be running (I’m thinking before Windows
starts or on a different OS with NTFS drivers or something). However, once
the file system is mounted any attempts to read its metadata without
synchronizing access (locking the volume or dismounting it) will risk
getting inconsistent data (well, unless the volume is mounted read-only in
which case multiple readers are safe without synchronizing with each-other).
What are you trying to do ? Is this something like encryption ?
Thanks,
Alex.
So Alex, are you saying I should see $MFT and $MFTMirr reads and write from a File System Mini-Filter?
I’m not sure how $MFTMirr is updated. You should see reads and writes for
$MFT in a minifilter. However, they might not be ALL the reads and writes
since the FS might do things behind the scenes. Still this is dependent on
the NTFS driver implementation (and version). Things might change.
Thanks,
Alex.
OK, thanks for the response.