The same ol’ saying: Don’t trust the client.
Now I’m not gonna go all out to say that you should never make a client-sided anti-cheat, but make sure to focus on server-side first.
Build a strong, server-sided anti-cheat that will prevent actions such as walkspeed, jumpheight, and gravity modifications by implementing checks to make sure the character always acts how it’s supposed to without needing a client-sided anti-cheat.
Now, here’s the thing, if you want to, you can leave it here since server-sided anti-cheats are secure and safe. They don’t generally need patching as if Roblox doesn’t change anything, you’ll be good.
But if you still want to develop client-sided anti-cheats, then you can go on and do it. But as I said, as long as you have a server-sided anti-cheat to back it up.
We generally say: “Do not trust the Client.” because it’s true. You cannot trust the client no matter which type of detection you add to it. Let me explain by talking about the methods first.
There are some popular methods such as Handshake, which is a local script on the client handling the anti-cheat while constantly sending signals to the server that it’s doing its job. Making sure that the exploiter cannot delete the script or else the signal will stop being sent and the server will kick the player because of that.
Other methods such as hiding the environment, hides the script from DEX and getnilinstances()
method. Pretty neat right? There are many ways you can try to prevent exploiters from modifying your scripts. So it might generally look like a good idea to use these methods. And to be honest? They actually work sometimes.
But this doesn’t mean they’re 100% effective and something you should put your trust upon.
The client has access to everything. With an executor/exploit, you have control over everything. The environment, the globals, the functions, events, and practically everything the engine has to offer. You can modify it. Developers are limited to heavily sandboxed methods while exploiters are free. They aren’t limited to global methods to do things. They have access to even the C++ side of the engine which no developer has access to.
The developer might try to use the getfenv()
method, but oopsies, the executor developer changed that global method to return nil or something else instead. What are you going to do then? The handshake method? Another oopsies, they have access to the bytecode, even if you try to encrypt it it’s a matter of time before the exploiters find a way to bypass it altogether.
This is why we say “Don’t trust the Client.”
Because it’s their territory, they can change anything. Even the Roblox engineers accept this fact while some people out there refuse to accept this only to get their games swarmed by exploiters who have figured out how to bypass their fancy “C stack overflow” method.
As I said, I’m not saying you should completely avoid client-sided anti-cheats, they can be effective if used well with a good server-sided one. But be careful.