DFIR Tooling - First Code Review
This week we're taking a look at the code I've written so far, what it does, and what it doesn't do quite yet but will need to do in the near future.
Previous Update: DFIR Tooling - Timmy and His File System
It's been another slow week for me over here, but that's very much a good thing. I spent some time getting ready to add network connectivity to Timmy, which requires me to wrap my head around channels and goroutines. Goroutines are a simple, built-in, lightweight concurrency mechanism, while channels are the built-in intraprocess communication mechanism in Go. I'll need to combine these two components to allow asynchronous communication between the client and the server.
Before I get into all that, let's take a look at the code I've written so far.
The entry point for the main binary, Tim, can be found at bin/tim/main.go. Right now all it does is take 3 command line arguments (host_address, port, and public_key), parse them, and load them into a global Application state object. The Application object will eventually be a Singleton when I get around to it. Using a Singleton pattern here will let me create a single Application object once, then grab a pointer to that object anywhere I need it in the application. That'll come in handy later on. For now, let's move on to network connectivity.
Timmy is a callback shell or reverse shell, meaning it's his responsibility to phone home to the user to set up the connection. The command line arguments passed by the user are parsed into a connection.Details object that's needed to initialize a new SecureClient. The SecureClient struct is really the heart of the application so far. It abstracts all the fiddly bits needed to keep the connection secure, and provides a collection of command handlers that will be used to extend Timmy's core functionality.
Honestly there's not a whole lot left to do before this piece is up and running. All I need to do is to set up the async communication routines and figure out exactly how I want to parse commands sent from the server. I'll need to tinker with the handshake protocol a bit in the future in order to add rekeying functionality I suppose. This line, this line, and this line create a bug where messages will get slower and eventually new messages will fail to transmit as the total amount of messages exchanged in a session approaches 2^24. Beyond that though, most of the work that's left to do is in the form of writing new command handlers to extend Timmy's core functionality. And that's where the fun begins.
In the next couple weeks I'll be adding a new binary (tim-control) to this repository. Tim-control will provide a command line interface for interacting with Timmy and will primarily be used for testing purposes. That way I'll have an easy way to know the wire protocol works and I'll be able to test new functionality in traditional environment before I try adding it to the VR UI. It won't be anything too terribly fancy, but it'll be an incredibly useful testing tool.
All in all, this project is moving along pretty well and I'm excited to see what the future holds!
Next Update: DFIR Tooling - Command Handling