Although the source code for our code injection doesn't appear really trivial, the code_inject.c source code is a slightly dampened-down version of a real memory infector. I say this because it is limited to injecting position-independent code, and it loads the text and data segments of the payload executable into the same memory region back to back.
If the payload program were to reference any variables in the data segment, they would not work, so in a real scenario, there would have to be proper page alignment between the two segments. In our case, the payload program is very basic and simply writes a string to the terminal's standard output. Also in a real scenario, the attacker generally wants to save the original instruction pointer and registers and then resume execution at that point after the shellcode has been run. In our case, we just let the shellcode print a string and then exit the entire program.
Most hackers inject shared libraries or relocatable code into a process address space. The idea of injecting complex executables into a process address space is a technique that I've not seen before, other than with my own experimentation and implementations.
A good example of injecting complex programs into a process address space can be found in the
elfdemon source code, which allows a user to inject a full dynamically linked executable of the ET_EXEC type into an existing process without overwriting the host program. This task has many challenges and can be found in an experimental project of mine at the following link: