- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 381
- Reaction score
- 7
Been digging into kernel loading methods lately and the results between standard manual mapping and DSE patching with NtLoadDriver are interesting, to say the least. Most people just grab kdmapper and call it a day, but that's a one-way ticket to a delayed ban on any decent anti-cheat (EAC/BE) if you aren't careful.
I've been comparing two specific approaches. The first is the classic Manual Mapper (pool/MDL style) which handles ExAllocatePool, resolves imports, and calls the entry point manually. The second is a DSE Bypass that patches CiValidateImageHeader in SeCiCallbacks, uses NtLoadDriver normally, and then restores the pointers. For the kernel R/W primitive, I used gdrv.sys (Gigabyte).
The Manual Mapping Headache
While it's the "standard" for many, the detection vectors are piling up:
DSE Bypass + NtLoadDriver Approach
This feels way more robust for long-term stability. Because you're using the native loader, the driver gets a legitimate entry in PsLoadedModuleList and a proper DRIVER_OBJECT.
In my tests, the DSE method is holding up significantly better. It seems that being "visible" in the module list with a valid backing is actually safer than hiding in pool memory where every stack trace looks suspicious. Even though I'm spoofing, the manual mapper still caught a hit while the DSE method stayed clean.
Anyone else moved away from pool-based mapping? Curious if anyone is seeing ACs actively integrity-checking SeCiCallbacks during the load window or if there's a better way to handle the callback restoration.
who's run this DSE setup lately?
I've been comparing two specific approaches. The first is the classic Manual Mapper (pool/MDL style) which handles ExAllocatePool, resolves imports, and calls the entry point manually. The second is a DSE Bypass that patches CiValidateImageHeader in SeCiCallbacks, uses NtLoadDriver normally, and then restores the pointers. For the kernel R/W primitive, I used gdrv.sys (Gigabyte).
The Manual Mapping Headache
While it's the "standard" for many, the detection vectors are piling up:
- Code lives in pool memory with no backing module on disk.
- NMI (Non-Maskable Interrupt) stackwalks catch the driver if it's running when the interrupt fires.
- Hooked API calls return to addresses that don't resolve to any known module.
- BigPoolTable entries are a massive giveaway for anyone looking.
DSE Bypass + NtLoadDriver Approach
This feels way more robust for long-term stability. Because you're using the native loader, the driver gets a legitimate entry in PsLoadedModuleList and a proper DRIVER_OBJECT.
- Stack traces resolve cleanly because the code is in a recognized module.
- NMI stackwalks don't flag the execution since it looks like a signed/legit driver (after the DSE check is bypassed).
- The SeCiCallbacks patch only exists for a few milliseconds during the actual load, then it's restored.
- The primary detection vector is just whitelisting or PsSetLoadImageNotifyRoutine at the exact moment of loading.
In my tests, the DSE method is holding up significantly better. It seems that being "visible" in the module list with a valid backing is actually safer than hiding in pool memory where every stack trace looks suspicious. Even though I'm spoofing, the manual mapper still caught a hit while the DSE method stayed clean.
Anyone else moved away from pool-based mapping? Curious if anyone is seeing ACs actively integrity-checking SeCiCallbacks during the load window or if there's a better way to handle the callback restoration.
who's run this DSE setup lately?
