Page Protection

PAGE_* constants, DEP/NX enforcement, guard pages for stack growth, VirtualProtect for shellcode staging, and Control-flow Enforcement Technology as the modern defense

PAGE_* Protection Constants

Modifier flags (ORed with a base constant):

• PAGE_GUARD (0x100): Guard page — triggers a STATUS_GUARD_PAGE exception on first access, then the guard is removed
• PAGE_NOCACHE (0x200): Disable CPU cache for this page (hardware I/O mapping)
• PAGE_WRITECOMBINE (0x400): Write-combining (GPU/video memory optimization)

Data Execution Prevention (DEP / NX)

DEP (Data Execution Prevention) is a hardware-enforced security feature that marks memory pages as either executable or non-executable — but not both — at the CPU level. The x86-64 CPU implements this via the NX (No-Execute) bit in page table entries. When a CPU attempts to execute code from a page with the NX bit set, it generates a protection fault.

On 64-bit Windows, DEP is always enabled for 64-bit processes. For 32-bit processes (WOW64), it's enforced when the executable is compiled with /NXCOMPAT (sets NXCOMPAT in DllCharacteristics) or when the system policy forces it.

DEP prevents: executing shellcode in the heap, stack, or other data regions. It does not prevent ROP (Return-Oriented Programming), where the attacker chains together existing executable code gadgets to achieve arbitrary computation without injecting new code.

Guard Pages

Guard pages (PAGE_GUARD) serve as memory tripwires. When any access (read or write) touches a guard page, Windows raises a STATUS_GUARD_PAGE_VIOLATION (first-chance) exception. After the exception is delivered, the guard attribute is automatically removed from the page — it fires only once per access.

Windows uses guard pages for automatic stack growth: the committed stack portion has a single guard page at its lower boundary. When the stack grows into the guard page, the exception handler maps one more page, moves the guard page down, and resumes execution — transparent stack expansion without reserving all memory upfront.

VirtualProtect — Changing Page Permissions

VirtualProtect (or VirtualProtectEx for remote processes) changes the protection flags on a committed region of virtual memory:

// Classic shellcode staging pattern (detected by most EDRs)
void* pMem = VirtualAlloc(NULL, shellcodeLen, MEM_COMMIT | MEM_RESERVE,
                              PAGE_READWRITE);   // Step 1: alloc as RW

memcpy(pMem, shellcode, shellcodeLen);          // Step 2: write shellcode

DWORD oldProt;
VirtualProtect(pMem, shellcodeLen,
               PAGE_EXECUTE_READ, &oldProt);    // Step 3: flip to RX

((void(*)())pMem)();                            // Step 4: execute

// Detection: VirtualProtect call that changes a private region
// from non-executable to executable. ETW captures this.
// oldProt contains the previous protection for rollback.

Protection Change as Detection Signal

The pattern VirtualAlloc(RW) → write → VirtualProtect(RX) is the canonical shellcode execution pattern, and it's well-monitored:

Evasion attempts: allocate directly as PAGE_EXECUTE_READWRITE (RWX) — skips the flip but a single RWX allocation is an even bigger red flag. Or use MapViewOfFile from a section object — may show as MEM_MAPPED instead of MEM_PRIVATE, reducing suspicion in some scanners.

CET — Control-flow Enforcement Technology

Intel CET (available from Ice Lake CPUs, Windows 10 20H1+) adds hardware enforcement of return addresses through a shadow stack. Every CALL instruction pushes the return address onto both the regular stack (RSP) and a separate, hardware-protected shadow stack (SSP). The shadow stack is read-only from user mode — software cannot modify it. When a RET instruction executes, the CPU compares the return address on the regular stack against the shadow stack. A mismatch triggers a control protection fault.

CET defeats ROP attacks that overwrite return addresses on the stack — the shadow stack still has the correct return address, and the tampered regular stack return address is caught. Malware targeting CET-enabled processes must use forward-edge control-flow techniques (indirect CALL/JMP), which Control Flow Guard already restricts.

Detecting Protection Abuse

import ctypes, struct

def find_rwx_regions(pid: int):
    k32 = ctypes.WinDLL("kernel32")
    hProc = k32.OpenProcess(0x1FFFFF, False, pid)
    MBI_SIZE = 48
    addr = 0
    suspicious = []
    while addr < 0x7FFFFFFFFFFF:
        mbi = ctypes.create_string_buffer(MBI_SIZE)
        if k32.VirtualQueryEx(hProc, addr, mbi, MBI_SIZE) != MBI_SIZE:
            break
        base, _, _, region_size, state, protect, mem_type = \
            struct.unpack_from("QQIIIII", mbi.raw)
        if state == 0x1000:  # MEM_COMMIT
            if protect == 0x40 and mem_type == 0x20000:  # RWX + PRIVATE
                suspicious.append(f"RWX private region at {hex(base)} size={hex(region_size)}")
        addr = base + region_size
    k32.CloseHandle(hProc)
    return suspicious

Q & A