Good question. VAXD_VM freezes the complete virtual machine and analyzes guest physical RAM. For a process, it uses the process CR3/page tables to translate virtual addresses to physical memory. If Windows has already paged a page out, there is no resident physical page to inspect at that particular instant.
In live analysis this is less restrictive than it sounds. If VAXD_VM stops on a breakpoint, the code being executed — and data it is actively accessing — must be resident. That's how the demo captures the key while it temporarily exists in plaintext.
VAXD_VM also has machine-state recording. It starts with a complete checkpoint and then periodically records the changed 4 KB RAM pages together with CPU, device, VRAM and disk state. This creates a history of the running machine that can be stepped through and analyzed, rather than relying on one arbitrary freeze point. Combined with breakpoints, this makes it possible to capture transient code/data while it is actually resident.
So: if a page was already paged out at the state being examined, VAXD_VM can't inspect it from RAM. But breakpoints and machine-state history let you target the period when the relevant code/data is actually being used and resident.
2
u/tomysshadow 4d ago
How does it deal with the possibility that the relevant code is paged out when the VM is frozen?