Greetings! I would like to validate something, I have a client asking if there is a way to intercept usermode requests to manipulate files on a fixed device partition (not removable media); read, write, delete, create files as well as formatting and deleting the device partition (and yes, I’ve read through this journey through the looking glass [https://community.osr.com/discussion/78245] … but sealing the drive into a block of concrete and dropping it into the Laurentian Abyss isn’t quite what the client wants)
File operations are easy … file system filter driver, done.
My validation is, device media requests like format (RClick from explorer or PowerShell, assume that the user has the ability to do that for whatever reason) look to be the purview of the storage port driver so a storage port class filter driver like this one [https://github.com/microsoft/windows-driver-samples/tree/master/storage/class/classpnp] looks like the ticket, done, yes? Conversely, can I manipulate the readonly bits on the media from the file system filter driver when I attach to the volume? That would save the trouble of the storage filter driver …
Thx!
There are multiple way partitions are created and disks are formatted. Note the IOCTL IOCTL_DISK_CREATE_DISK and friends.
The “read only” bits on the media are subject to very simple manipulation, and here at OSR we’ve ruled-out using them even for quasi-security purposes several times. I’m also not sure that these bits survive all those IOCTLs.
I’m quite confident you’re looking at two filters, unless you want to just block “all writes and all manner of destructive IOCTLs” which you could do down at the storage layer quite nicely. Though the user experience might not be so great.
Peter
Thanks for the feedback Mr Viscarola, it’s kind of what I was thinking would need to be done here … I’m not a big fan of hunting mosquito’s with nuclear weapons, so a very specific file system driver and a very specific storage port filter driver is what I’ll spec for what the client is looking for and go from there … 
I wonder if you could do something cool by intercepting FSCTL_LOCK_VOLUME? Worth checking into…
Peter
Great idea, thx! [https://docs.microsoft.com/en-us/windows/win32/api/winioctl/ni-winioctl-fsctl_lock_volume]
I don’t want to interfere with “normal” volume operations like backups, indexing, cacheing, etc. though … the parameters of the POC are “manage read/ write/ create/ delete operations for a given set of file(s) on a given volume”, and “prevent format/ delete partition on a given volume from usermode” … that’s the mission …
This is more oriented toward preventing ransomware from encrypting a set of backup files on a local fixed media (it’s not, this is an example) or preventing someone from altering a group of supply side files being made available for network download (it’s not, this is another example)
FSCTL_LOCK_VOLUME would appear to inhibit any kind of operations on the volume, beyond the scope of “prevent format/ partition delete”, if they wanted to use the volume for something else they would be hosed … a nuclear weapon for a flyswatter as it were. There are also lot’s of ifs/ ands/ buts in the comments, that’s more stuff to code for (and remember, code written equals bugs written) … but again, I really appreciate the suggestion!
Another great idea, Mr @Pavel, thanks! I’m actually familiar with the UWF, I did a file system filter driver for a client a while back to modify it to operate both on a byte level granularity rather than a file level granularity as well as putting the modified file bytes into an in-memory structure rather than written out to a partition …
Unfortunately it requires the Enterprise version of Win10, plus the in-box version will require a “scratch pad” to cache the modified files … that scratch pad needs to be either on another partition or on a RAM disk, all of which are outside of what the client is expecting … it also doesn’t handle the file level read/ write/ delete/ create filtering …
Great idea though, much appreciated! It’s a great solution if someone doesn’t want to write a driver but wants to prevent file system changes, simply use Win10 Enterprise (and since you can change the product key from Pro to Enterprise, that’s not as painful as it might appear), enable UWF and done. UWF is also really good for machines that need to go back to a known good state (like, as they say, Kiosks or public machines) where you can simply reboot and poof all of the cruft of the day goes away …
UWF is also really good
When it works. Let’s not be too very fulsome in our praise of UWF. It pretty much works, but it has horrible issues with edge conditions… like when you do more writing than anticipated to a protected volume.
Peter
Oh no, there are really definite issues with UWF … but the underlying concept is really cool, like the acetate sheets on the projector that the teacher used in class to mark up lesson notes [does that date me? 
)… mark 'em up all you want, take away the sheet, poof all clean … really a good way to handle machines that are open to the public that lord only knows what has gotten written to them … and in conjunction with a RAM disk as the backing volume, are a way for small computers that use flash as the storage media to get around the write cycle limit.
If I had a) a machine that was going to be available to the public that I wanted to revert back to a known good state with a simple power cycle or b) was on a machine that had a flash based storage media UWF would be up there on the candidate list.
That said, and for anyone (?) searching for UWF in these archives in the future, there are some definite limitations (as of 19H1)
- UWF is only available for Enterprise Win10, although the binaries are all there for Win10 Pro … that can be a licensing issue
- UWF operates on a file level cache, not a byte level cache … which means if you make a five letter change to a 20MB document you will get a 20MB copy in the UWF cache. That can be a problem with small capacity media filling up rapidly
- UWF requires some location to store the cached files, typically another partition or media. That’s a problem because you don’t know how large it should be … 100MB? 2GB? 20TB? Whatever size you choose has to be there before the UWF starts and can be a massive waste of space if it’s too large or could be too small. The MS suggestion is that you use a cache space at least as large as the media it’s backing, with again for small systems can be a problem
- UWF does NOT cache alternate data streams, which for most folks [who likely don’t even know what they are] isn’t a problem but for some folks that’s a big problem
- As @Mr Viscarola mentioned, once UWF runs out of space then really bad things happen
So, Craig, if you liked the idea of UWF, is what you want just ability to mount a drive or volume read-only?
Does such thing as read-only mounting exist in Windows at all (besides of forensic type hardware and software hacks) ?
–pa
is what you want just ability to mount a drive or volume read-only?
Not quite; the client asked for six specific items of functionality for the project: control a specific file read/ write/ create/ delete access (they would pass in a JSON file containing a list of specific files to be monitored) and control a specific volume format/ delete partition command as would be available from a usermode application such as File Exploder or Disk Mangler. Kernel level operations were specifically mentioned as outside of the purview of this (for obvious reasons)
As an example of this kind of functionality (and it’s an example, not the actual application the client is wanting) imagine you wanted to be able to make file/ volume backups but didn’t want Ransomware to encrypt them or for Wiperware to nuke them. The backup files would need to reside on a different volume than the one being imaged (obviously), but would need 100% availability for the automated backups so you couldn’t just disconnect the storage media (which isn’t really solving the problem either, just changing the window of vulnerability). Ransomware would want to read the file (to begin to encrypt) and do an inplace (write) of the encrypted bytes (AES encryption consumes the same byte size as it encrypts, making it ideal for this kind of operation), Wiperware might want to write to the file to scramble it or just delete the file and either one might want to create a trojan backup file if there is a CVE in the backup program restore sequence. Wiperware might also simply try to delete the volume or change it’s partition characteristics …
Does such thing as read-only mounting exist in Windows at all (besides of forensic type hardware and software hacks) ?
In answer to your question of a read-only mounting in Windows, you have to qualify that with what volume you want to make read-only:
- For the volume that is the UEFI boot volume, likely no: most UEFI BIOS’s write information to the GPT UEFI boot partition to update UEFI variables (not all, though, some embedded OS’s are readonly for UEFI variables)
- For the volume that is the Windows boot volume, no unless you are using the UWF due to the OS constantly writing information to the registry store
- Most other volumes visible to Windows, yes
Most folks use the same volume for UEFI booting as the OS is installed on, so for most folks the short answer is “no” with the longer answer being “get the Enterprise edition and enable UWF if you want a read-only Windows volume”
and it’s an example, not the actual application the client is wanting
Well, then UWF is not a good direction at all and I am out of ideas… though if it were, the driver itself is available on a Pro version.
I can install it on my win10 21390 Pro. Maybe the Enterprise is needed just for integration with group policy or other management stuff.
As for the backup functionality, it looks like effective ransomware protection demands combination of hardware and software and certain practices,
just like the damned virus this crap has changed the whole world and there’s no way back.
The hardware measures IMHO are much easier than one can think:
-
Firmware of magnetic and flash-based storage can implement WORM functionality.
Instead of “sequence of blocks” such firmware will behave as “set of variable size, growing blobs”. It is just a firmware change.
-
Write-protection switches on external drives must come back.
(why they disappeared? Is it a conspiration against our ability to protect our data and push us to cloud services?)
If somebody from ex-Sandisk or EMC or storage startups near me reads this, I’m ready to discuss details 
–pa