Progress has not been as fast as I hoped lately. There are several reasons for this, but most of it is probably due to a lack of planning. When I finally started programming RustRAT I had a very specific idea of what I wanted to start with. After I finished that specific, little part of RustRAT, progressed seemed to halt to a grind.

While I have slowed down some, progress seems slower than it is because my plan is less detailed for this part of the development. My initial plan looked something like this:

1. Glue together wasm3 and libffi so that wasm blobs can call arbitrary functions.
2. Implement everything else.

This is a slight exaggeration, but is not that far from the truth. Writing the first part with wasm3 and libffi was a quite easy and small task. Even though there are things that will probably be changed in the future, the overall architecture was pretty clear to me from day one. It was also a bonus that it was quite easy to write code to test the libffi bindings for wasm3, making it easy to visualize progress.

I am having a harder time planning everything that is needed for the next step (“everything else”), and there are no concrete plans, only vague goals for what I want it to be like in the end. It is possible to follow the development on my progress page, but I have been unable to finish these goals one by one, and more or less just write some code on whatever part I feel like. I do hope to have something small ready during April though, even if it is just the ability to start a server that receives checkins from rats and nothing more.

Enum onions

This post is called “Progress report: enum onions”, so I better mention this mess of enums I have created as well. It stems from both my lack of experience with Rust, and perhaps the general lack of specific plans for how best to implement what I want to create.

As I wrote in my last post, the server will utilize a MPSC channel to send messages to a “main task” that will do much of the heavy lifting. To do this, I have created a enum of different jobs that can be requested. This enum in turn contains new enums and structs depending on the type of job it is, which in turn contain new layers (hence the onion title) of enums and structs depending on what I needed when I wrote that specific part of the code.

Currently, a “job” enum looks something like this:

1. The “main task” receives a job in the form of a enum, detailing what kind of job it is.
2. Messages from rats (the only type of job implemented at the moment) can either be check ins, basically a rat’s public key, or an encrypted message.
3. Encrypted messages are structs containing the rat’s public key and the encrypted data.
4. Finally, the actual encrypted message from the rat to the server, which is yet another enum.

Now four layers might not seem like much (or does it? I don’t know), but I am getting concerned about the number of layers that suddenly appeared before I even created something useable. I am starting to wonder about my plans, and whether moving this much work into the main task is a good idea after all, it certainly does not seem like the most “async” way to do it. However, for now I will not make any major changes to my plans, so I guess we will see whether these onions are something to cry about later.