I want to create a minifilter driver to transparently redirect disk i/o, but I'm having trouble getting started

Question

A project I'm working on at the moment requires the implementation of a copy-on-w/m mechanism which will be used to redirect disk i/o in a similar manner to Deep Freeze or Sandboxie, on Windows XP. If I could I'd also like to be able to "mount" the user's modified files, similar to how VirtualCloneDrive simulates disk drives and transparently mounts ISO images on them.

It is my understanding that such programs make use of minifilter drivers to redirect i/o requests. The standard process copies any modified data to a secondary location and then reads/modifies that storage for subsequent access to that data; so I think I understand what I would need to do there. When it comes to simulating a CD/DVD drive and mounting an image on it though, I'm completely lost.

I've been looking online (Google, MSDN, The Code Project etc) and in books such as Developing Drivers with the Windows Driver Foundation and Windows NT File System Internals : A Developer's Guide, but finding specific information and examples (on monitoring, intercepting and redirecting requests and creating loopback devices) is proving difficult. I'm still quite new to the technologies involved, so maybe I'm having trouble seeing the forest for the trees.

I was wondering if anyone has been in a similar situation and had discovered any useful resources, or could point me in the right direction so I could implement similar functionality.

Edit: I found this question which seems like a useful resource (though not for my specific use case), so I've linked it here to add to any forthcoming responses.

Some clarification:

I am trying to create a program which will allow users to install and use applications without needing administrative privileges. The program will work by saving any filesystem/registry modifications to a seperate storage area (a file on a pen drive or network store, for example) then allowing these to be integrated into any desktop on which the host program is runnning, on the fly. Carry your desktop around on a USB pen, plug it in, and your settings are applied.

To redirect the I/O, I could:

1. Patch a process' Import Address Table (IAT) to insert customised code at the application level.
2. Write a user-mode filter driver to modify the requests on the fly.
3. For enhanced (any at all, really) security, implement a kernel-mode driver to patch the System Service Descriptor Tables (SSDT's) in a similar manner to AV software.

There are upsides and downsides to each of these approaches. For example, approach three is much more difficult than approach one. It provides more security, but even then it can be beaten (theoretical attacks have been around since '96, practical attacks since '07.)

I was initally considering specific security features (as opposed to just i/o redirection similar to WoW64 compatibility settings); but since starting to look at this I've remembered that you cannot protect the user from himself forever, and that no matter how much work I was to put into defending a host system from a malicious process or foolish user it could be beaten (or more likely I would make a mistake.) I also decided to avoid reinventing the sandboxing and antivirus wheels and simply concentrate on creating some useful functionality. The philosophy of "a tool should do one job and do it well" won the day.

In a nutshell, all I want to do is implement functionality similar to that of VM snapshots, and redirect changes to my own storage area. The diagram below is a little out of date, but it might be better at communicating my intentions than I am at the moment :-)

Drue

You don't give much details about what you want to do but I guess you need a very good experience with system calls and driver programming... – Xenon

You make a good point. I've added some more information to try to clarify things a bit. Thanks :-) – Drue

Installing a minifilter driver requires administrative privileges (for the initial setup, you could establish a route to use that driver without special privileges)... Also note that the Terminal Services feature on server editions of windows has a similar redirector function – Hugohugon

@Hugohugon Is there a preferred way to communicate with a minifilter driver from an unprivileged application? – Drue

@Adam, generally you'd have a userspace service process acting as a gatekeeper – Hugohugon

Also note that if you have a minifilter applying to all I/O from a given process, you won't need any DLL injection. – Hugohugon

Also, be sure to consider the security implications of FS shadowing when other processes impersonate yours (if they do a LoadLibrary, do they get the shadow filesystem? If so, what stops the user from giving them a modified library?) – Hugohugon

@Hugohugon I think I understand what you're getting at with your point about other processes impersonating mine, but if you could explain a bit more I would appreciate it. I think what you're saying is that if a process I'm filtering I/O on calls LoadLibrary, would they receive the native library or a copy that I provided. Correct? – Drue

If you redirect all I/O via a miniport driver, all requests, including LoadLibrary, get filtered. It gets weirder if you remove the minifilter after the LoadLibrary completes... – Hugohugon

Answer 1

The WDK has all the examples you need on minifilters under samples/filesys/minifilter, they are decently documented, but a little confusing in parts. However, as mentioned in the comments, this need admin privilages to use used, but so does any form of patching or hooking(see SeDebugPrivilege)

Cauterant

How did I not find this before? This should be very helpful, thanks! – Drue