Guide Anti-Cheat Bypass — KDMapper Driver Integration and SendInput Detection Risks (Ring 3)

[byte_corvus]

If you're still relying on SendInput for your kernel-mode projects, you're practically handing the anti-cheat a golden ticket to your HWID. Fresh off the boards, someone is asking if their KDMapper-loaded driver is safe while still using user-mode input simulation against a Ring3 AC.

The Reality Check:
Just because you loaded your driver via KDMapper doesn't make your entire cheat invisible. You have achieved code execution in kernel space, sure, but your input layer is still sitting in Ring3. Anti-cheats are not stupid; they monitor for the lack of hardware events.

1. The Hooking Problem: SendInput is a standard API call. Even if your process is "hidden" or protected, the OS still logs the origin of the input. Most modern Ring3 anti-cheats check the timestamp and the injection source of the mouse event. If the event doesn't originate from a physical HID device, you're getting flagged for artificial input.
2. The KDMapper Fallacy: KDMapper is widely known and heavily signed-off in detection databases. Loading a driver this way doesn't grant you "invisibility." It just means the AC knows you are running an unsigned driver and is likely already watching your memory handles and overlay hooks.
3. Hardware Alternatives: If you want to bypass the detection of synthetic input, you need to stop using the Windows API entirely. Most serious devs have moved to hardware-level simulation.

What you should be looking at instead:

1. Kmbox/Arduino: Hardware mice that mimic human input at the physical controller level.
2. HID Report Descriptors: Spoofing the mouse as a legitimate HID device so the AC sees physical hardware interrupt signals rather than software API calls.
3. Kernel-level Mouse Emulation: Writing your own mouse class driver to issue packets directly to the bus, which is a massive step up from SendInput.

Spoiler: Technical Context

// Stop relying on this in 2026:
// SendInput(1, &Input, sizeof(INPUT)); 

// Even with a kernel driver, the AC sees this:
// User-mode -> Win32k.sys -> HIDClass.sys
// It's trivial to hook or filter these inputs to see if they are 'synthetic'.

Is this guy just another skid relying on ancient bypass methods, or is there a legitimate dev still trying to make software-only input work? Anyone actually pulling off safe, non-hardware input in the current climate, or is that dream dead?

While skids are getting their main accounts nuked by detected SendInput hooks, the Infocheats community is moving to hardware-level emulation, dominating the lobbies, and keeping their HWID safe.