The Single-Primitive Write: WriteProcessMemory’s Hidden Page Flip

Documenting Undocumented WriteProcessMemory Behavior

In offensive Windows tradecraft, we are taught to treat memory protections as absolute boundaries. When developing local loaders or manipulating memory regions, we meticulously track page states. If we need to modify a region that is currently marked as read-only (PAGE_READONLY) or execute-read (PAGE_EXECUTE_READ), our immediate reflex is to explicitly fluctuate the permissions using VirtualProtect or its native equivalent, NtProtectVirtualMemory.

We do this because documentation dictates that attempting to write directly to non-writable space will result in an access violation.

But Windows documentation often obscures kernel-mode reality. As it turns out, WriteProcessMemory is perfectly capable of handling the permission flip for you. By understanding the implicit behavior of the underlying API, we can avoid the need to explicitly toggle user-mode protection.

WriteProcessMemory: Under the Hood

Automated NtProtect Toggling

The MSDN documentation for WriteProcessMemory (WPM) states that the function copies data into a specified process's memory space, but it stays quiet about permission management. The standard assumption is that if the page permissions don't explicitly permit writing, the API should fail.

[1] MSDN: WriteProcessMemory API Documentation

In practice, the heavy lifting is passed down to NtWriteVirtualMemory. When the kernel services this request against a non-writable page:

• The Kernel Intercepts: Instead of immediately failing the operation with an access violation, the kernel verifies handle rights and checks the target page.
• The Page Flip: It temporarily forces the write bit on the target pages, copies the data buffer, and seamlessly restores the original protection state — all without requiring an explicit VirtualProtect invocation from user-mode.

As Microsoft developer Raymond Chen famously noted in The Old New Thing, this design choice stems from the API’s primary audience: debuggers. When a debugger needs to patch memory to set an INT 3 breakpoint or handle edit-and-continue modifications, forcing an operator to juggle page permissions manually adds unnecessary overhead. WPM tried to be helpful by handling that transition transparently behind the scenes.

[2] How is it that WriteProcessMemory succeeds in writing to read-only memory? — Raymond Chen (The Old New Thing)

💡 Architectural Note: Under the hood, the kernel is essentially performing an implicit NtProtectVirtualMemory loop on your behalf. The permission modification still occurs; it is simply abstracted away from the user-mode code.

For example, consider the following test case. Allocating a region straight to PAGE_EXECUTE_READ and issuing a write immediately afterward is completely valid and fully functional:

[wpm-example.cpp](https://github.com/toneillcodes/windows-process-injection/blob/main/snippets/wpm-example.cpp)

#include <windows.h>
#include <stdio.h>

int main() {
    // Example payload buffer
    unsigned char buf[] = "\x90\x90\x90\x90"; 
    HANDLE pHandle = GetCurrentProcess();
    // 1. Allocate straight to RX space. No RWX, no explicit RW transition.
    LPVOID bufferAddress = VirtualAlloc(NULL, sizeof buf, (MEM_COMMIT | MEM_RESERVE), PAGE_EXECUTE_READ);
    if (!bufferAddress) {
        printf("[ERROR] Allocation failed. Error: %lu\n", GetLastError());
        return -1;
    }
    printf("[*] Memory allocated as RX at: 0x%p\n", bufferAddress);
    // 2. The documentation implies this should fail. The kernel says otherwise.
    // NOTE: This internal permission flip is still a visible event to kernel telemetry!
    BOOL writeShellcode = WriteProcessMemory(pHandle, bufferAddress, buf, sizeof buf, NULL);
    if (!writeShellcode) {
        printf("[ERROR] Write failed. Error: %lu\n", GetLastError());
        VirtualFree(bufferAddress, 0, MEM_RELEASE);
        return -1;
    }
    printf("[+] Successfully wrote to RX memory without calling VirtualProtect.\n");
    return 0;
}

Executing wpm-example.cpp

c:\Users\Administrator\Desktop>cl.exe wpm-example.cpp /nologo
example.cpp

c:\Users\Administrator\Desktop>

c:\Users\Administrator\Desktop>wpm-example.exe
[*] Memory allocated as RX at: 0x00000287BC670000
[+] Successfully wrote to RX memory without calling VirtualProtect.

c:\Users\Administrator\Desktop>

The Operational Caveat

The Signature Changes, The Signal Remains

To be clear: allocating a raw private memory region straight to PAGE_EXECUTE_READ and writing to it this way is poor OPSEC if your goal is evasion.

Leaving an unbacked, private memory region as RX creates a glaring memory anomaly that any mature memory scanner will catch during a routine sweep.

The value of this snippet isn’t that you should use it to stage raw payloads into private allocations. The value is what it teaches us about the underlying API’s implicit behavior.

In part two of this series, we will look at how to leverage this quirk to eliminate noise in module-stomping workflows.

Conclusion

For offensive practitioners, understanding the delta between documented Win32 behavior and actual kernel execution allows us to strip unnecessary assumptions out of our tradecraft. While the documentation implies a rigid boundary that requires manual intervention, the reality is that the OS is designed to be helpful, executing complex, automated operations right beneath our user-mode threads.

Relying on WriteProcessMemory to implicitly handle permissions highlights the danger of building detections around assumed user-mode sequences. When a behavioral signature expects an explicit VirtualProtect call to precede a cross-process or local write, it creates a blind spot out of a documentation technicality. For defenders, this reinforces the idea that monitoring must decouple from user-mode sequence expectations and anchor itself directly to the kernel choke points where the physical memory transition actually occurs.

Now that we understand the raw mechanics of this implicit page flip, we can begin applying it to practical tradecraft. In part two of this series, we will look at how moving this exact trick away from raw allocations and toward existing file-backed memory allows us to strip the noise from precision module-stomping workflows.

References

[1] MSDN: WriteProcessMemory API Documentation https://learn.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-writeprocessmemory

[2] How is it that WriteProcessMemory succeeds in writing to read-only memory? — Raymond Chen (The Old New Thing) https://devblogs.microsoft.com/oldnewthing/20181206-00/?p=100415

Windows Process Injection Repository https://github.com/toneillcodes/windows-process-injection

wpm-example.cpp https://github.com/toneillcodes/windows-process-injection/blob/main/snippets/wpm-example.cpp