The kernel boundary also determines how devices reach memory. A process sees virtual addresses; a device moves bytes through a physical-memory path with its own mappings and access permissions. Understanding both maps makes an offline capture interpretable without assuming that a game address is a R A M, random access memory, offset.
Section: D M A is a way devices move data.
D M A means direct memory access. A capable device can transfer data without asking the C P U, central processing unit, to copy each byte. Storage, networking, graphics, and other high-throughput devices use D M A because involving the C P U in every tiny move would waste time.
Here D M A refers to device transfers. It is different from dynamically allocating memory in a program, where the program asks its allocator for space and receives an address. The shared word memory does not make those the same operation.
D M A is not automatically a cheat or an attack. It is a hardware feature. Security problems appear when a device can reach memory it should not reach, or when software trusts a device too much.
This chapter uses ordinary offline capture files from an owned machine, virtual machine, or synthetic test. It does not configure D M A hardware, install a kernel driver, disable an IOMMU, access a live game, or bypass anti-cheat.
Section: Physical and virtual addresses are different maps.
A C P U process usually uses virtual addresses. The memory-management unit translates them through page tables to physical addresses in R A M.
In brief: A process virtual address, a physical R A M address, and a device mapping belong to different address spaces.
Treat translation as a function with an address-space input:
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
That describes the C P U’s complete decision. The small offline walker in Lesson 13.2 answers a narrower question: where do the recorded, present entries lead? It checks presence and file bounds but does not emulate every read, write, execute, and user/supervisor permission check the C P U would make. A physical result alone is therefore not proof that a live process could read or write the address.
Two processes may both use virtual address hexadecimal 1 0 0 0 because they supply different page-table roots. The access type matters too: a mapping may permit a read but reject a write or instruction fetch. A virtual address by itself therefore does not name a location: the address space and the mapping’s permissions are part of its meaning.
It is like asking for apartment 1000 without naming the building. The apartment number is useful only after the building is chosen; likewise, hexadecimal 1 0 0 0 is useful only with the correct page-table root. The analogy is limited: page tables can remap or remove a page while a program runs, and they separately record whether a read, write, or instruction fetch is allowed. The diagram below shows the same virtual number reaching two different physical places.
An offline physical capture contains bytes arranged by physical address. A debugger’s pointer such as this value is virtual. To connect them, the reader needs the correct page-table root for that address space.
The idea transfers to a guest virtual machine in Lesson 13.3: a guest’s virtual address first needs its guest page tables, and the resulting guest physical address needs a second translation through the hypervisor’s map. Neither stage can be skipped just because both addresses are written as numbers.
Section: Place the virtual address inside a process map.
Before translating one page, identify the architecture and address-space configuration. Microsoft’s default 32-bit Windows map gives a 32-bit process on 32-bit Windows a lower 2 GiB user range (this value–this value) and an upper 2 GiB system range (this value–this value). Those are address ranges, not amounts of installed or resident R A M. Modules, heaps, stacks, mapped files, and free holes occupy parts of the user range rather than filling it uniformly.
A S L R, address space layout randomization, and allocation history can move those user regions; Microsoft describes the image-randomization behavior under DYNAMICBASE. The limits table also gives the exceptions: 4GT plus a large-address-aware image can extend a 32-bit process to 3 GiB on 32-bit Windows; on 64-bit Windows, a large-address-aware 32-bit process can have 4 GiB. A native 64-bit process has a different map. Do not apply the diagram’s split to this lesson’s x86-64 capture merely because both use Windows.
In brief: A legal address range can contain unmapped holes. The range tells you where an address could fit; the current page tables tell you whether an access can work.
Section: Segmentation and paging are different stages.
A simplified upward-growing segment has a base and an inclusive limit. For a one-byte access, check the offset against the limit, then add it to the base to form a linear address. Paging divides that linear address space into fixed-size pages and maps each page to a physical frame, with access permissions. Adjacent virtual pages need not reach adjacent physical frames.
Intel’s memory-management guide describes how the mechanisms combine. Windows normally uses a flat application address model rather than separate variable-size application segments; Microsoft’s x86 overview states that model. Page tables supply the process mappings and page permissions. In 64-bit mode, most traditional segment bases are ignored, while FS/GS still have special uses. A segment register is therefore not an alternative process page table. The next section follows the paging structures used by the capture.
Section: c r 3 points to the first translation table.
On ordinary x86-64 systems using four-level paging, the C P U’s c r 3 register identifies the physical base of the top table. The virtual address supplies four nine-bit indices and a twelve-bit offset:
Each table has 512 eight-byte entries. A normal translation reads one entry at each level, checks its present bit, takes the next table’s physical address, and finally adds the page offset.
Large pages can finish earlier: a page-directory-pointer entry may map 1 GiB, and a page-directory entry may map 2 MiB.
Section: Canonical addresses catch bad input early.
With the common 48-bit virtual-address form, bits 63–48 must repeat bit 47. An address that breaks this rule is noncanonical. The lab rejects it before reading the capture:
Optional: practise the sign-extension check for this four-level, 48-bit address model.
Code example. The surrounding prose explains this example; the full lesson contains the exact code.
Rejecting impossible input gives a clearer error than following nonsense offsets into a file.
Section: An IOMMU gives devices their own map.
An IOMMU is an input/output memory management unit. It does for devices what the page tables above do for processes: it sits between a device and physical memory and translates the addresses the device asks for, so the operating system can limit a device to approved physical regions instead of letting it reach all R A M.
Alternative: An IOMMU supplies a device’s approved map, just as C P U page tables supply a process’s map; neither address should be assumed to name unrestricted R A M.
Windows exposes protections including Kernel D M A Protection on supported hardware. Microsoft explains that it uses the IOMMU to isolate capable peripherals and protect against malicious D M A devices. Read the current Microsoft overview for requirements and behavior.
If a protected machine blocks D M A, that is the system working correctly. Keep the protections enabled and use the synthetic capture created by the tests or an offline hypervisor capture.
Section: A capture is a snapshot, not a live process.
An offline image has important limits:
threads do not run while you inspect it;
pages may have changed immediately after capture;
some virtual pages may be absent, swapped, compressed, or intentionally omitted;
you need the correct c r 3 and architecture details;
device memory and C P U caches may not be represented;
the capture may contain private data unrelated to the lesson.
A capture holds whatever was in R A M, including private data unrelated to the lesson, so it is stored securely and deleted when the lab no longer needs it. It also cannot be interpreted on its own. Its origin, capture time, build, architecture, capture method, and a cryptographic hash travel with the file, because a c r 3 value or a structure layout means something only for the machine state it came from, and the hash is what shows the bytes have not changed since.
Narration: A saved c r 3 and object layout are meaningful only beside the capture they describe. Mixing records from different moments can produce a convincing but wrong result.
Section: What “using D M A” means in this book.
The useful computer-science problem is translating and validating captured memory. The complete implementation:
opens a normal file read-only;
accepts a physical c r 3 value and virtual address;
walks x86-64 page tables inside that file;
checks present bits and bounds;
supports 4 KiB, 2 MiB, and 1 GiB mappings while leaving live C P U access permissions as a separate question;
prints a bounded hexdump.
No hardware-specific SDK is needed. This keeps the lesson reproducible and focuses attention on address translation rather than stealth, firmware, or bypasses.
For the exact paging bit definitions, use the current Intel Software Developer Manuals as the primary architecture reference.