Soo, I am developing a game but I want to make sure it is safe from exploiters. I need to have quite a few remote events to send info from the client to the server for things like the player interacting with a sprint button system, changing their inventory through a gui, etc.
From what I know, an exploiter may be able to fire remote events themselves, and this could result in issues with giving themselves items out of thin air, breaking the sprint system (and obtaining infinite speed) etc.
I have brainstormed a method of protecting the remote events’ security, but I want feedback from the public for the following things: “will it work?”, “how could I improve it?”, and “if it doesn’t work then what can I do to instead?”
Here is my plan!
First create a “key”. This would be a random string that only I know.
Whenever an event fires from the client, I fire the string as the last argument in the FireServer() function.
When the server receives the event, check if the last argument is the correct key. If so, then do the function. If not, then kick the player for exploiting.
This would work from what I know since exploiters can only “insert” local scripts into the game. If they wanted to fire any events, they’d need to know the key.
Anyways, I actually have one concern about this method that I don’t have enough information to rule out by myself. This is:
Can an exploiter see inside the ingame scripts? If so, they could see the line of code containing the key and the whole system would fail.
Lastly, any help, feedback, support, and suggestions are appreciated, so if you have anything to say, don’t hesitate!
The exploiter might try to brute force the key, I would add some additional checks in place to stop any unwanted behaviour, and a rate limiter to limit the rate of the event bieng fired.
The truth is, remote events will always be exploitable without additional checks, the sole purpose of a remote is to communicate to the server via the client and vice versa. So that lends the exploiter access to the server. Which is very problematic and exploitable.
That might be an issue, you may also try to randomise the key and encrypt it, then send it to the server?
Okay. Could you explain what those other checks would be? Also, If I made the key 30 letters long let’s say, and I had it include lowercase, capital letters, numbers, and symbols, and if I kick them every time they guess it wrong, would a brute force attempt actually be a problem?
They could have a macro on, but they might not go for the extra mile to brute force it. Usually checks can vary depending on the situation, for example, leader stats, if there’s no proper checks, it might award the money/value to the wrong player or if they can sell apples for coins, they can fire a remote to sell the apples to the negatives, netting them tons of coins, which can be used to buy in game perks or whatever.
If an exploiter can see how your remote event fires, safe to assume they can decompile your scripts. How you sanity check depends on what type of trigger you want to happen, such as your sprint.
I just came up with this on the top of my head, but you could use a table to store the last time the player sprinted and how long the player is sprinting for. If its longer than x amount of time, do whatever you have to do.
Alright! Thanks for the feedback! But as one last thing, could you compile everything that would not work with my method into one post? (In simplest as possible vocabulary please)
game.ReplicatedStorage.SprintToggle.OnServerEvent:Connect(function(plr, key)
if key == "Jfmmwjakk184):$;jsmw2),alcmwjkxm" then
--Sprint toggle function
else
plr:Kick()
end
end)
And then, if the exploiter inserted a script that did:
game.ReplicatedStorage.SprintToggle:FireServer()
They’d get kicked because the “key” value on the server would be nil.
However, if they could see inside the client script, then they’d know what the key is and be able to write:
The method you described is unfortunately ineffective. Exploiters can read “decompiled” versions of your Scripts, which don’t have stuff like local variable and function names or comments, and they also have a tool known as “RemoteSpy” which can read data sent through Remote Events, so they can still find the key even if it’s randomly generated. Key or “handshake” systems, while common on this Dev Forum, really aren’t going to do too much other than be a minor annoyance to the exploiters and yourself.
Instead, you should prefer Server-side security and mitigations:
