Great question—you’re right that while this feels like a black box to many developers, it’s absolutely feasible to distinguish between real user clicks and those generated by SendInput or SendMessage, and that’s exactly what most anti-bot systems in games rely on. Let’s break down how this works, with practical, actionable methods:

Core Differences to Exploit #

First, it helps to understand why simulated clicks leave detectable traces:

• SendInput injects synthetic input into Windows’ system input queue, but Windows explicitly marks these events as non-hardware-generated.
• SendMessage skips the input queue entirely and directly delivers click messages to a window, creating an event flow that’s fundamentally different from real mouse input.

Practical Detection Techniques #

1. Check for Injected Input Flags #

Windows provides built-in markers for synthetic events. Here’s how to access them:

• Low-level mouse hooks: Use SetWindowsHookEx with WH_MOUSE_LL to intercept mouse events before they reach your window. The MSLLHOOKSTRUCT structure’s flags field will include LLMHF_INJECTED (0x00000001) or LLMHF_LOWER_IL_INJECTED (0x00000002) if the event came from SendInput or another injected source.
• Window message handling: For messages like WM_LBUTTONDOWN, call GetMessageExtraInfo()—the high-order bit of the returned value indicates if the message originated from synthetic input (like SendInput). For SendMessage-generated clicks, this extra context won’t exist at all, since the message bypassed the input queue.

2. Analyze Event Sequence & Timing #

Real human clicks don’t happen in a vacuum—they’re preceded by natural mouse movement with jitter, variable speed, and small overcorrections. Bots using SendInput/SendMessage often:

• Jump directly to a target coordinate and click instantly (no prior WM_MOUSEMOVE events).
• Have perfectly consistent click intervals (no human-like variation in reaction time).
• Lack the minor, random movement jitter that real hardware mice produce.

Track the history of mouse events leading up to a click; if the sequence feels unnatural or missing key context, it’s likely a simulation.

3. Distinguish SendMessage from Queue-Based Input #

SendMessage delivers messages synchronously, skipping the system input queue entirely. This means:

• No associated WM_MOUSEMOVE or WM_MOUSEHOVER events will be present in the queue before the click (unless the bot explicitly sends those too, which adds significant complexity).
• The message won’t carry the same input context as real clicks. For example, you can verify if a message was posted to the queue (via PostMessage) or sent directly—queue-based messages are far more likely to be real user input.

4. Hardware-Level Verification (Advanced) #

Top-tier game anti-cheats go a step further by checking input directly from the mouse driver, bypassing the Windows input stack entirely. This can detect even sophisticated bots that mimic synthetic input flags, but it requires low-level driver access and is overkill for most applications.

Limitations & Caveats #

• Legitimate Synthetic Inputs: Accessibility tools (like screen readers or voice control) also use SendInput—you’ll need to avoid flagging these. Whitelist known accessibility processes or add user-configurable exceptions to prevent false positives.
• Advanced Bots: Some sophisticated bots mimic natural timing and movement, or use kernel-level injection to bypass user-mode checks. But for most use cases, the methods above will catch the vast majority of basic to moderate simulations.

To answer your core question: Yes, detecting clicks generated by SendInput or SendMessage is absolutely feasible, and these techniques are exactly what games use to block bots without disrupting real user experience.

Content from Stack Exchange, author Steve