September, October, November, December, and most of January passed by silently without any RustRAT updates. There are many reasons for this, the two main ones being that I sort of lost the spark after completing a sort-of usable tech demo, and that work mostly fulfilled my programming needs with a few interesting assignments. Now I am back in action, however, and first up is making it more ergonomic to write code that is intended to run in the WASM “sandbox” (which is not much of a sandbox at all with all the holes I am punching in it).

Figuring out exactly what I need is tricky, I have some ideas of what I think I need, but I am not really sure how it should look. The approach I am taking is writing some code that does something useful in Rust, and then I will try to abstract out things that cannot be done “natively” inside WASM, mostly involving API calls and pointers. Ultimately I hope to end up with something that will compile and run both natively, but also from inside my WASM interpreter.

The project

If you have read this far, you are probably wondering what this “some code” doing “something useful” I am writing is. I decided to write functionality to retrieve the loaded DLLs, function pointers by name (or hash), and ultimately to load DLLs and map them correctly in memory and perform relocations. This is nothing groundbreaking, but this kind of functionality is needed to do quite a lot of different activity.

It can serve as the basis for reflective DLL loading, which again can help create shellcode such as done in sRDI. Other techniques for loading codes and attempting to avoid forensics also depend on the ability to parse and alter modules in memory. Futhermore, it is useful when trying to detect user-mode hooks of DLLs, and can also be used to perform unhooking in order to attempt to stay hidden.

The initial rust code will show up in a new “experiments” repository at GitHub when it is ready, before I rework the code and fit it into the main Rustrat repository.