Still on the topic of cheating and as a follow up on my last post in this community, I will try to explain one of the alternatives I used, and that you can also try, to avoid using tools that simulate mouse clicks or keyboard keystrokes.

What is it?

These tools that simulate Input events are usually used to create Bots, where the tool will repeat a user-defined input pattern (mouse or keyboard) without having a "real" interaction with the application, e.g., the tool will simulate behavior as if a person is in charge.

Alright, but where does the user use this type of tool? It is very common to use it in games such as RPG, where the player needs to use a skill every time, a potion to recover its life or even click on a certain position on the screen to attack a monster. All of this can be done by simulating clicks or keystrokes.

Auto clickers can be as simple as a program that simulates mouse clicking. This type of auto-clicker is fairly generic and will often work alongside any other computer program running at the time and acting as though a physical mouse button is pressed. (Source: Wikipedia)

This kind of “cheating” can be very harmful to your application, since the user is having an advantage over other players and he can set the “Bot” playing for him 24 hours non-stop (which would be very difficult for us humans).

How does it work?

Usually, the operation of these tools is quite simple. The most common method is to send an Input message to the HANDLE of the window that we want to simulate the click or keystroke. This can be done using the Win32 API's SendMessage function:

LRESULT SendMessage(
  HWND   hWnd,
  UINT   Msg,
  WPARAM wParam,
  LPARAM lParam
);

In the first parameter we specify the HANDLE of the target window. In uMsg we specify the identifier of the message we are sending (Eg WM_KEYDOWN), and the other parameters are additional information related to that type of message. For example:

SendMessage(hTargetWindow, WM_KEYDOWN, VK_RETURN, 0);

In the case above, we are sending a WM_KEYDOWN message, e.g., a key is being pressed and with the WPARAM being VK_RETURN, means that we are simulating the pressing of the Enter key.

As explained, you can replicate this operation for other types of events and build your own logic, like building a Bot to automatically use skills in a game.

Problem

The problem we have when trying to avoid this type of cheating in a "native" way, is that we were unable to identify the source of a message using the Win32 API. That is, all messages are valid regardless of where they are coming from for our application.

With that in mind, what we should do is filter out these Input messages received in our application, limiting them to only reliable devices and that they originate from hardware, and not virtual messages (which are sent by software).

Implementation

The implementation of the proposed solution is quite simple. We will change the way we handle the Input messages received in our application, starting to use the concept of Raw Input (Win32 API).

The raw input API provides a stable and robust way for applications to accept raw input from any HID, including the keyboard and mouse.

To use Raw Input, first of all we need to register the devices that we want to receive the inputs. Thus, we can choose whether to receive data from a Joystick, a Mouse, keyboard, gamepad etc. No input will be detected if we don't have a registered device.

In the code above, we are registering only two devices: mouse and keyboard. You can check the RAWINPUTDEVICE documentation for more information.

With the devices already registered, our application will start receiving Input events through the WM_INPUT message. What we need to do now is to simply handle these messages, and identify whether we are dealing with a keyboard, mouse event, etc. I am showing the way I used it in my Gist application below, where I am handling messages from keystrokes and mouse clicks.

The operation of the code above is quite simple. We are retrieving the input data with the function GetRawInput, and with the output of this function we can handle the events according to our application. In my specific example, I check if the input message is of the keyboard or mouse type, and if it is valid, the application processes normally. Otherwise, the message will be discarded.

Although the solution is quite simple, this type of content (about cheating) is a quite difficult to find on the Internet, so the programmer's creativity is of great importance. It should also be borne in mind that for any solution, there will always be a possible gap (it is up to you to make it difficult to access the gap).

With the proposed solution, we will avoid the vast majority of Auto Click tools, as they all follow the same operation. The only case that our solution cannot avoid is when the Input is simulated by some type of hardware, because if the event is emitted by a hardware, we consider the event to be reliable and process the Input normally.

Just a reminder, architect your server properly!🤗