- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 85
- Reaction score
- 7
If you are still getting KERNEL_SECURITY_CHECK_FAILURE (0x139) every time you trigger the mapper, stop treating your kernel like a playground. You are getting nuked because you are trying to register callbacks while your driver has no legitimate backing in the system module list. Anti-cheats like EAC/BattlEye have been checking `PsLoadedModuleList` and integrity validation for ages; faking a list entry and unlinking it immediately is a amateur move that triggers a bug check the moment the kernel tries to verify your stack.
The Breakdown:
What to look at:
Advice: Ditch the "unlink and pray" strategy. Modern ACs perform periodic integrity checks on the module list and will detect your driver's absence even if you successfully bypass the initial registration. If you want to stay UD, look into mapping into existing, legitimate driver memory or move to a proper DMA setup.
Stop pasting random snippets you found on some other board and start debugging your memory ranges. While skids are getting their main accounts nuked by BSODs and detected syscall hooks, the Infocheats community is focusing on legitimate memory mapping and keeping their HWID clean.
The Breakdown:
- The Crash: Your `0x139` is likely occurring because `ObRegisterCallbacks` is performing a security check on the caller. If your driver isn't properly registered or the memory is marked as executable but not backed by a proper file object, the kernel will panic the system to prevent a potential exploit.
- The Fake Entry: Your manual linking/unlinking logic is flawed. You are modifying the `PsLoadedModuleList` without acquiring the proper locks (`PsLoadedModuleResource`). Modifying a linked list at IRQL PASSIVE_LEVEL without synchronization while the kernel is potentially traversing it for other tasks is a one-way ticket to a BSOD.
- The Altitude: Using `321000` for an altitude is standard, but you are not handling the return status of `ObRegisterCallbacks` with any actual robustness. If that call fails, you are still proceeding to create a thread, which creates an unstable state.
What to look at:
- Synchronization: If you must spoof your presence, use a real spinlock. Don't touch the module list without it.
- Memory Attributes: Ensure your `kdmapper` isn't setting memory pages incorrectly. If the pages holding your `DriverEntry` or callback functions aren't aligned with `PAGE_SIZE` or have improper permissions, you are getting caught by DEP/NX checks.
- Stack Alignment: Ensure you aren't leaking handles. Your communication thread is spawning without verifying if the system is ready to host a worker thread in that context.
Advice: Ditch the "unlink and pray" strategy. Modern ACs perform periodic integrity checks on the module list and will detect your driver's absence even if you successfully bypass the initial registration. If you want to stay UD, look into mapping into existing, legitimate driver memory or move to a proper DMA setup.
Stop pasting random snippets you found on some other board and start debugging your memory ranges. While skids are getting their main accounts nuked by BSODs and detected syscall hooks, the Infocheats community is focusing on legitimate memory mapping and keeping their HWID clean.