Cleaning up references

module-stomping/README.md

@@ -247,10 +247,8 @@ The `local-stomp.cpp` example follows this execution logic:
 
 1. **Load Target DLL:** Use `LoadLibraryExA` with the `DONT_RESOLVE_DLL_REFERENCES` flag to map a "sacrificial" DLL into the process without executing its entry point.
 2. **Identify Section:** Lazy locate the `.text` section of the loaded module to ensure the payload is placed in an executable region.
-3. **Reprotect (Write):** Call `VirtualProtect` to change the memory permissions from Read-Execute (`RX`) to Read-Write (`RW`).
-4. **Write Payload:** Use `WriteProcessMemory` or `RtlCopyMemory` to stomp the payload over the legitimate instructions.
-5. **Reprotect (Execute):** Revert the memory permissions back to Read-Execute (`RX`).
-6. **Execution:** Trigger the shellcode using a thread execution API (e.g., `CreateThread` or `CreateRemoteThread`).
+3. **Write Payload:** Use `WriteProcessMemory` or `RtlCopyMemory` to stomp the payload over the legitimate instructions.
+4. **Execution:** Trigger the shellcode using a thread execution API (e.g., `CreateThread` or `CreateRemoteThread`).
 ### Stomping in a Remote Process
 The `remote-stomp.cpp` example follows this execution logic:  
 
@@ -258,9 +256,7 @@ The `remote-stomp.cpp` example follows this execution logic:
 2. **Locate Remote PEB:** Query the target process to find its remote Process Environment Block (PEB) address using internal utility routines.
 3. **Parse Remote Modules:** Walk the remote process's InMemoryOrderModuleList to dynamically locate the base address of a loaded target module (e.g., KERNEL32.dll).
 4. **Identify Section / Export Target:** Verify the boundaries of the executable .text section, and locate a specific target function address (e.g., FileTimeToSystemTime) within that module via manual Export Address Table (EAT) parsing.
-5. **Reprotect (Write):** Call VirtualProtectEx to change the target function's memory permissions in the remote process from Read-Execute (RX) to Read-Write (RW).
 6. **Write Payload:** Use WriteProcessMemory to stomp the shellcode payload directly over the legitimate instructions of the identified remote export.
-7. **Reprotect (Execute):** Revert the remote memory permissions back to Read-Execute (RX) via VirtualProtectEx.
 8. **Execution:** Trigger the payload within the target process context using a remote execution API (e.g., CreateRemoteThread) pointing directly to the stomped function address.
 
 ## OPSEC Considerations
@@ -281,4 +277,4 @@ The use of `VirtualProtect` on an image-backed region is a high-confidence heuri
 ## Indicators of Compromise (IoC)
 * **Memory/Disk Mismatch:** Significant byte differences between the loaded module and its corresponding `C:\Windows\System32\` file.
 * **Suspicious Call Trace:** Thread execution starting from the middle of a DLL's code section rather than a legitimate exported function.
-* **API Pattern:** The sequence of `LoadLibrary` -> `VirtualProtect(RW)` -> `VirtualProtect(RX)` is a classic signature of memory manipulation.
+* **API Pattern:** The sequence of `LoadLibrary` -> `VirtualProtect(RW)` -> `VirtualProtect(RX)` is a classic signature of memory manipulation.

module-stomping/local-stomp.cpp

@@ -2,7 +2,7 @@
 * Local module stomping: load a sacrificial DLL into the process memory, locate a function to stomp (it'll be within the .text section, this is lazy)
 *                        & inject calc.exe msfvenom shellcode into the target buffer, toggling the memory protection between RW and RWX
 * shellcode: msfvenom -p windows/x64/exec CMD=calc.exe -f C EXITFUNC=thread
-* compile: cl.exe local-stomp.cpp /W0 /D"UNICODE" /D"_UNICODE"
+* compile: cl.exe local-stomp.cpp /W0
 */
 #include <windows.h>
 #include <stdio.h>