MiniFilter Driver Windows 10

NTFSD
1

How I would block devices through minifilter driver in Windows 10?
*Description*: I’ve a minifilter driver which blocks devices, it works fine
in Windows up till ver8.1 but I’m having problem in Windows 10.
Driver is able to block devices once when system is reboot and then it
automatically unblocks all the devices in Windows 10 when I start my
application.

*Example*: Windows 10 -> Application get installed system need to reboot,
the system reboot and all Non-System Partitions and USB get blocks (i.e:
Access is Denied), by default application blocks USB when it’s checkbox is
checked but Non-System Partitions is unchecked, but still after getting
reboot Non-System Partitions is Access is Denied.

Then when I run my application all the blocked things get unblock and the
things should be blocked get unblocks as well.

I’ve coded PreOperationCallBack, PostOperationCallBack,
Operation_Registration_Callbacks (IRPs) and every driver routine that
needed to perform blocking and unblocking the devices.

2

By completing create requests with STATUS_ACCESS_DENIED error in PreOperation callback.

Fix this application so it provided a correct information to the driver. Seriously, what is your question?

3

You cannot block devices with the minifilter model. You can only process
file system related events.
Filesystems, if you think about it abstractly reside on the disk/device as
random pieces of data on their surface as far as the device ( whatever that
might be) is concerned. The file system driver is called to recognize that
a certain disk has a filesystem it can “work with”.
At this point, the point where the filesystem is called to recognize the
filesystem your driver is not even loaded for filtering even though the
device is up and running and doing its’ thing. The fact that is a valid
filesystem there (on the disk) is a “coincidence” as far as the OS is
concerned. You can store on a disk whatever raw data you want and at that
point as far as the OS is concerned the device is running, but as far as
the filesystem is concerned there is no valid FS there. You can get a
handle to the device and use ReadFile and WriteFile on it and use it
essentially like a big file to read and write data to it. If you really
want to block devices, the assumption you can block them with a minifilter
is not correct.
You would need to implement a PNP filter to check out what device classes
you are interested in, filter the correctly according to their stacks and
block them from there. See if you need a lower or upper filter in that
stack, propagate flags correctly. Allow devices that you are not interested
in to run correctly and only block the ones you should depending on your
policy. Also blocking a device can occur, depending on the device in
different stages of the filtering.
Good luck.

Regards,
Gabriel
www.kasardia.com
Windows Kernel Driver Consulting

On Wed, Sep 7, 2016 at 3:36 PM, wrote:

>


>
> By completing create requests with STATUS_ACCESS_DENIED error in
> PreOperation callback.
>
>


>
> Fix this application so it provided a correct information to the driver.
> Seriously, what is your question?
>
> —
> 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;
>

–
Bercea. G.</http:>

4

Block devices access are checked at FSD level. This is how NTFS works.

In case of block devices this requires administrator or SYSTEM privilege if nobody changed object security descriptors which in turn requires elevated privileges. Trying to block a device for administrator or system usually doesn’t make sense as this requires hypervisor to implement such protection.

5

MTP devices don’t use a host file system, so you can’t block those with a
minifilter.

In newer versions of Windows (at least Win7) the interactive user is given
write access to the device. For example, you can format a USB device from an
unelevated command prompt.

-scott
OSR
@OSRDrivers

wrote in message news:xxxxx@ntfsd…

Block devices access are checked at FSD level. This is how NTFS works.

In case of block devices this requires administrator or SYSTEM privilege if
nobody changed object security descriptors which in turn requires elevated
privileges. Trying to block a device for administrator or system usually
doesn’t make sense as this requires hypervisor to implement such protection.

6

I would advise to do some more digging around what you claim for the sake
of your requirements and what you hope to achieve.
Again do not confuse NTFS.sys or any other FS ( which are not PNP drivers,
they are not specific to a device) with what the drivers “below”: disk.sys,
acpi, raidport or any device specific driver ( PNP level driver ).
A FS is something that is “attached” to a medium or to a volume. A volume
is a region on a disk that you can format it with a filesystem. You can
also filter at volume level, or at FS level ( different things ). Volume
devices are PNP devices and have a class and stack of their own as far PNP
goes.

When you are at FS level you cannot hope to deny anything that is device
specific. You can only deny access to what a certain FS considers to be a
file. I thought this was common sense for a FSF driver developer. By saying
“Block devices access are checked at FSD level. This is how NTFS works.” it
means you think that USB devices (for example ) cannot be filtered only at
FS level which is completely wrong.

Please take your time and view your requirements and see if you need device
filtering or FS level filtering is enough. It might be but I have no idea
what you really want to achieve.

Regards,
Gabriel
www.kasardia.com

On Wed, Sep 7, 2016 at 6:14 PM, wrote:

>


>
> Block devices access are checked at FSD level. This is how NTFS works.
>
>


>
> In case of block devices this requires administrator or SYSTEM privilege
> if nobody changed object security descriptors which in turn requires
> elevated privileges. Trying to block a device for administrator or system
> usually doesn’t make sense as this requires hypervisor to implement such
> protection.
>
> —
> 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;
>

–
Bercea. G.</http:>

7

MTP devices are not block devices. MTP is a file transfer protocol like FTP.

This is just remounting with RAW FSD, so if a minifilter doesn’t allow access the operation will fail. When a volume is opened for anything beside read attributes(IIRC) the RAW FSD is mounted.
Below are call stacks for a format operation. A FilterManager’s object attached to a RAW FSD object is clearly visible.

The RAW FSD mounting

00 nt!RawDispatch
01 nt!IopDeleteFile
02 nt!ObpRemoveObjectRoutine
03 nt!ObfDereferenceObjectWithTag
04 nt!ObfDereferenceObject
05 nt!RawMountVolume
06 nt!RawFileSystemControl
07 nt!RawDispatch
08 nt!IofCallDriver
09 fltmgr!FltpFsControlMountVolume
0a fltmgr!FltpFsControl
0b nt!IofCallDriver
0c nt!IopMountVolume
0d nt!IopCheckVpbMounted
0e nt!IopParseDevice
0f nt!ObpLookupObjectName
10 nt!ObOpenObjectByName
11 nt!IopCreateFile
12 nt!NtOpenFile
13 nt!KiFastCallEntry
14 ntdll!KiFastSystemCallRet
15 ntdll!NtOpenFile
WARNING: Stack unwind information not available. Following frames may be wrong.
16 ifsutil
17 ifsutil
18 ifsutil
19 FMIFS!ConvertSectorSizeIfNeeded
1a FMIFS!FormatEx2
1b SHELL32!CFormatEngine::ExecuteFormat
1c SHELL32!FormatThreadProc
1d kernel32!BaseThreadInitThunk
1e ntdll!__RtlUserThreadStart
1f ntdll!_RtlUserThreadStart

The RAW file object opening to perform IO

00 nt!RawDispatch
01 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
02 fltmgr!FltpCreate
03 nt!IofCallDriver
04 nt!IopParseDevice
05 nt!ObpLookupObjectName
06 nt!ObOpenObjectByName
07 nt!IopCreateFile
08 nt!NtOpenFile
09 nt!KiFastCallEntry
0a ntdll!KiFastSystemCallRet
0b ntdll!NtOpenFile
WARNING: Stack unwind information not available. Following frames may be wrong.
0c ifsutil
0d ifsutil
0e ifsutil
0f FMIFS!ConvertSectorSizeIfNeeded
10 FMIFS!FormatEx2
11 SHELL32!CFormatEngine::ExecuteFormat
12 SHELL32!FormatThreadProc
13 kernel32!BaseThreadInitThunk
14 ntdll!__RtlUserThreadStart
15 ntdll!_RtlUserThreadStart

The RAW file object IO to format the volume

00 nt!RawDispatch
01 fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted
02 fltmgr!FltpDispatch
03 nt!IofCallDriver
04 nt!IopSynchronousServiceTail
05 nt!NtWriteFile
06 nt!KiFastCallEntry
07 ntdll!KiFastSystemCallRet
08 ntdll!NtWriteFile
WARNING: Stack unwind information not available. Following frames may be wrong.
09 ifsutil
0a ifsutil
0b ifsutil
0c UNTFS!NTFS_VOL::Initialize
0d UNTFS!FormatEx
0e FMIFS!FormatEx2
0f SHELL32!CFormatEngine::ExecuteFormat
10 SHELL32!FormatThreadProc
11 kernel32!BaseThreadInitThunk
12 ntdll!__RtlUserThreadStart
13 ntdll!_RtlUserThreadStart

0: kd> !devstack 0x870c6b40
!DevObj !DrvObj !DevExt ObjectName
870c6020 \Driver\volsnap 870c60d8
870d4c80 \Driver\fvevol 870d4d38

870c6b40 \Driver\volmgr 870c6bf8 HarddiskVolume3
!DevNode 870c1c98 :
DeviceInst is “STORAGE\Volume_??_USBSTOR#Disk&Ven_SanDisk&Prod_Cruzer_Facet&Rev_1.27#4C530007661201117570&0#{53f56307-b6bf-11d0-94f2-00a0c91efb8b}”
ServiceName is “volsnap”

kd> !devobj 870c6b40
Device object (870c6b40) is for:
HarddiskVolume3 \Driver\volmgr DriverObject 862cf490
Current Irp 00000000 RefCount 1 Type 00000007 Flags 00003050
Vpb 879ff308 Dacl 903c7c9c DevExt 870c6bf8 DevObjExt 870c6ce0 Dope 870afc48 DevNode 870c1c98
ExtensionFlags (0000000000)
Characteristics (0x00000001) FILE_REMOVABLE_MEDIA
AttachedDevice (Upper) 870d4c80 \Driver\fvevol
Device queue is not busy.

1: kd> !vpb 879ff308
Vpb at 0x879ff308
Flags: 0x21 mounted
DeviceObject: 0x863c3e30
RealDevice: 0x870c6b40
RefCount: 1
Volume Label:

1: kd> !devstack 0x863c3e30
!DevObj !DrvObj !DevExt ObjectName
864981d0 \FileSystem\FltMgr 86498288

863c3e30 \FileSystem\RAW 863c3ee8

8

Actually they process PnP requests. It is just a way they are being mounted not by the PnP Manager but by the IO Manager.

This is very interesting point of view.

A volume is the same abstraction as a file. A volume doesn’t have any implication on hardware implementation or management.

You don’t have such opportunity at any level if an attacker has elevated privileges. The direct access to a controller IO memory range will be used which can’t be detected by any driver. But if we are speaking about a non compromised system the user access can be restricted at FSD level.

9

Yet MTP devices provide a way for someone to plug a USB device in and transfer files. Secure environments often care about these things, so it’s a matter of what you’re trying to protect.

My comment about device access had specifically to do with the statement that this being administrator or system only activity.

-scott
OSR
@OSRDrivers