Minifilter on FAT32

I have 2 basic questions regarding file system minifilters for Windows 7 thru 10. (I have done some preliminary searching, but have not found definitive answers, so just hoping for confirmation from this forum.)

1/ Is it possible to filter on disk volume whose file system is FAT32 (vs NTFS)?
(My educated guess is that the answer is “yes”.)

2/ Is it possible to “hide” the disk/device volume from the system?

I am certain I will need to expound on these in the near future… ;^)

Thanks!
MarkH

If you are asking about registering a minifilter for FAT32 volumes only I think this is not possible( maybe I missed something ). You can figure out file system type a filter is being attached to and decide whether to attach or skip this volume. For example

  • FltGetDeviceObject (FltGetDiskDeviceObject on old systems w/o Volume Manager if FltGetDeviceObject failed) can be used to get a volume object to retrieve volume/disk sectors to determine file system type by looking for known signatures.

  • Also, a volume object returned by FltGetDeviceObject can be used to get a pointer for a mounted file system object through Volume->Vpb->DeviceObject, then a file system object name can be queried by ObQueryNameString and compared with a known file system driver name ( \FileSystem\fastfat in this case ) .

It depends.

You can “hide” it from a user GUI but the system still knows about the volume and it is accessible by a full device path ( like \Device\HarddiskVolumeN, e.g. a file can be opened as \Device\HarddiskVolumeN\DirName\FileName ) .

A volume object is a PDO and the Volume Manager uses PnP subsystem to report new volumes to the system and it is very tricky to remove it from IRP_MN_DEVICE_RELATIONS to completely “hide” it from the system and keep it alive for IO as IRP_MN_START will not be sent to it by the PnP Manager.

P.S. Below is a WinDBG output for a volume object relation with a mounted file system object. The volume object was retrieved by a call to FltGetDeviceObject.

4: kd> ??VolumeObject
struct _DEVICE_OBJECT * 0xfffffa80`0d229060
/…/

4: kd> !devstack 0xfffffa80`0d229060
!DevObj !DrvObj !DevExt ObjectName
fffffa800fc2a040 \Driver\volsnap fffffa800fc2a190
fffffa8010dfb940 \Driver\fvevol fffffa8010dfba90

fffffa800d229060 \Driver\volmgr fffffa800d2291b0 HarddiskVolume10
!DevNode fffffa8010dfc670 :
DeviceInst is “STORAGE\Volume_??_USBSTOR#Disk&Ven_Innostor&Prod_Innostor&Rev_1.00#000000000000001518&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}”
ServiceName is “volsnap”

4: kd> ??VolumeObject->Vpb->DeviceObject
struct _DEVICE_OBJECT * 0xfffffa80`0d359030
/…/

4: kd> !devstack 0xfffffa80`0d359030
!DevObj !DrvObj !DevExt ObjectName
fffffa8010e31ce0 \FileSystem\FltMgr fffffa8010e31e30
fffffa800d2face0 \FileSystem\pgpfs fffffa800d2fae30
fffffa800cf95440 \FileSystem\FltMgr fffffa800cf95590

fffffa800d359030 \FileSystem\Ntfs fffffa800d359180

Ooops, a typo in my post

“then a file system object name can be queried by ObQueryNameString”

should be read as

“then a file system DRIVER object ( i.e. Volume->Vpb->DeviceObject->DriverObject ) name can be queried by ObQueryNameString”

Thank you, Slava, for your helpful reply. My questions were actually a bit more general…

1/ I was just wondering if it was possible *at all* to register a minifilter for a FAT32 volume. For example, a user inserts a USB disk that contains FAT32 format. I would want to place my own minifilter on that disk, i.e. for that file system device stack.

I know that this can be done for NTFS volumes; I just was not sure if a minifilter would “work” for FAT32 volumes, as well. I think you have confirmed that indeed that should work, as well.

2/ I would like to be able to hide it from the GUI, e.g File Explorer, if at all possible. I realize it would be difficult to disguise it from the system overall; but I believe I could satisfy the requirement of the project by not showing it in cases where an application would be querying for it.
For example, is there some set of IOCTLs that I could intercept with a disk/volume filter?
(I am guessing this would not be possible by filtering at file system level?)

Thanks!
MarkH

Check the Instance Setup Callback doc, you can decide in that callback to
attach (or not) the minifilter to a new volume (e. g. your USB storage
device) The filesystem (NTFS, FAT, etc.) info is one of the parameters.

Regards,

Julian

El El mar, 15 ago 2017 a las 9:14, xxxxx@knowwareinc.com
escribió:

> Thank you, Slava, for your helpful reply. My questions were actually a
> bit more general…
>
> 1/ I was just wondering if it was possible at all to register a
> minifilter for a FAT32 volume. For example, a user inserts a USB disk that
> contains FAT32 format. I would want to place my own minifilter on that
> disk, i.e. for that file system device stack.
>
> I know that this can be done for NTFS volumes; I just was not sure if a
> minifilter would “work” for FAT32 volumes, as well. I think you have
> confirmed that indeed that should work, as well.
>
> 2/ I would like to be able to hide it from the GUI, e.g File Explorer, if
> at all possible. I realize it would be difficult to disguise it from the
> system overall; but I believe I could satisfy the requirement of the
> project by not showing it in cases where an application would be querying
> for it.
> For example, is there some set of IOCTLs that I could intercept with a
> disk/volume filter?
> (I am guessing this would not be possible by filtering at file system
> level?)
>
> Thanks!
> MarkH
>
>
> —
> NTFSD is sponsored by OSR
>
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
></http:>

Thank you Julian - very helpful indeed!

So by checking in my PFLT_INSTANCE_SETUP_CALLBACK callback function that the parameters (FLT_FILESYSTEM_TYPE == FLT_FSTYPE_FAT) && (DEVICE_TYPE == FILE_DEVICE_DISK_FILE_SYSTEM), I could be certain I am attaching to a FAT disk, correct?

I also need to verify that this is coming from our own USB disk …
I suppose if I check that (FLT_INSTANCE_SETUP_FLAGS == FLTFL_INSTANCE_SETUP_NEWLY_MOUNTED_VOLUME), it would have to at least been inserted after system has been up. But then what about the case that the USB disk was left in during reboot?

So the new question becomes:
How does one ensure that the volume (newly arrived or already present) is on removable media, specially USB disk?

Thanks again for the help!
MarkH

So to answer my own question:

How does one ensure that the volume (newly arrived or already present) is on removable media,
specifically USB disk?

I think I see …
Basically, during Instance setup function, issue IOCTL_STORAGE_QUERY_PROPERTY and check that returning PSTORAGE_DEVICE_DESCRIPTOR->BusType == BusTypeUsb.

Can anyone verify that I am on the right track here?

Thanks,
MarkH

(Sorry for repeated posting …)

Would a more “modern” approach be to simply call FltGetVolumeProperties in the Instance setup function, and check - among other things - that PFLT_VOLUME_PROPERTIES->DeviceType == FILE_DEVICE_MASS_STORAGE?

For USB hard drive volumes on disks with ATA / SATA interface the reported bus type might be BusTypeAta / BusTypeSata.

A USB pen drive should report BusTypeUsb.