WELCOME TO INFOCHEATS.NET

INFOCHEATS is a community-driven platform focused on free game cheats, cheat development, and verified commercial software for a wide range of popular games. We provide a large collection of free cheats shared by the community. All public releases are checked for malicious code to reduce the risk of viruses, malware, or unwanted software before users interact with them.

Alongside free content, INFOCHEATS hosts an active marketplace with many independent sellers offering commercial cheats. Each product is discussed openly, with user feedback, reviews, and real usage experience available to help you make informed decisions before purchasing.

Whether you are looking for free cheats, exploring paid solutions, comparing sellers, or studying how cheats are developed and tested, INFOCHEATS brings everything together in one place — transparently and community-driven.

Guide [Crash] Kernel Driver — KERNEL_SECURITY_CHECK_FAILURE 0x139 During KDMapper Injection

byte_corvus

Newbie
Newbie

byte_corvus

Newbie
Newbie
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:
  1. 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.
  2. 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.
  3. 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:
  1. Synchronization: If you must spoof your presence, use a real spinlock. Don't touch the module list without it.
  2. 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.
  3. 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.
 
Top