i don’t think i need to explain anything here
3 Likes
They can inject code (and even whole scripts) in LocalScripts.
They can make their character do all sorts of funky stuff.
ServerScripts are safe, but some RemoteEvents can be triggered from LocalScripts to ServerScripts, so you have to be careful with what potential damage they can do if they get fire server events without any sort of anti-cheat.
2 Likes
Exploiters can do whatever they want with their clients. By trying to stop them on the client side in any way that comes to mind, you just make their life harder temporarily. This may be useful for small games, however as a game’s popularity increases, more actual threat actors are attracted to it. By threat actors I don’t mean a random kid injecting things in their executor, but a dedicated team of people who know how to write code, that decompiles your client-side checks and makes code specifically to bypass them. Then they share that code publicly as one of your game exploits, which keeps working until you patch it, and it becomes a cat-and-mouse race every time you try to patch something on the client side. These groups often operate in ways that help them earn money(for example by selling access to their malicious code and obfuscating it so much is not worth the time to make it look readable and bypass the access). Although sometimes they may not get paid at all, just break your game for fun.
Therefore if you really want to protect your game you need to carefully control the communication between client and server, on the server(for example rate-limiting remotes, checking argument types, verifying everything on the server, etc) and apply your client-side logic on the server as well(for example if a proximity prompt button can’t be clicked if the client avatar is X studs away, you should make a distance check on the server).
A good tactic I like to use to avoid accidentally banning people if they’re just laggy is to add client-sided checks as well. That way, if they bypass something and the server picks it up, I know they exploited and they disabled those preventing them from performing said action. Basically, I use the client filters as a way to protect normal players from the server filters, not stop exploiters.
I personally recommend focusing on anti-cheats when a game is almost ready for production, not during the early phases. Otherwise, it might distract you from actually developing the game itself and you may have to modify the anti-cheat multiple times due to the game mechanics changing.
4 Likes
soo, exploiters can do whether they wan’t on client, and if you can’t secure scripts/remotes on server too, but there is tricks to prevent that, firstly, not every cheater are hacker, soo for example someone who uses gui to change speed or jump will be kicked, if someone uses writen scripts, there is a bigger problem.
here is few solutions to solve the problem of cheaters:
-
change name of local scripts to prevent them from be deleted by script
-
change location of local scripts, you can put them inside folder with other scripts, and with custom name, cheater can’t delete exact script, because all of them are different every time, soo if he wan’t to destroy scripts, he have to delete all of them = he can destroy his game and can’t play without restart
-
update game, if you’ll update game frequently, cheaters can’t write scripts that fast + you can relly on roblox’s anticheat a bit
-
secure your remotes, soo even custom local script, can’t acces them in wrong way
Ok this is all about cheat prevention, i think i help you
1 Like
Thanks for all this info! I have some questions though. Can exploiters modify a table in a local script?
Exploits have functions like “debug.setupvalue()” and “debug.setconstant()” which lets exploiters modify upvalues & constants inside of functions.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.