Projected File System

May 16, 2024

I rarely describe features and prefer to focus on my own research, undocumented corner cases, and other fancy things. And what if the feature is not widely known and interesting at the same time? Projected File System (or ProjFS) seems to meet these criteria. It is documented at https://learn.microsoft.com/en-us/windows/win32/projfs/projected-file-system, including some samples.

The idea of ProjFS is relatively simple: if I put my code into the right place, it may provide a list of files and folders (including file content) when user tries to enumerate filesystem data.

We theoretically know that if we dig deep enough, we can make Windows believe the file contains "abc" even if the file does not even exist on the disk. Deep enough means minifilter and filesystem drivers level, which means it’s not quite realistic. And what if the "deep" part of the solution is provided by the Operating System itself, and the part responsible for content generation may be run by anyone, including non-admin users?

It’s exactly how the ProjFS works. By default, the Windows Projected File System component is not installed with Windows. It’s just one of features managed by the "Turn Windows features on or off" applet, which means that turning it on requires administrator privileges. Once the feature is enabled, everyone can use it.

Filesystem asks ProjFS about the filesystem content, ProjFS asks the end-user application, the application replies, and everyone can now see the content provided by an end-user process. Is it useful? It could be. Providing data looking like a file while it is not really a file is something Unix users know very well. /dev/urandom may be a notable example here. Implementing it in Windows seems to be relatively simple: enable ProjFS, create dev folder (called virtualization root), write your application talking to ProjFS API and let it run.

If the application says the file content is random, it is random each time someone wants to read the file. Of course, different scenarios can be interesting here as well. It may be about the content itself, or about the file access. It may be the same folder and file content, or it may change depending on different criteria. Creating something I would call "\dev\timer" seems to be simple, even if not very useful in practice.

Some time ago, I described yet another case: the file content is different depending on who asks for it. If one process seems to check file content, it’s innocent and not harmful. But when another one tries to execute it, something totally different is returned from ProjFS.

The ProjFS API is not very friendly and requires some experience with complex filesystem flows and their callbacks, but if you want to play on your own, you can start with my code: https://github.com/gtworek/PSBits/tree/master/ProjFS.

I hope you will enjoy it regardless of the use case and the final ProjFS usage.

¯\_(ツ)_/¯

[©] Copyright 2024

GT

Projected File System

May 16, 2024

I rarely describe features and prefer to focus on my own research, undocumented corner cases, and other fancy things. And what if the feature is not widely known and interesting at the same time? Projected File System (or ProjFS) seems to meet these criteria. It is documented at https://learn.microsoft.com/en-us/windows/win32/projfs/projected-file-system, including some samples.

The idea of ProjFS is relatively simple: if I put my code into the right place, it may provide a list of files and folders (including file content) when user tries to enumerate filesystem data.

We theoretically know that if we dig deep enough, we can make Windows believe the file contains "abc" even if the file does not even exist on the disk. Deep enough means minifilter and filesystem drivers level, which means it’s not quite realistic. And what if the "deep" part of the solution is provided by the Operating System itself, and the part responsible for content generation may be run by anyone, including non-admin users?

It’s exactly how the ProjFS works. By default, the Windows Projected File System component is not installed with Windows. It’s just one of features managed by the "Turn Windows features on or off" applet, which means that turning it on requires administrator privileges. Once the feature is enabled, everyone can use it.

Filesystem asks ProjFS about the filesystem content, ProjFS asks the end-user application, the application replies, and everyone can now see the content provided by an end-user process. Is it useful? It could be. Providing data looking like a file while it is not really a file is something Unix users know very well. /dev/urandom may be a notable example here. Implementing it in Windows seems to be relatively simple: enable ProjFS, create dev folder (called virtualization root), write your application talking to ProjFS API and let it run.

If the application says the file content is random, it is random each time someone wants to read the file. Of course, different scenarios can be interesting here as well. It may be about the content itself, or about the file access. It may be the same folder and file content, or it may change depending on different criteria. Creating something I would call "\dev\timer" seems to be simple, even if not very useful in practice.

Some time ago, I described yet another case: the file content is different depending on who asks for it. If one process seems to check file content, it’s innocent and not harmful. But when another one tries to execute it, something totally different is returned from ProjFS.

The ProjFS API is not very friendly and requires some experience with complex filesystem flows and their callbacks, but if you want to play on your own, you can start with my code: https://github.com/gtworek/PSBits/tree/master/ProjFS.

I hope you will enjoy it regardless of the use case and the final ProjFS usage.

¯\_(ツ)_/¯

[©] Copyright 2024

GT