An Introduction to Windows File System Filter Driver
A file system filter driver intercepts requests targeted at a file system or another file system filter driver. By intercepting the request before it reaches its intended target, the filter driver can extend or replace functionality provided by the original target of the request.The filter driver concept is one of the most powerful architectural features of the Windows I/O subsystem. A filter can add value to the functionality of an existing device by simply attaching itself over that device. And, of course, filtering a device requires no change to the driver for the underlying device.
One of the most common, and also the most powerful, places to insert a filter in a Windows system is over a file system. File system filters intercept I/O operations (from both applications and the system itself) before those I/O operations reach the file system. This allows them to monitor, track, manage, manipulate, and even accept or reject I/O operations before the file system gets to see them. The type of file system filter that most people are familiar with is probably the antivirus filter. This type of filter typically intercepts file open requests and suspends them while the filter (or, more likely, an associated service running in user mode) scans the file being opened for viruses. If any viruses are found, the open request can be canceled. If no viruses are found, the open request can be allowed to complete normally.
File system filters are commonly used for everything from antivirus and malware scanning as just described, to software license tracking and management, to auditing and changed tracking on files, to on access transparent data encryption and decryption. File system filters can also be used for other, less obvious, purposes. For example, because they see which files are created and written, file system filters are often play key roles in backup products and hierarchical storage subsystems. And because file system filters are able to be the first interpreters of the file system “name space” that applications see, they can also perform powerful file redirection operations, such as making a remote file (such as one stored somewhere in the cloud) appear to be local.
Since its introduction in Windows XP SP2, the File System Minifilter model has become the preferred mechanism for implementing file system filters. This is for good reason, because the Minifilter model provides an excellent organization and support framework for file system filter driver development. With reasonably good documentation and a significant set of examples on GitHub, many devs feel that writing a file system Minifilter is well within their ability. And they’re right… provided they stay within certain boundaries.
The Standard Mini Filter Driver
The most common type of file system Minifilter monitors, and perhaps tracks or records, various operations performed at the file system level. Some Minifilters, such as antivirus scanners, might even approve or disapprove certain operations. These filters do not, however, become involved in changing the view, or the size, of the data in the files they filter. We term such filters Standard Minifilters, because they represent the vast majority of the file system Minifilters that exist.
The primary challenges that developers of Standard Minifilters face are:
Properly understanding and dealing with native Windows I/O Subsystem semantics.
Properly preserving the behavior of all native file system operations, even the ones they don’t necessarily understand or care about.
Of course, this is in addition to the basic challenges inherent in writing any Windows kernel-mode driver.
Overcoming the first of these challenges, that is properly understanding and dealing with native Windows I/O Subsystem semantics, simply requires time and experience. There are numerous Microsoft-provided examples that can be used as a starting point. And the documentation on writing basic file system Minifilters is surprisingly good – Assuming you take the time to read it and understand it.
The complexity of item B, above, depends greatly on the type of Minifilter you write. The simpler you keep your operations, and the more limited you keep your filtering, the easier things will be. For example, it’s usually a mistake to attempt to filter I/O operations that your filter doesn’t specifically care about. The HLK tests for file system Minifilters will be very helpful to you in assessing your success in preserving the behavior of the file systems you filter. Be sure you run them!
Thus, if you need to write a Standard Minifilter – that is, one that monitors file system operations – the challenges you face will be reasonable.
The Isolation Mini Filter Driver
An Isolation Mini Filter Driver
is a Windows file system Minifilter driver that separates the view(s) of a file's data from the actual underlying data of that same file. A typical example of an Isolation Minifilter is an on access transparent encryption/decryption filter.
Isolation Minifilters use the “same stack” concept, and provide their different views by providing unique cache sections for each view.A transparent encryption isolation filter driver can create two views of the access data, one is encrypted from the local storage, so your data is always encrypted in the local disk, the other one is decrypted to the authorized user, for every file open, the filter driver will create an unique memory cache, so the users or processes won't see the same view of the data if they have different permission. When the process or the user was authorized to access the encrypted file, the filter driver will decrypt the data in memory during the read request, so the authorized process can get the plain text back, or it will get the ciper text. When the encryption filter driver is turned off, the encrypted file can’t be accessed, when the application opens the encrypted file, it will get cipher text, so no one can read the encrypted files without the encryption filter driver enabled.
The isolation filters separate (or “isolate”) the view
of a file’s data from the actual underlying data
stored by the file system. Writing this type of Minifilter is usually as complex as writing a standard Windows file system, because it involves direct and close interaction between your Minifilter, the Windows Cache Manager, and the Windows Memory Manager. In fact, some experienced devs consider Isolation Minifilter even more difficult than file system development, because when you’re writing an Isolation Minifilter you effectively have to “fit” the implementation of a Windows file system into the API provided by Filter Manager. Thus, in addition to the challenges faced by the developers of Standard Minifilters, developers of Isolation Minifilters deal with numerous significantly more complex issues.
To implment the separating view of a file’s data form the actual underlying data, we need two types of file object, the first file object is the uper file object which is the open instance associated with the application, it represents the application’s view of file, it contains decrypted data, the data was placed into cache by the Isolation Filter, working in cooperation with the Cache Manager.
The other file object we called is the shadow file object, it is created by the Isolation Minifilter, and represents the Minifilter’s (and the underlying file system’s) view of the file. The data in the cache section for this file object is encrypted, the Isolation Minifilter uses the shadow file object to interact with the underlying file system. The shadow file object was created during the IRP_MJ_CREATE dispatch handler by the isolation filter driver, and sends this shadow file object down to the underlying FSD. To control the uper file object, the isolation filter will fill the fields FsContext/FsContext2 of the file object structure, now the uper file object belongs to the isolation filter, to control the cache, the isolation filter also will set up the SOP structures to point to the control data section crated by the filter.
The most challenge of the isolation filter driver is to handle all the IOs for the uper file object which was sent down by the user, if the upder file object was sent down to the NTFS, the NTFS will blow up in a function called NtfsDecodeFileObject. Developing an Isolation Minifilter is more like developing a full Windows file system than developing a Standard Minifilter, because it requires close interaction with the Windows Cache Manager and Memory Manager. As such, the development of an Isolation Minifilter is not likely to be a task that can be successfully undertaken by most developers who do not also seek to become Windows file system experts.
Isolation Minifilter for virtual cloud storage
: the Isolation Minifilter model is not only used for transparent data encryption and decryption systems. The Isolation Minifilter model also can be used by the virtual cloud storage, it can present a virtual file structure view to the user,
the view of the data was associated to the remote cloud storage,
when the user read the data of the virtual file, the filter can pull back the data block by block.