Hello im wondering if there is a way to make my remotes secure for my project/game. Ive seen other people do it and im wondering if anyone know how to or can help me. Thanks!
You can add sanity checks or cooldowns with tick() / tables & task.delay(time, function)
As far as stopping exploiters from fake firing remotes, it’s impossible. However securing them is really simple and can be done fairly easily, provided you use the correct sanity checks.
Firstly, the easiest sanity check is if it’s an admin command or something equivalent, lets say like an admin GUI. A normal player wont have access to an admin UI, so anyone who fires it that isnt on the whitelist is an exploiter and as such can be banned.
Secondly, you can compare the data received to the data on the server. For things the player controls, i.e movement, this won’t really matter as you’ll have other anti exploits but if someones trying to shoot a FAMAS and when you know they have an AK-47, you can assume they’re exploiting and once again ban them.
Finally, you can secure your remotes by making sure you don’t overuse them. It’s a lot harder for an exploiter to cheat if theres 1 remote handling all weapons, but if theres 1 remote per weapon it’s a lot easier to pin point for them.
I wouldn’t recommend extremely short cooldowns unless required as a player could just be using an autoclicker or just a fast clicker, and they can be avoided easily.
2 Likes
If you want your game super secure, you can make dynamic event names. You would need some way encrypt the names of your remotes and a way for other scripts to decrypt the name. This would stop most exploiters since they usually don’t want to take the time to figure out these types of things. Another way could be to add fake events, that, when fired, ban the client.
I really like that fake events one but what do you mean by dynamic event names. I have a script defining the remote that fires it when the tool is swung idk how that would work then
I don’t think banning the client would be a good idea. The best way is to kick the client from the game. There can be some errors in a code that might detect the player exploiting when the player isn’t really exploiting at all.
By dynamic I mean that in every server, the name of the remote is different. You can do this through a cipher. For example, if you used a simple cipher that shifts letters by one, and you have an event called Coin, the event would be renamed Dpjo. Then, when a script tries to access the event, it shifts the letters back to figure out what the event is actually called.
True, but in my opinion, if you have a big game and a good staff team, a couple false bans that are easily restorable is better than a bunch of exploiters running around.
Security through obscurity is not real security. “Dynamic remote event names” is bad advice; consider the fact that your own code also needs to know which remotes it should be using in order to access networking features in your experience in the first place. Then, if you set up that method, exploiters can look into how it’s done and replicate that on their end to know which remotes do what.
There is no way to “protect remotes against an exploiter firing them” because exploit code is run through the exact same channels as legitimate developer code. The proper way to secure remotes is from the server-side through sanitisation or validation depending on your use cases, or other appropriate means. Client-side security is a nice-to-have bonus for exploiters who don’t expend the effort to breach your game or don’t have a publicly available bypass for your security.
Assuming that exploiters won’t take the time to breach your game’s security is a lazy thought process and can lead to security becoming part of your technical debt later in development. Don’t set yourself up for failure and certainly don’t shoot yourself in the foot. Look into proper security.
1 Like