Verify Client Mouse Input on Server

I’m creating a game that depends on “clicker” style input. The only way to do this is fire an event on the server from the client every MouseClick.

I can verify on the server that the event isn’t being fired too quickly to prevent insanely fast auto clicking; this part is simple. What is not simple is preventing bad actors using exploits from creating a (literal) 4 line script to fire this event on an interval for an indefinite amount of time on loop, allowing them to essentially “AFK grind”. I understand this could also be achieved with a conventional auto clicker, however, at least in this instance the user would have to have their game open and it would disable them from using their PC for other purposes; an inconvenience tradeoff I see as valid enough reason to not care quite as much about this mainly unavoidable method of abuse. I do not, however, want users to be able to exploit with no repercussion.

Is it even possible to prevent this? Is there any possible way to [efficiently] verify on the server the mouse was ACTUALLY clicked, and the event was not simply fired via injected script?

What you’re asking for is just CAPTCHA, which is always waging a war against bots. No CAPTCHA is 100% safe, but you can try making it as difficult as possible to automate.

Here’s some ideas:

  • Have the player click buttons located in random locations on the screen, in a specific order.
    • Devise a way to visually tell the player what the correct order is, but keep it difficult for bots to understand
  • Have the player click & drag the button in a specific pattern
    • Once again, a way of keeping it easy for real players but hard for bots
  • Record the mouse movement during CAPTCHA and discriminate suspicious mouse movements.
    • Calculate the acceleration of the mouse. If it’s noisy and erratic, it’s probably a human.
1 Like

I’m not so concerned with autoclickers as I am exploiters. CAPTCHA would not allow me to validate that the user actually clicked their mouse when the server receives an event from the client. Although I could force all users to periodically verify they are not AFK, I would also have to fire an event on the server once they complete the CAPTCHA, which would also be impossible to verify the validity of and therefore vulnerable to exploits.

Is there not an established way to validate user input on the server? Seems like this is essential for any input to ever be able to be trusted on the server.

The first example I gave needs the user to click buttons in a specific order. This is essentially a password that the player needs to get right. There are countless other ways to do something similar.

The server can only do so much before starting to become invasive to the client. Sanity checking can only check the data itself, but not how the client got the data.

Firstly, I appreciate your genuine effort to assist me. I apologize for being critical, however

The first example I gave needs the user to click buttons in a specific order. This is essentially a password that the player needs to get right. There are countless other ways to do something similar.

Once the player completes this process, I’m still required to fire an event to the server indicating it was completed. This could be fired by an exploiter without ever actually completing the process. Even if I were to generate a password from the server, and send it back to the server once the CAPTCHA is complete, it has to be exposed to the client at some point - therefore being vulnerable to exploiters.

I totally understand what you’re suggesting, but there is no way to sanity check a CAPTCHA is successful, or any other form of client input that has already been exposed to the client.

Edit: I think the simple answer is that I will just have to leave the event unprotected outside of sanity checking for debounce, but I appreciate your suggestions.

You’re completely missing my point. The client needs to fire the event with the password to prove that they did the CAPTCHA correctly. The server checks the password. It cannot be guessed.

Which is why in my first reply I suggested ways of communicating to the player how to solve the CAPTCHA without making it obvious to bots. If you need examples:

  • A matrix display where you send an encoded table representing the pixels of the display. Because it is completely visual, a bot cannot immediately tell what it says, but to a human eye it is simply a number.
  • A mesh shape inside a ViewportFrame that reveals a number when you look at the mesh from a specific perspective.
  • A colorblind test.

The exploiter would need their own machine learning algorithm to try to crack these examples, which, by then you have bigger issues to worry about.

I’m not referring to bots, or people using autoclickers.

I’m talking about cheaters using executors, granting them the ability to run arbitrary code on their client.

Exploiters have complete access to reading parameters of events fired from the server to the client, as well as firing events to the server with any amount/type of parameters they choose, and viewing the contents of client sided scripts. If I generate a random password on the client, there is no way to provide the server with the information needed to determine if the password is correct that isn’t able to be easily reversed or bypassed by exploiters. If I generate it on the server, the client won’t be able to access it. If I send it to the client, it is visible to exploiters.

Edit: if it was as easy as this to generate some sort of passphrase to sanity check server-client communication, it would be the only type of sanity check needed. However, it doesn’t work, which is why other forms of checks are necessary.

Did you even read the examples I just gave? You are not sending the raw password to the client. You are not even sending AssetIds. You are just telling the client the instructions to retrieve a password that requires human intervention. This is literally what a CAPTCHA is, and it definitely works because it’s everywhere on the internet. You are worrying too much.

Also, if you take a step back and look at the bigger picture, in what circumstance would an exploiter devote hours of their time to try and crack a CAPTCHA in a Roblox game? More importantly, why would you design a game such that the only fundamental game mechanic is something that you have to fear so much about getting automated?

Okay, let’s say I use this method.

Every ~5 minutes, I have the player complete this type of CAPTCHA. I pull up a puzzle on the screen, and prompt them to click the first, and then third, and then second image sequentially.

In order to generate this prompt, the client needs to know in which order the server expects these images to be selected (1, 3, 2). This means I have to send (1,3,2) from the server to the client. Regardless of whether or not this is in plaintext, in order to display it to the user, it would then need to be decoded on the client. An exploiter would have access to this decryption process, meaning it is instantly and effortlessly reverse engineered; making it no longer secure. An exploiter can receive the “encrypted” event parameters from the server, decrypt it, and immediately send a valid response to the server.

There is no way to visually represent such a sequence of events that does not require the client to either receive and decrypt, or generate, the sequence. As soon as this happens, it is no longer secure, and is incredibly simply decoded. We’re talking about exploits that have malicious, internal network access - not a bot that physically completes the CAPTCHA.

As I stated, if this were a valid method of protection, it would be the only method ever required to ensure your remote events are secure. This would already be the primary, accepted method for sanity checking. However, it isn’t and cannot be.

In fact, this has already been discussed on the forums.

CAPTCHA works on the net because in normal circumstances, network requests can be protected. This isn’t possible nor provided by Roblox in the case of executors. This is why executors are able to work at all.

Edit: The source code of CAPTCHA, it’s methods of action, decryption processes, etc. are also not open source. If they were, it would be easily bypassed just as it is in my example. An exploiter has free access to my client sided code.

I’ve already said it, you are NOT sending the raw password to the client.

This depends on how you implement it, what I’m suggesting means that the “decryption process” needs to be a fully fledged LLM running on the client’s PC needed to simulate a human person’s vision. Refer to my other example:

The server sends a dictionary of booleans to the client. Here’s what it can look like:

{
    ["1,2"] = true,
    ["3,5"] = true,
    ["7,10"] = true,
    ...
}

The client reads the table and lights up pixels on the screen based on the data. The player sees the display and reads the number it represents. Nowhere in this process is the password revealed to the client. An exploiter would need something to interpret that table and guess what it represents, which necessitates a machine learning algorithm. Like I said earlier, this is not something that should be on the top of your to-worry list.

You are confusing CAPTCHA for an anticheat. It is not an anticheat. You protect your remotes with sanity checks, not a human check. Exploiters are humans.

I described a process that could in principle be performed by a CAPTCHA. It is not the only thing that the CAPTCHA uses to discriminate humans. Other factors include your network traffic, your search history, even your biometrics. These are data that you do not have access to for obvious reasons which is why you do not see it being used in Roblox games. In other words, it’s impossible to implement industry-grade CAPTCHA in a Roblox game.

Once again you are confusing CAPTCHA for cybersecurity.

Also, Roblox exploits work because the game client is on your computer, which you have full control over. You protect the client-server interface with sanity checks, NOT with CAPTCHA because it’s completely unrelated.


A reminder because you are getting off-topic: You are using CAPTCHA to tell apart bots. I gave you suggestions to implement CAPTCHA in a secure manner that should be exploit-resistant. Protecting your remotes and your game security is a separate issue that has nothing to do with CAPTCHA.

1 Like

I am getting off topic? I’ve repeatedly reminded you I’m specifically seeking a way to protect my remote events from exploiters and not worried about bots.

The method you describe here is genius (not /s), if I was looking to create a CAPTCHA system to detect AFK “bots”. My post asks about securing remote events from remote tampering exploiters.

You mention an array of pixels to represent my expected output, which is farther than I had personally thought into this. The problem lies in that this is an incredibly complicated solution that raises more issues of performance than solves security flaws. Do you seriously expect me to be able to do this in a performant manner, inclusive that I will spend hours defining these characters as pixel arrays and implementing enough randomization that exploiters can’t perform their own sanity checks against existing examples?

Again, it would not. Ignoring the apparent presumption that I am world-class in cyber security, and as I mentioned above, the amount of sheer time necessary to create a method such as this (let alone knowledge and effort), a bad actor could very easily log 2-3, if not only 1 of my “generated” pixel maps and do extremely simple checks to determine which character I am representing. I would have to use thousands of pixels with slight discrepancies to avoid this.

No, but the solution I requested is closer to an anticheat.


A reminder because you are getting off-topic: I requested a way to protect my remotes relating to user input for game security. Single-handedly creating an optical-character-recognition test to check for human intelligence is a separate issue that has nothing to do with this.


Edit:
I offer you a friendly challenge, perhaps it will entertain you. Create this system yourself, to the parameters I requested, and I will find a way to circumvent it. If I can’t, I will personally pay you 100,000 Robux or 350USD. Your choice.

I don’t want to purchase the system: just a wager on whether it can be done.

You were right, I was the one who went off topic. :pensive:

This thread is way longer than it needs to be. Let’s just start over to clear up.

The short answer is no. I apologize for not making it clear and jumping straight to my suggestion of implementing CAPTCHA, which I argued is exploit-resistant.

Your ultimate goal is to make sure players play fairly. Your game security is important in this respect so exploiters don’t just fire remotes to trigger game mechanics. For that, there’s really not much you can do other than sanity checks, which cannot tell the difference between human input and exploit input. But CAPTCHA can be used to predict if the input was legit based on some other information that you can get from the player. If the game is about clicking, make the player do a bit more with clicking that exposes nonhuman behavior.

If it’s about the CAPTCHA itself, I can try making it with a few tweaks because I don’t want the money

3 Likes

Likewise, I apologize if I became short throughout the discussion. I was trying to indicate I did not believe a simple implementation of an optical system would be immune from cheating. Your more detailed revelations make sense, and offer a great solution, but I just don’t view them as the solution to my circumstance and thus disagreed not with the logic behind your text but the proposed implementation of your ideas.

Sadly, without the use of a more complex solution such as the ones you have offered, I see this being fruitless as it once again falls into the court of being impossible to sanity check on the server. While this proposed method does solve the issue of AFK players by requiring constant human input, alas the events used to indicate success once again fall victim to remote event spoofing - and lead back into our conversation thus far on the topic.

I hope I do not appear overly critical and wish that you view my analysis with understanding. I’m only attempting to better define the specific caveats, to me personally, of these ideas; not disband them as if they are irrelevant or invalid entirely. They are absolutely valid, but not in my intended implementations.

With that being said, I’m disappointed that Roblox seemingly has no straight-forward way to protect user input being sent to the server outside of generic sanity checking. This includes keystrokes, mouse positions, etc - all of which are often relied upon for vital game play elements not exclusive to a “clicker” that need to occur on the server. For instance, in my implementation of granting n currency per click. The best I can do is server-side debounce to prevent a non-human amount of inputs from rapidly occurring, where I wish I could prevent automation via script instead.

The choice is yours, I only intended to highlight my points that the amount of time and effort required, as well as navigating glaring performance issues of generating and displaying pixel arrays with pseudorandom capability is far out of my scope of interest. The invite is still valid and I’d love to see the final result if you make it happen.

edit:sp

2 Likes

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.