- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 122
- Reaction score
- 7
Boys, I need some eyes on a persistent issue with my AMD SVM hypervisor build.
I am hitting a brick wall regarding CR3 resolution. Ever since EAC started heavy CR3 poisoning, my standard EPROCESS scan approach is returning garbage. When I pull from EPROCESS.DirectoryTableBase (+0x028) or the UserDirectoryTableBase (+0x390), I am consistently getting 0x40000004088ff000. It is obvious the protection is active, and any attempt to read the PE header at the section base (0xe825834000) just results in 0 bytes, triggering the 0xeeee0001 (VA not present) error.
Here is what I have already cycled through:
I am at the point where I suspect they are utilizing a more complex translation layer that invalidates standard PT walking if it detects the hypervisor's access pattern. I have seen some chatter about hardware-assisted page walking or potentially hooking the CR3 load instructions within the guest, but I am trying to avoid a full-blown modification of the guest state to keep the footprint minimal.
Has anyone here managed to bypass the CR3 poisoning on current builds? Are you guys still relying on standard EPROCESS structures, or have you moved to tracking the process through different kernel objects that aren't getting zeroed out?
If anyone has a lead on how to resolve the VA to physical address mapping when the directory base is intentionally corrupted, drop a hint below. I am stuck in a loop trying to verify the page tables and could use a second set of eyes on this logic.
I am hitting a brick wall regarding CR3 resolution. Ever since EAC started heavy CR3 poisoning, my standard EPROCESS scan approach is returning garbage. When I pull from EPROCESS.DirectoryTableBase (+0x028) or the UserDirectoryTableBase (+0x390), I am consistently getting 0x40000004088ff000. It is obvious the protection is active, and any attempt to read the PE header at the section base (0xe825834000) just results in 0 bytes, triggering the 0xeeee0001 (VA not present) error.
Here is what I have already cycled through:
- Physical Brute-Force: Scanned potential CR3 candidates across the physical memory range, but nothing yielded a valid page table structure that maps to the process space correctly.
- VMEXIT Sniffer: Ran a passive monitor to catch transitions, but the overhead and the way EAC handles the context switching here makes it difficult to isolate the legitimate base.
I am at the point where I suspect they are utilizing a more complex translation layer that invalidates standard PT walking if it detects the hypervisor's access pattern. I have seen some chatter about hardware-assisted page walking or potentially hooking the CR3 load instructions within the guest, but I am trying to avoid a full-blown modification of the guest state to keep the footprint minimal.
Has anyone here managed to bypass the CR3 poisoning on current builds? Are you guys still relying on standard EPROCESS structures, or have you moved to tracking the process through different kernel objects that aren't getting zeroed out?
If anyone has a lead on how to resolve the VA to physical address mapping when the directory base is intentionally corrupted, drop a hint below. I am stuck in a loop trying to verify the page tables and could use a second set of eyes on this logic.
