Hello, i’m currently working on an client → server anti exploit system for my game and i would need help finding breaches and issues with it to try fix them.
Explanation :
This anti exploit system uses an Instance as the passcode.
When the game launchs, a server script creates an Instance with a not suspect class in ReplicatedFirst. After this, local scripts save it in a variable and after that the server set the parent of the passcode to nil.
Doing so prevents exploiters from being able to acces the passcode.
When a remote event get called, the server will check if the passcode sent by the sender is right else it kick the player. After the check is done, the server will change the name of the Instance to an string of length 11 with each character being a random base64 character. After the name is changed, the passcode parent is set to ReplicatedFirst and immediatly after back to nil. This is done so the Instance replicates to the client.
Exploiters can access anything on their client. As such, they can access local code, thus knowing the passcode.
This might work for most exploiters, but I wouldn’t trust it to catch the “big fish”. Simple honey-pots and sanity checks from the server should suffice for most games.
I’m no expert when it comes to anti-exploits, so I can’t really give a clear answer on this.
However, if the module is visible to the client, in theory they could open it using exploits. Thus, they would be able to see the variables in the module.
Basically, focus on server-sided antiexploits, as they are much more reliable/should not be bypassed.
Clients cannot view assets in ServerScriptService or any service with “server” in the name to be exact.
LocalScript variables can be hooked and spoofed with ease and nil instances can be recovered with getnilinstances. This anticheat is very insecure as you are giving exploiters a time window to detect your instance, get the passcode and save it. (Execution upon client startup).
Your best bet instead of this is trying to go with obfuscating your anticheat to prevent most types of variable hooking and spoofing, and to use a common instance if you’re gonna continue to try your name method. Not instancing a new one in a rarely used service.
First of, now the passcode get stored in ServerScriptService so they can’t recover it and for the variable thing, and im not sure if they can get variable from modules required by some scripts and even if they could i could try to reference the module before and then putting in ServerScriptService.
And what do you mean by obfuscating?
Yes they can. ABSOLUTELY ANYTHING AND EVERYTHING on the client, whether or not it is supported by the vanilla roblox engine, is accessible by a hacker as long as it is on the client side
Yes, even variables in localscripts, nil-instances, dummy folders, data that appears for a second and is then removed. Anything.
Think of it this way, have you heard of Cheatengine? It allows cheaters to access stored variables and edit code of running applicarions or games on windows.
The exact same is possible with the lua/luau engine. They can still see the variables. Even if you remove them, or scramble them and pass them along, they can see that code, and modify it so that it just prints it out. Yes, they have that sort of power.
Think of it this way, the client is the players house and localscripts are like lock boxes you mail to their doorstep. No matter how hard you try to secure the box, they can always get a sledgehammer and smash it open.
Server-side checks however, are not at their house, and theres no way for them to reach it. One such example is an server side anti cheat that checks that their y value is not above a certain level. In this case, they are powerless. Since the script is not on the client, not at their house.