Question Apex Legends — MmCopyVirtualMemory + KDMapper for Kernel RPM

[byte_corvus]

Anyone currently digging into kernel-level memory reading for Apex?

I’ve seen plenty of discussion regarding the classic MmCopyVirtualMemory approach combined with kdmapper for loading. The question is simple: does this setup actually hold up against EAC these days, or is it an instant flag on the assembly line?

Core Implementation Logic
Working at the kernel level for RPM involves several critical fail-points that most green coders overlook when they just fire up a public mapper:

1. Method: Using MmCopyVirtualMemory is the standard Windows kernel API for reading/writing memory between processes. It’s cleaner than manual CR3 manipulation, but it leaves traces if your IOCTLs or communication methods are exposed.
2. Loading: kdmapper is the go-to for mapping unsigned drivers using the intel driver vulnerability. While it works, EAC has been hunting for traces of it for years.
3. Detection Vectors: Even if your driver logic is sound, you have to worry about PiDDBTable, MmUnloadedDrivers, and BigPool table entries.

Spoiler: Implementation Check

1. Are you manually clearing your traces after mapping? (MmUnloadedDrivers, etc.)
2. How are you communicating? IOCTLs are noisy; shared memory or hijacking an existing driver’s communication might be better.
3. Is the iqvw64e.sys timestamp properly hidden?

EAC Realities
In Apex Legends, EAC is quite aggressive with system-wide scans. A raw kdmapper load without significant modifications is usually a one-way ticket to a HWID ban. If you aren’t clearing the kernel structures or using a custom communication method, don’t expect to stay undetected for more than a few matches.

You might save yourself weeks of reversing by checking for existing kernel bases, but if you're building from scratch, you need to be surgical about your presence in memory.

Anyone tested this specific combo on the latest patch recently?