I believe there is something fundamentally wrong about needing to write to disk to launch a process. Unfortunately, in Windows the de facto way to launch a process is LoadLibrary or CreateProcess both take a filename as an argument. Previously, I wrote that the Assembly::Load() method will perform that function nicely for you. Unfortunately, it requires your code to be .NET (or that you manage to get access to the .NET code). I knew that CANVAS didn’t touch disk to launch a process but several layers of abstraction to get to the meat.
Immunity and Dave advertise MOSDEF occasionally and post the source code on their website. Despite this it eluded my as to why they’d want a Python based C compiler. The reason is that their C is special, it’s position independent code that you can point EIP to and start executing. This means you can take a C program and have working shellcode. This is lovely because you can reasonably convert your C code to compile with MOSDEF and execute it as shellcode.
As you can see above, the program is almost ANSI C. The difference is that you have to manually import every system/library that you want to use. While this can be slightly troublesome, overall it’s a fairly easy compared to other options.
If you you don’t want to recompile your code, you could always use Metasploit’s technique. Rather than recompiling code, they hook LoadLibrary and replace it with a custom loader. This work is done in Meterpreter. This method could cause some problems with complicated libraries, but overall makes it easier to generic code.
The above is the main code that loads your library. It’s buried in ./framework/external/source/meterpreter/source/server/
I think for a quick solution Meterpreter is probably the easier option, but if you’re looking for more flexibility and/or you’re trying to load your code anywhere Mosdef is probably the way to go. Either way, both methods provide good options for getting custom code onto a remote system without touching the disk.