Could you provide some “certain exploits” you are trying to prevent?
Hmmm… I did see some stuff on this when researching. Maybe I could check the player’s ping, and if their ping is low (less than 200), and they’re moving at abnormal speeds, it could kick them or reset their speed? What even is a good way to check ping?
Some exploits I’m wanting to prevent are:
Speed and teleportation
God mode
Obtaining weapons before they should
Obtaining items before they should
Basically, I just want to make gameplay fair for everyone, and don’t want things where I player could just have a script that kills anyone around them or something.
1 Like
You may want to look into this thread to check a player’s ping. It has several methods which are mostly optimal
2 Likes
Never rely on client-based anti-exploit systems. Everything on the client can be modified by the exploiter, including the anti-exploits. Always do server checks, since exploiters don’t have access to that. Using PrivateModule isn’t necessary per-se since nobody (other than the devs) can access server-side content anyways.
5 Likes
When you add remote event security, don’t kill people for sending fake values over; it could be an issue with your LocalScript that makes it fire bad data. Just ignore the exploiter’s request or add a cool down before they’re allowed to send another request or whatever.
1 Like
For god mode, I wouldn’t bother making your own exploit protection because roblox core scripts now automatically respawn most common godmode exploiters.
Alright, first of all you need to assume that the client has tampered the data that is sending back to the server. Implement sanity checks and ensure that the server validates every request.
Since some others have sent some good tips, I am just gonna add that your checks must not depend on the player’s connection quality. Server-sided movement checks, bullet checks and so on that depend on the player’s connection may raise false-positives.
1 Like
Please put your code in code blocks, so it is easier to read.
3 ` symbols lua
–code here
another 3 ` symbols
--code here
2 Likes
A key system does not work. Exploiters can intercept any and all information sent to or from remotes. They can see a few requests or look at your code, figure out the formula, and fake requests. Alternatively, they can edit requests while they’re in transit. See Is it possible for exploiters to intercept Remotes, and possibly event edit them? - #4 by Kampfkarren.
1 Like
Security through obscurity is not real security. Things like key systems or encrypting traffic are only temporary and fragile ways to stop exploiters, considering the exploiter has full access to what happens on their client.
8 Likes
Do you have any suggestions on how to provide more “security” to remote events? (ignoring the key system idea)
Server-sided checks and server authorization. Everything else is pretty much futile and a waste of time.
8 Likes
To further explain this, almost every remote you create should be easy to sanity check and authorise server side. This can literally be as simple as checking a player’s position or whether they have a gamepass (server side).
3 Likes
When making my Anti Cheats I do it on the server and check the users ping. You can then get the average ping that user has within the last minute or so and compare if there movement speed is abnormal.
It’s a bit more advanced then this in order to prevent false positives, but that’s the basic idea.
2 Likes
This is a little off-topic, but relating to exploit protection:
Example:
Client-Side: Let’s pretend that you want to fire a bullet
remote event arguments to server (player, bullet direction / or mouse hit, player position)
Can the server really trust the player position sent?^
Or should the server use it’s version of the player’s position? (If yes, wouldn’t players see a little latency between the initial point from where they wanted to fire from?)
1 Like
Guns are by far the most common case of a game mechanic that is hard to secure. Some basic things you should be doing in this scenario:
- Rate check the player, are they firing more often than their gun is able to?
- Do they have the ammo to fire?
- In terms of player position, I would do a comparison between the server’s position of the player and the communicated position and allow a small difference, over which the server position would instead be used.
Aside from this, you will have to trust the player’s arguments. Draw the ray server side, and communicate it to all other players in the server apart from the person who fired gun (you should draw the bullet’s path clientside for this player).
You always need to take performance into account, however. A system where the client who fired the gun drew the ray, and told the server what they hit would be much more performance effective, but would be much more easy to exploit. You as a developer need to choose a balance between security and performance.
6 Likes
Dont have your exploit protection harshly punish the player like banning the player unless you’re 100% sure it’s not false positives.
If you have something like anti speed, simply reset the speed so not only does it help stop those speeding, but it wont penalize innocent players harshly
2 Likes
Another thing which you can’t do is ever safely assume that a player can’t see the in the mechanics of your game. I’ve seen lots of tutorials online which assume that an exploiter can’t (for example) change a Boolean value in their character or something similar.
Also, for the idea on guns, many people store information about a gun’s stats in some kind of integer value in the gun. Ideally, you shouldn’t do this because an exploiter can simply change these values.
If you do use these values, just add server side sanity checks (I.E check if those stats were changed without permission) and you should be fine
2 Likes
You as a developer need to choose a balance between security and performance.
I’ll definitely take that into account, didn’t really think about it like that until now. Thank you!
1 Like