The rat is almost fully functional (for certain values of fully functional), and communication between rats and the server is operational. It is not quite ready, but a new update with a new git commit should hopefully be coming this or next week. While I think everything has proceeded surprisingly smoothly, I have spent many hours debugging stupid mistakes, and this post is about yet another mistake.

May is almost upon us, and it is time for another quick post on Rustrat progress. Implementing the random seed “generators” from last post went smoothly as soon as I realized that inline assembly is only available in nightly, and figured I needed to do something else. I decided to go for separate files containing the assembly for the required functionality, adding a custom build script to build the assembly file using CC. This post is not about my adventures with MASM, however, although I might revisit that later on. As you may have guessed from the title, this post is another cautionary tale about what can go wrong when you play with unsafe rust and pointers.

RustRAT uses libffi (more specifically the libffi-rs bindings) to call arbitrary functions at run-time. This works by putting the function’s argument and return types into a struct and providing libffi with a function pointer. Libffi then makes sure that all the arguments are placed in the correct registers or on the stack and calls the function pointer. I am not that proficient with Rust yet, but if anything is unsafe, I am pretty sure this is it. While developing RustRAT, my tests would initially contain calls to libffi-rs’s own call function and everything was proceeding smoothly. The call function is essentially something like this: