DFIR Tooling - Timmy and His File System

What does Timmy do? Now that's a good question. Timmy is the endpoint agent described in my last blog post, DFIR Tooling - Outline. Timmy will eventually be responsible for facilitating all communication between the user's virtual reality headset and the endpoint on which the user is conducting their forensic analysis. Right now though, Timmy is just learning how to walk.

Secure Network Connectivity

I just finished implementing some basic security for Timmy's network connections using golang.org/x/crypto/nacl/box. I chose this library specifically for its inherent interoperability with libsodium. The thought here is that using a standardized cryptographic protocol will minimize cross-platform compatibility issues when I start working on the VR UI. That work will likely have to be done in C#. C#/.NET is one of my absolute favorite languages, but .NET's native cryptography libraries make some assumptions about the ciphertext format that make it a hassle to use with other languages' cryptography libraries.

I cobbled together a little compatibility layer in the form of a DLL written in Rust to solve this problem in the previous iteration of this project. It's crazy to me that was only 3 years ago. Feels like a different world to me. That compatibility layer worked really well, but it had its own issues (described in the README file). This new approach is a bit more robust and it should help speed up implementation.

That's very much a good thing for me right now. Between my SANS training and some personal life troubles I'm building this out a lot more slowly than I'm used to doing. Slow and steady wins the race, though.

File System Handling

Timmy's firstest and onliest task (for a while, anyway) will be to describe the state of the filesystem and relay that description over the network. What I'm building here amounts to a cross-platform VR-native shell. A shell simply exposes operating system functionality to a user via a graphical (or command-line) interface. Filesystem interactions are table stakes for any good shell, so that's where I'm starting.

Timmy's built with modularity in mind. Filesystem interactions will be handled via a self-contained module in the form of a command handler that's made available in the client at runtime. This design respects the Open-closed principle as much as it can right now, which ought to simplify implementation and troubleshooting when I finally get around to it.

3D filesystems have been tried before, most famously seen in Jurassic Park. In fact, I've tried to implement one before. It was awesome! Check out the images below to see for yourself.

It kept exploding, though.

In short, there's a good reason most filesystems are 2D. 3D adds complexity, and complexity adds hassle to filesystem interactions. Fortunately, I'm going to try to learn from my mistakes and make a more streamlined UI.

In my previous iteration, files and folders were color coded and used different assets (icons) so I could differentiate them. I like that approach and I'll probably keep it. There are three parts that are going to change:

1. My last iteration was unbounded. This iteration will contain the filesystem objects within a bounded 3D plane. This should allow me to minimize and maximize the current working directory on demand, which should ease the hassle considerably.
2. My last iteration ignored most filesystem metadata. This iteration will represent metadata (such as file size) by adjusting the size and shape of each object. This should make it easy to spot any files that are excessively large or excessively small, which will provide an advantage over 2D UIs when analyzing unknown filesystem artifacts.
3. I'm picturing a flat pane attached to the main controller which contains all metadata attributes (such as MAC times, ownership, and ACLs) for each filesystem object. That'll update depending on where the controller is pointing. So: point at a file, learn everything there is to know about that file. That's nothing novel, but I believe it'll be helpful.

All told, this project is coming along nicely. Stay tuned for my next update, sometime around Sunday next week!

Next update: DFIR Tooling - First Code Review