Recently I’ve made an anti exploit on the client that would detect some basic exploits like abnormal walk speed and such.
How does the server know if the client script still exists?
Every second, the client script fires a remote event that would tell the server that the client script still exist. Now in the process, the client script would hold a variable that has been destroyed by the client, meaning client scripts can no longer access the variable, but the anti exploit client still can. The server will see if the variable is the object (that has been deleted by the client). Notice: The object still exists on the server side.
Flaws I see
Lag - Possibly falsely kicking the player when the client script still exists
Yes.
Its hard to come to terms with for some new developers however, it is downright one of the only things that can be seen as impossible to do within coding.
The rule I go by personally is: if it can be built, it can be broken.
Meaning you will always have someone who’s going to burn hours to weeks of their time to breakdown each little piece of your code until its bypassed.
Rule of thumb: If it’s on the client; it’s accessible, modifiable, and can be intervened.
Remotespys can see the secret “key” that’s being used to verify the integrity of the anticheat. The exploit can imitate its process and pretend like it is the anticheat.
It’s going to be stored inside memory on the client’s own computer no matter what. Custom functions like getgc(), getnilinstances(), and getreg() can access hidden information.
Spoofers and securecall can mask the environment of the exploit, making it practically undetectable by means of stack tracing.
Client-sided anticheats are basically useless and impractical. You’re better off investing your time in server-sided anticheats and sanity checks to ensure the highest level of security in your game.
The best way to make an “impassible anti-exploit system” is to continually update it. If you’re constantly fixing loopholes in your system, you’ve also been managing to send the exploiter back to step 1 with each and every patch. I can’t speak for the exploiters but spending hours or even days on something for it to get fixed in the next day or so seems like a lot of wasted effort for little yield. Although it won’t be truly “impassible” you can certainly fight back against exploiters, and quite possibly get them to give up.
Not only is this poor practice/spamming unnecessary remotes, but is insanely easy to replicate from exploits. Simply a case of while task.wait(1) remote:FireServer() end and bam, your anticheat won’t be any wiser.
Let’s assume that it was impossible to fire remote events from exploits. It could still be easily bypassed by simply removing the script and replacing it with an empty one or one with the main anticheat code removed instantly after. One whole second is more than enough time to swap the instances over and the anticheat wouldn’t know any better.
In short, easy to bypass and just poor practice anyway.
Unfortunately, nothing that relies on a clients’ good faith to report they’re not cheating is going to be effective. The only thing you can really do is to keep the client responsible for as little as you can and sanity check everything coming from the client. Assume everyone is a cheater and design your event handling around that. Also, hide as much code as you can in ServerScriptService so that it’s not replicated to the client. If they can see it, they can figure out how to exploit it.
Yes, this is why you shouldn’t rely clients as anti exploits, they can just mimic values.
Always rely on serverscripts no matter what, never use localscripts for anticheats
How can they bypass it:
They can just copy the value and inject a script which sends the same value and delete the localscript and kaboom. The server will think “ooh this malicious data is safe.”
If you were reading correctly, you need a variable to be passed to the server in order to tell the server that the local script exists which can’t be accessed since it has been destroyed.
You’re still storing a reference variable In the localscript, which means the exploiter can copy the variable and destroy the localscript and inject an modified one which does nothing other than send the variable to the remoteevent
Wait. Do the exploits have scripts that are in lua? If so then if could a script found the script wouldn’t we have access to the exploits own commands?