MS Windows Only: Need a way to create a private filesystem within the scope of a process

Question

I have an application that launches CPU/GPU intensive applications as child processes. Within each child process I'm looking for a way to create a process-private filesystem (encrypted, hidden, etc...) that only that process has access to. This filesystem can reside on a local disk, UNC path or mapped drive. Only the process that created that private filesystem (subfolder) can have access to it. Any other process, including users and administrators, must not be able to "see" the contents of that private filesystem. This filesystem can be disk-based or memory-based (as long as the memory-based filesystem can be accessed via a mapped-drive)

Possibile solutions:

1. Process-private RAMDISK. (not visible or accessible to logged in users)
2. Encrypted folder that can me managed by unique (random) passwords that are maintained by the process. Again, users and admins must never be allowed to access the contents of this filesystem.
3. Custom device driver?

Note: The "filesystem" can be an actual disk-based filesystem or a folder that resides on an existing disk hierarchy.

Any help would be much appreciated.

Answer 1

I don't think this will be possible, but I'll tell you why as that information can hopefully inform your decision on what method to use to stop users accessing the information.

Hidden Folders

The issue here is that anything that you hide using conventional means I can pretty much guarantee to find. This isn't even an especially difficult process on windows. Any application that I run on my PC can be investigated with process monitor - this Microsoft program will allow you to see every file the process accesses, reads or writes from. It's shockingly easy to use (considering how little it's used by the average user) and will go to the level of detail of showing the exact files accessed or any registry keys used.

Encryption/Password protection

This is a more robust solution than hiding things, but it's not a guarantee. The old adage of 'any client software is in the hand of the enemy' is relevant here. If you plan to read from an encrypted folder, you'll need some way of decryption, similarly if it's password protected then you'll need some way of giving the file system the password. If you plan on doing that on my computer I can see everything you're doing. It would likely need some software like ollyDbg which allows me to see the instructions you're process is running on my machine, which I personally feel is a lot more effort than using process monitor. It's not a question of simply attaching to the process and then viewing a list of all file read/written - although ollyDbg does make it as easy. There are lists of strings, searchable op codes, everything someone looking to access your encrypted/password protected data would need.

Obfuscation

You didn't mention this, but it's worth a look. Obfuscation basically means hiding your data in plane sight. If you obfuscate your code that does the encryption/password handling then things get much more difficult. Without more data on what you're doing it's hard to suggest specifics on how to obfuscate - in fact if you're especially paranoid you wouldn't want to follow my suggestions as it would be a guide on how your code is obfuscated for anyone to find on google.

Answer 2

In a project I worked there was a "filesystem" which basically had a map of hashes: [path, fileInMemory].

In our case, the filesystem was static, stored between multiple files and encrypted.

On program init, it was decrypted and the map was populated. In our case all the "virtual paths" we used would like to access "Disk D:" so for example "d:\file", this was because we supported having unencrypted files in the real fs and use them (easier development)

However, it has the problem that you have to modify the sourcecode or...

Use MinHook or Detour.

You can use my method (or something similar) with detour or minhook hooking the WIN32 file api, this way you can redirect/do anything you want with the files, store them in memory etc... or easier, let them be in any folder you want but encrypting them and decrypting them when the api is called.

These are ideas that maybe not ideal, I hope that at least I gave you more options.