The original date for this is actually 2004. Maybe 2003, but I can’t find an archival link.
I wrote the code because someone asked how to do this and it was easier to implement it than to explain it in detail. The whole thing is based on what I learned from “Linkers & Loaders,” a great book. (I still have my copy)
Later that year I wrote a wrapper around ul_exec() that used an automated interactive session with gdb to load a process, replace it with another binary (delivered over STDIN) and then execute that. This would prevent the binary ever being written to disk.
Remote exec was documented in phrack 62, along with the more advanced theory of counter forensics. Interestingly, the techniques I discussed in rexec() are now common APT tradecraft. Using common tools to limit the chance of detection and reduce evidence, aka living off the land, is now standard practice. I explained why about 20 years ago :)
QNX always did it that way. One of their basic design decisions was to never process strings or complex data formats in the kernel. That's all in user space, which is good for crash prevention. It's hard to have kernel buffer overflows when you don't have kernel buffers.
The boot loader loaded an image into memory which contained the kernel, a utility process called "proc", and whatever else needed to be available at startup. For an embedded application, that might be the entire program. For a standard desktop environment, it would include a disk driver, a network driver, and a startup program.
Shared object files could also be loaded as part of the initial image. One of them was the program loader. The C library for QNX had calls for the various 'exec' functions, but they were just passed to the program loader shared object. With no special privileges, it allocated the memory for the new program, read in the program image, set up the Unix-type args, and transferred control to the newly loaded program.
fexecve is just a wrapper of execve using "/proc/self/fd/3" as binary location. (with fd=3 pointing to a mmapped binary)
In 2014 you could still use a tmpfs location exec from it and unlink binary, but it generate a lot of artifacts.
With linux kernel > 3.16 you can use memfd_* syscalls to achieve same thing in cleaner way.
You can look at this rootkit https://github.com/io-tl/degu-lib that uses theses tricks for stealth executions of binaries
I wrote the code because someone asked how to do this and it was easier to implement it than to explain it in detail. The whole thing is based on what I learned from “Linkers & Loaders,” a great book. (I still have my copy)
Later that year I wrote a wrapper around ul_exec() that used an automated interactive session with gdb to load a process, replace it with another binary (delivered over STDIN) and then execute that. This would prevent the binary ever being written to disk.
Remote exec was documented in phrack 62, along with the more advanced theory of counter forensics. Interestingly, the techniques I discussed in rexec() are now common APT tradecraft. Using common tools to limit the chance of detection and reduce evidence, aka living off the land, is now standard practice. I explained why about 20 years ago :)
http://phrack.org/issues/62/8.html
It seems easier to load the whole issue from here: https://www.exploit-db.com/exploits/42873