Indeed most exploiters are script kiddies, but there is a fair amount of experienced ones. And all it takes is one experienced exploiter who makes a script for your game and releases it to script kiddies. That’s why you should never go by “noobs will never figure this out” 
3 Likes
Luckily for me, in my scenario and I think many other ROBLOX devs who’s games are victims to cheats more often than not are not dealing with the most advanced exploiters. My client anti cheats which were hidden in the chat scripts way back when were a surprisingly easy counter to many of these less experienced exploiters. Only two exploiters I have seen have been able to correctly use getfenv(2) and it seemed they hooked it into Kick() locally to stop it. Out of the many cheaters I have seen the two that were able to bypass a client script without deleting it used my initial metatables against me (which I have since removed to prevent an exploiter passing false information) which was a pretty good win for me considering the two that did exploit it were only testing it for me since I do not own any exploits on a Mac to test my own systems against. Hidden local scripts provide a pretty large level of easy security against these simpleton exploiters many games are plagued with*.
*Not to be confused with nil scripts, as those make it very obvious, I believe personally, when those more experienced players come into your games as to whats going on behind the scenes.
Again, you’re assuming that you will be lucky enough to not stumble upon any advanced exploiter. It’s not what you should do. You should try to guess what an exploiter could possibly do and then prevent that. Obviously, you can’t prevent everything, but you can still detect some things and then kick the player.
Using a clientsided anti exploit gives you more ways of detecting a possible exploit, but keep in mind your checks could be spoofed, events disconnected, and so on. That’s another thing you can prevent (or at least detect).
But yea it’s pretty much a cat and mouse game, however with enough effort, you can make your clientsided checks take too long to figure out for them, so that they eventually give up.
1 Like
OMG! Why are you having a script running on the client enforce this? You should instead detect when they are moving much faster than a normal humanoid could on the server side and set physics ownership of their character to the server for a while when something like that is detected. Won’t stop their inputs, but will sure annoy your exploiters as it will lag their character and their speed exploiting won’t register on the server side anymore.
Besides, that bit of code will bite only the first time a player’s character generates if it works at all. It won’t work after their first death unless it is part of a tool or GUI.
Proper remote communication is key.
That is not how it works neither is that how it should be thought of. It’s that the change is blocked. Only the speed effects will be replicated but the property itself doesn’t change.
I meant this to br a meme topic like
debug = nil
Smh
Yea just make sure to not pull a ripull and be proud of an anti cheat that uses :FireServer() when catches an exploiter, or ban all ur players because of an error in anti cheat
1 Like
The ripull one actually made me laugh xd. But yea I took precautions and my anti exploit localscript tries to use other ways to communicate with the server first. If they fail, only then it falls back to using remotes. (It also checks if you’ve been disconnected after firing the remote and crashes you if you haven’t)
I pretty much killed any effective exploits on my game.
All you basically need are server checks. However, this is hard to do sometimes if there are things that the client heavily relies on but is not on the server. For example, the recoil of a weapon.
Exploiters can decrease recoil on the client side. A way you can prevent this is occasionally checking the client from the server.
The server will always have the correct recoil value. Periodically, the server will ask the client for their recoil value. If they don’t match up, kick them.
Easy day.
1 Like
Client can reply with a spoofed value, not easy day.
Imagine not handling all your guns on server and the only thing that depends on client is the uis 
What am I??
Yeah,
then I can just structure my firing system around the server more.
Still easy day.
Just like last night I made a prototype gun system that I finished. It’s all on server and when I say that I really mean it, other than grabbing the players mouse smh, I’m planning to revamp it because server to client communication is epic in Roblox
That’s not quite feasible though. It’s important to deliver the client immediate visual feedback. If everything is server-side and you merely pass mouse information without doing anything, this won’t look good to the client.
You should re read what i wrote
If they actually know that they are doing there are some exploits that are basically impossible to prevent.
I just never trust the client and it prevents like 99% of most of the issues. Like every time a you send a :FireServer(arg, arg) event you should always check the data/arguments you send to the server to see if it is legitimate untampered data. It is also good to have the data you rely on located in the ServerStorage or in a script/module script that is not touched by the client.
1 Like
There are several threads on this. Please use the search function before creating such a thread.
To address the issue at hand though… I’ll be parroting many people when I say this, but do not put any kind of check on the client. The only thing you need to worry about is the server and minimising how much damage an exploiter can inflict upon your game. The client can do whatever they so please, it’s their device.
3 Likes
I made a script where it would change the clientside anticheats’ name to things like “GET NOOBED EXPLOITER”, etc. etc. and, no, it is not a basic font. its a different font, so that its harder for the exploiter to exploit my games.
I am not going to show the script because exploiters are on the developer forums and i know it.
2 Likes
A large majority of exploiters do not know what they are doing. However, another large portion of exploiters do know what they are doing. Your best bet is to make sure you have strong server sided security, and an anti-exploit on the server. If you really wanted, you could make a client sided anti-exploit too, I recommend you obfuscate it if you choose to, but remember that it can be deleted, exploiters can stop events from being fired (.Changed, :FireServer, etc) and so on.