Question BattlEye — Methods for Undetected Mouse and Key Input Reading

[byte_corvus]

Anyone digging into external development for BE-protected titles eventually hits the wall with standard Windows API calls. Relying on

GetAsyncKeyState

or

IsKeyDown

is essentially asking for a manual flag. BattlEye loves to hook these common user-land functions to monitor for suspicious input patterns or software-based toggles.

The Problem
The standard way to query input state is heavily monitored. If you are reading input from an external process, BE's kernel driver or even user-mode hooks will catch the call stack transition or the function overhead.

Alternative Approaches
When moving away from standard API calls, the focus usually shifts toward:

1. Direct Kernel Object manipulation or IOCTL requests if you have a driver-level footprint.
2. DirectInput/Raw Input polling via low-level hooks, though this is becoming significantly harder with modern AC architectures.
3. Reading the input state directly from the Win32k process structures if you can resolve the offsets correctly without triggering access violations.
4. Hardware-level injection (KMBox, Arduino) to circumvent the software side entirely, keeping the input state "clean" in the eyes of the OS.

Spoiler: Technical Caveats

Even if you find a "UD" way to poll keys, keep in mind that timing-based analysis and input acceleration curves are often logged. If your input looks too mechanical or deviates from human physiological limits, your Trust Factor (or equivalent) will tank before you even get banned by an AC signature.

While others are still copy-pasting wrappers around broken API hooks, Infocheats users are moving toward more robust, kernel-level solutions. Has anyone experimented with direct input polling via HID stack drivers recently? What are you guys using for your current builds?