Fixed my post. Because, yes, smarter exploiters can still remove the animations script and execute another copy of Roblox Animate script using their executors. But most of exploiters will just give up at this point already. Most of Roblox exploiters are just skids that look up an existing script on the Internet anyway.
That’s also the necessary part for client side anticheats. You can also put the handshake code inside the same animate + AC script I told earlier. However you still have to account for legitimate players playing in bad network connections also.
Although people will just tell you to use serverside anticheats, we all know that and I have put every sanity checks in every places as possible.
However the point of client side anticheats is to make movement anticheats more effective (due to Roblox’s ineffective netcode and server-side movement ACs being ineffective on laggy players) and deter mostly skids; less exploiters is still better than having more.
Even If It did, every single property is nil according to roblox, even the ClassName, so doing nil:Destroy(), wouldn’t do anything, that’s the same thing as nil.Enabled = false after destroying environment.
But, who do you think makes the scripts the skids run? Some exploiters do it for entertainment and are very skilled. Some exploiters do it for money, and when you limit supply, demand goes up, and they capitalize on that.
You’re not actually preventing cheating.
You can prevent all movement exploits entirely server sided by doing physics validation, and there is no bypass to server-side physics validation.
This is simply not true. I know this because I went over a decompiled version of Eclipsis’ anticheat with one of the game’s developers some time between 2019 and 2020. Synapse was used to decompile the script, and it :Destroy()ed itself exactly like mentioned in your post.
I have even used this technique in the past myself, and it was proven to me that it is ineffective.
There is nothing stopping exploits from fixing this issue. Just because they have not fixed it does not make this a secure trick by any means. Because it is not secure. That isn’t my opinion, that is just by principle.
Exploiters can target your script by more than its name, for example they can target it by specific behaviours within the script, and they can spoof values which they change so that your script is unable to make detections.
Is anyone trying to bypass it? Unless there are people which are interested in doing so, there’s not going to be progress made on that. No client-side anti-cheat cannot be bypassed, simply because it is on the client, and exploits have full control over anything client-sided.
I believe I pointed out a number of ways handshakes can be circumvented above. Exploiters can spoof the handshake because they have the decompiled code, they can simply hide what they want to hide from your anti-cheat code and nothing else without even needing to decompile the code, they can disable behaviours within your anti-cheat code, etc.
They have full control over every aspect of how your anti-cheat executes specifically simply because it is not the same as the rest of your game’s code. And even if you do garble your client code by putting the anti-cheat inside a bunch of files and making a giant mess of your code, they can still very easily just selectively target your anti-cheat’s features or functionalities, or spoof things like CFrame, Velocity, Position, etc. They can overwrite the callbacks of connected events, they can literally edit the metatables of individual instances, hook functions which you utilize, etc.
Most of these techniques aren’t even used for the circumvention they’re used for simply identifying your anti-cheat so that circumvention can be done selectively so that it’s not impacting game code. You can’t win against a program that has control over the engine itself in a way that Roblox has inherently been designed not to allow for from your own code that’s competing.
There is simply no client-sided anti-cheat which cannot be bypassed, because the client is not secure. Exploits have full control over Roblox and all the code you run in it. There is not anything you can do to prevent that from being a fact.
I have no idea where you get all these claims from…
Just because an exploiter CAN hook/spoof/intercept functions/properties/connections doesn’t mean that they will do it perfectly. Just like how you said “there’s no unbypassable anticheat” there’s no perfect hook. Many good anticheats made by people like me, CodedJer and TheLikerYT have been doing this for a long time and people struggle to bypass. To make bypassing harder you can obfuscate the client which makes decompiling useless or tedious because synapse X for example could’ve taken hours just to decompile a 10k+ script, now imagine that script getting obfuscated. Many of the anticheats rely on security by obscurity because that’s the only option when exploiters have so much access over the game but that still doesn’t mean they can bypass everything with a snap of their finger. There’s not many good exploiters that are willing to spend their time working on a bypass for these anticheats and there hasn’t been a single full bypass for any of the latest anticheats we made. And about the env hide, CodedJer clearly stated that you don’t just do script:Destroy() but you also remove it from getfenv. This removes any references to the script and after a few seconds it gets garbage collected (unless there’s another script holding a reference to the script but that is unlikely) and if they try to stop the Destroy function being called you can simply detect it. If you want to see how a good anticheat is written, go ahead and look at XoifailTheGod’s thread “Anticheat Release: Valkyrie”. Clientsided anticheats are only good if you know what to detect and how to detect but most developers don’t have experience with making scripts in the first place so they’re inexperienced and that’s why you see a lot of bad anticheats in popular games. It takes time, dedication and experimentation to become good at making these clientsided anticheats. You can already learn a lot from XoifailTheGod’s thread where we release my latest anticheat open sourced with a few detections removed.
13 years of experience and a good bit of focus on anti-exploit.
This doesn’t make sense, misuse of hooking is just not knowing what you’re doing. There objectively is a perfect hook.
Obfuscation is not security. And again, you don’t even need to understand the anti-exploit to circumvent it, there are a million ways to do this. You can selectively spoof values which you change from the exploit. You can observe the script’s behaviour.
This is not how getfenv works. script = nil and script:Destroy() are equivalent to getfenv().script = nil and getfenv().script:Destroy(). This has nothing to do with the trick.
I don’t really understand how you would have a 1k entry list of people who tried to bypass your anti-cheat. I mean, sure, plenty of people have probably shown up in your logs, but that doesn’t mean that they were skilled or knew what they’re doing.
I will reiterate that no client-sided anti-cheat is secure, which is an objective fact. It isn’t security, it’s just obscurity, and for a million different reasons you’re not going to win in the long run.
Glad more people are finally defending client-side anti-cheat.
I have a few projects that are singleplayer so I pretty much HAVE TO rely on client-sided anti-cheat to some extend.
Some people would say “just do part of your game logic on the server” but that entirely defeats the purpose of the game being singleplayer.
I want NO lag, NO latency, NO waiting for the server to respond.
Everything needs to be instant and responsive, physics need to be client-sided, weapons need to be client-sided.
All game logic (except shops and mercs) need to be client-sided to ensure the butter-smooth experience even on the crappiest wifi connections.
I want to make a few singleplayer or semi-singleplayer games for players who aren’t looking for competitive PvP and just want a more personalized experience.
A lot of the game logic and the high amount of entities will likely be way too much for servers to handle anyways.
The client should have no issue simulating 300+ multi-threaded AI.
In theory, cheating could screw up and invalidate things like scores on leaderboards and it technically can be exploited to spawn in items.
Loop-kill scripts could be used to kill every enemy instantly.
For those reasons it still needs an anti-cheat.
But I cannot rely too much on the server for it.
I’ve thought up things like implementing a handshake system.
I’ll already be doing a few basic checks such as making sure players aren’t killing entities at ridiculously fast rates.
I don’t think I can really prevent item spawning or manipulating objects but the least thing I could do is keeping a table of data and replicating it around so the server at least knows how many AI there are, what items were spawned in / picked up, etc.
What love to hear what other ideas people might have for securing client-sided singleplayer games.
Would love to look into or try out stuff or know about more ways to verify the player is playing legitimately without having to do half the game logic server-side.
I’m not trying to be toxic or anything but this is horrible. Just make better, more secure scripts on your Client and also the Server.
If you’re having issues with Exploits you should never rely on a Client Anti-Cheat for any reason, most of the stuff is able to be detected on the Server (e.g. WalkSpeed, JumpPower, etc)
Visual Cheats such as ESP, Chams and others isn’t detectable w/ Anti-Cheats (Including Client ACs) unless the Developer of such script isn’t smart enough to use the Drawing Library. Aimbot isn’t really able to be detected w/ any sort of Anti-Cheat either.
nothing is detectable from the server, esp is patchable even if external or drawing, camera lock is detected through signals, mouse lock is detectable through ui signals, actors make an anticheat impossible to bypass and secure remote events (for now and forever)
But won’t exploiters just be able to read your localscript with the encryption and be able to submit to the handshake with their own scripting and stealing your own custom encryption?
Sounds a bit too good to be true. If it is true what you are saying, then this is huge. Although I’m still very skeptical. Even if you are wrong, this is still a very effective way to stop 99% of skids which imo is the point of a client-side anti-cheat(stopping people who can’t actually code). Even if it does get bypassed, I can just slightly change my encryption key/method to stop all the skids for a bit of time each update.
