Observation

It is based on the same principle behind Reflective DLL Injection, except we are loading our own shellcode, which in itself acts as a loader for the DLL appended to our shellcode.

  • We don’t need to use CreateFile to read our DLL byte by byte from disk, because it is in-memory, appended to our loader’s shellcode.
  • The loader shellcode is an in-memory PE loader like in Reflective DLL Injection (PE headers, sections, entry point) and executes functions exported by our DLL. The whole thing is just this huge shellcode that will be stored somewhere in the PE file, and we only need to execute it from somewhere.

Working

Here is an example

In the example, the shellcode is placed in the resource section. We can theoretically place it in any section, or can have it written anywhere in the memory of a process.

Preliminaries

Lets try to understand what happened here.

Looking at the python or powershell script that is responsible to convert the DLL to shellcode, we find that it arranges all the instructions in the following manner:

return bootstrap + rdiShellcode + dllBytes + userData

Lets break down each part

  • bootstrap: What it really does is setup locations of rdishellcode, dllBytes and userData so that it can be flawlessly referenced throughout the execution of the shellcode.
  • rdiShellcode: These are the instructions which will reflectively load the DLL into the process like in Reflective DLL Injection.
  • dllBytes: This is your DLL that you passed to the script and is stored byte by byte, which will be reflectively loaded by rdiShellcode.
  • userData: This is optional, and by default is set to “None”.