So I understand there’s no way to truly stop exploiters. But I want to make anti exploit scripts that can stop certain exploits. I already have some ideas, but I was wondering if someone could give me some guidelines of what I really SHOULDN’T do when create them.
Also, is it necessary to use PrivateModules that hold all the code for the anti exploit, and are run by ServerScripts?
When creating an anti exploit system, you should never create strict or precise boundaries in all areas, especially areas that tend to vary. For example, if you will check if a player is speed hacking and you expect the client character to be in the same position as the server character, you might get false positives or vise versa because players with low end devices tend to lag, hence creating a gap between server character and client character position.
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.
You may want to look into this thread to check a player’s ping. It has several methods which are mostly optimal
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.
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.
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.
Please put your code in code blocks, so it is easier to read.
3 ` symbols lua
–code here
another 3 ` symbols
--code here
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?.
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.
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.
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).
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.
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?)
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:
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.
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