- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 381
- Reaction score
- 7
Been digging into a Valorant external and hitting a machine-specific wall. The setup is standard: signed driver, HVCI and Secure Boot are non-issues, and the base functionality is solid.
On a Windows 11 test bench, everything maps and reads flawlessly. However, moving the build to a Windows 10 environment triggers a persistent failure during the UWorld extraction. Even though the driver confirms it can read the PE header (MZ/PE signatures match), the pointer resolution for the world object returns null or raw addresses that won't dereference.
Swapping to MmCopyMemory(MM_COPY_MEMORY_VIRTUAL) didn't change the outcome. The loader identifies the process and window correctly, and even pulls the base address, but the Guarded Region logic seems to be tripping up on the Win10 box.
The BigPool scan identifies the guarded region, but as soon as the cache thread starts, it hits "Heap unreadable". This usually points to a Directory Table Base (CR3) mismatch or Vanguard's context swapping being handled differently between OS builds. If the driver can read the MZ header but fails on the world pointer, we're likely looking at a failure to attach to the correct process context or a stale CR3.
Anyone else dealt with machine-specific heap unreadability while the driver remains clearly attached and verified?
who's run into this specific CR3 scan fail?
On a Windows 11 test bench, everything maps and reads flawlessly. However, moving the build to a Windows 10 environment triggers a persistent failure during the UWorld extraction. Even though the driver confirms it can read the PE header (MZ/PE signatures match), the pointer resolution for the world object returns null or raw addresses that won't dereference.
Code:
No world. raw=0x182A63F4F00 guarded=0x0
PE Header (expect 0x5A4D 'MZ'): 0x5A4D OK
PE Signature (expect 0x4550 'PE'): 0x00004550 OKSwapping to MmCopyMemory(MM_COPY_MEMORY_VIRTUAL) didn't change the outcome. The loader identifies the process and window correctly, and even pulls the base address, but the Guarded Region logic seems to be tripping up on the Win10 box.
[INFO] Waiting for Valorant...
[OK] Process found! PID: 5844
[OK] BASE: 0x7ff6ead90000
[INFO] Driver read test: MZ=0x5A4D (OK)
[INFO] Checking guarded region...
[INFO] Driver scan failed, trying usermode BigPool scan...
[BIGPOOL] GUARDED: 0xFFFFE0006E740000
[BIGPOOL] GUARDED: 0xFFFFE00068C00000
[OK] Guarded region (usermode): 0xffffe00068c00000
[GW] raw=0x1F28D84EC20 *raw=0xEE7BF41E1E0 gi=0x0 gs=0x0 cr3req=0
[GW] Heap unreadable! Requesting CR3 scan for target=0xEE7BF41E1E0
[OK] Process found! PID: 5844
[OK] BASE: 0x7ff6ead90000
[INFO] Driver read test: MZ=0x5A4D (OK)
[INFO] Checking guarded region...
[INFO] Driver scan failed, trying usermode BigPool scan...
[BIGPOOL] GUARDED: 0xFFFFE0006E740000
[BIGPOOL] GUARDED: 0xFFFFE00068C00000
[OK] Guarded region (usermode): 0xffffe00068c00000
[GW] raw=0x1F28D84EC20 *raw=0xEE7BF41E1E0 gi=0x0 gs=0x0 cr3req=0
[GW] Heap unreadable! Requesting CR3 scan for target=0xEE7BF41E1E0
The BigPool scan identifies the guarded region, but as soon as the cache thread starts, it hits "Heap unreadable". This usually points to a Directory Table Base (CR3) mismatch or Vanguard's context swapping being handled differently between OS builds. If the driver can read the MZ header but fails on the world pointer, we're likely looking at a failure to attach to the correct process context or a stale CR3.
- Verify if the Win10 machine has specific KVA shadowing or VBS settings interfering with the BigPool results.
- Check if the guarded region offset is actually valid for that specific game build/OS combo.
- Manual CR3 walk might be necessary if the kernel-level attach is failing silently.
Anyone else dealt with machine-specific heap unreadability while the driver remains clearly attached and verified?
who's run into this specific CR3 scan fail?
