Archived. Extracted from private repos for reference. Written February 2021. No guarantee it compiles or runs on any current version of Windows. Detection status versus modern anti-cheats is unknown.
Kernel-mode cross-process memory read/write via page table entry manipulation. Instead of using MmCopyVirtualMemory or any other documented (or undocumented) API, this walks the page table hierarchy manually using CR3 and performs reads and writes at the physical level.
Part of fightclub, a kernel communication driver from early 2021.
On x64, virtual address translation goes through four levels: PML4, PDPT, PD, and PT. Each level is a table of 512 entries indexed by 9 bits of the virtual address. The bottom 12 bits are the byte offset into the final physical page.
To translate a virtual address in another process, read its DirectoryTableBase (CR3 value, at offset 0x28 in EPROCESS), then walk down:
CR3 -> PML4E (9 bits) -> PDPE (9 bits) -> PDE (9 bits) -> PTE (9 bits) -> physical page
Large pages short-circuit this: a PDPE with LargePage=1 maps 1GB directly, a PDE with LargePage=1 maps 2MB. GetPageTables handles both.
Physical addresses are mapped into kernel virtual address space via MmMapIoSpace for the duration of the read.
The AVL bits in a PTE (bits 9-11) are available for OS/software use. Windows uses bit 9 as a copy-on-write marker. Setting it, invalidating the TLB entry with __invlpg, and atomically swapping the PTE with InterlockedExchange64 causes the next write to the page to produce a private copy. This is the mechanism used here rather than directly patching the write-protect bit, which would be noticed faster.
paging/
pte.h VIRTUAL_ADDRESS, PML4E, PDPE, PDE, PTE union structs (x64 and x86)
pteutils.h PAGE_TABLES_INFO struct, function declarations
pteutils.cpp GetPageTables, TriggerCopyOnWrite, IsPagePresent, IsMemoryRangePresent
Physical memory access via MmMapIoSpace is slow per-call. This was not designed for high-frequency reads. It was a proof of concept for the mechanism, not a production memory-read path.
Detection-wise, the page table walk itself leaves no kernel objects behind. The MmMapIoSpace calls do show up in kernel pool allocations if you are looking hard enough, and the AVL bit manipulation is visible to any hypervisor watching EPT violations or PTE modifications. EAC monitors this. BattlEye was less aggressive about it at the time.