- Status
- Offline
- Joined
- Mar 3, 2026
- Messages
- 271
- Reaction score
- 7
Anyone diving into Rust recoil compensation knows the drill—the game's anti-cheat (EAC) loves to flag poorly implemented input simulation. I've been seeing a lot of talk lately about using SendInput for scripts, and it's time to set the record straight for those of you actually building something functional.
The reality of SendInput:
Honestly, SendInput is the most basic approach and for good reason—it's high-level. While it works for simple key mapping, EAC hooks the input stack and will catch jittery mouse events if you aren't masking them correctly. It's essentially "detected" if your math is too linear or your timings are static.
Better alternatives for long-term reliability:
Preventive measures:
If you're sticking to user-mode for testing, make sure your randomization logic is tight. Static compensation for an AK-47 is an instant behavioral flag. Always ensure you are building against a clean environment and never run these on an account you aren't prepared to lose. If you are going down the kernel route, ensure your driver is properly signed and doesn't trigger a BSOD on boot.
Has anyone here successfully moved their Rust recoil logic from user-mode to a KMBox or a custom driver setup? I'm curious about your experiences with input delay and overall stability.
The reality of SendInput:
Honestly, SendInput is the most basic approach and for good reason—it's high-level. While it works for simple key mapping, EAC hooks the input stack and will catch jittery mouse events if you aren't masking them correctly. It's essentially "detected" if your math is too linear or your timings are static.
Better alternatives for long-term reliability:
- Kernel-level mouse driver hooks: Significantly harder to implement, but bypasses the standard Windows API flags that EAC looks for.
- Custom KMBox hardware: The gold standard for external scripts. Offloading input to a dedicated device makes detection near-impossible since the OS sees a literal human-like USB peripheral.
- Intercept/Raw Input: Bypassing the Win32 message queue entirely is the direction most serious devs are taking now.
Preventive measures:
If you're sticking to user-mode for testing, make sure your randomization logic is tight. Static compensation for an AK-47 is an instant behavioral flag. Always ensure you are building against a clean environment and never run these on an account you aren't prepared to lose. If you are going down the kernel route, ensure your driver is properly signed and doesn't trigger a BSOD on boot.
Has anyone here successfully moved their Rust recoil logic from user-mode to a KMBox or a custom driver setup? I'm curious about your experiences with input delay and overall stability.
