Why Your Anti-Exploit Sucks

Repost because I accidentally posted it early :dizzy_face:

Almost every day the #resources:community-resources section is blessed with an anti-exploit which can’t even do its job because it indulges in some bad practices. Now while these posts are met with valid criticism, and usually get locked within a few hours, I’d like to attempt to educate any aspiring anti-exploit developers with a few of the most common bad practices I see in such posts.

My personal big three of the bad practice list are

  • Client-sided security
  • Common false positives
  • Lack of versatility / bad UX

Client Sided Security

While it’s not a terrible idea to secure the client a little, I just hope you understand that it takes one competent exploiter to release a script to the masses and forever nullify your client’s security measures.

That’s not the only reason why, however. The second and most important reason is that the exploiter has full control of what the client does. Anything the client can do, an exploiter can do. I’ll go over a brief list of common client-sided anti-cheat measures which can be bypassed within minutes.

  • Memory checking
  • Indexing literally anything
  • CoreGui descendant checking
  • Kicking on the client

Everything listed above can be spoofed by an exploiter. They’re able to completely override any method called on the client. If you want to learn more about spoofing, do check out this thread. In summary, don’t rely too heavily on client security. It’s not worth your time.

I advise against memory checking not only because it can be bypassed within 10 lines of code, but also because it can return false positives on players with lower-end hardware. Speaking of false positives…

False Positives

For those who don’t know, a false positive is when someone is incorrectly labeled as an exploiter. This can be for any number of reasons but usually boils down to a small oversight on what the developer believed was possible at the time of writing their code.

I’ll use a recent example of a false positive gold mine.

This is a bad way of detecting (and dealing with) speed hacks for a few reasons, but the main one I’ll point out is that this can be set off by physics acting up. The speed argument passed when the .Running event fires does not pass the value of the Humanoid’s WalkSpeed, but rather the velocity at which the HumanoidRootPart was going when it does. This also includes vertical momentum, so even if you’re falling too fast, this will go off.

As for alternatives, I would suggest measuring strictly horizontal velocity, and detecting for consistent time intervals that the speed goes above the norm.

Bad UX

UX, or user experience goes both ways here.

I’ll start with bad player experience, which I’ll define as not punishing potential cheaters effectively. No matter how great your anti-cheat may be, you will always catch a false positive one way or another. It’s just a matter of how frequent it is.

So when your anti-exploit “catches” someone, you’ll want to punish them accordingly. So what’s the best course of action to take if your script catches someone going over the speed limit?

  • Ban the player
  • Kick the player
  • Teleport the player back to where they should be

This is a pretty subjective question, but I strongly believe it’s best to be tame and reasonable when dishing out punishments, at least when a machine is the one doing it. As suggested by @Pokemoncraft5290, it would be much friendlier to simply teleport the player back to before their speed changed suddenly.

If your anti-exploit goes haywire and starts banning or kicking people, your players won’t like that. You’re far less likely to lose players by giving them a small setback as opposed to removing them from the game entirely. Not everyone has that much patience.

Of course, even lax punishments that start going crazy can eventually lead people to leave out of frustration, but as someone who has played games with anti-exploits, the less invasive the better. A game with an invasive anti-exploit that constantly pesters legit players is not fun. Even if it mitigates the threat of exploiters, I personally wouldn’t have much fun with the base game.

Now for bad developer experience. This only applies to the people making anti-exploits for public use, as games with a special anti-exploit tailored specifically for that game probably don’t have bad dev UX.

When you do make a public resource, I think it makes perfect sense to try to appeal to as many developers as possible, which means you should not bar potential consumers by marking certain API usage as an ‘exploit.’

Once again borrowing from a recent example.

This code just outright boots players who enter the PlatformStanding humanoid state. Now while this code does its job in punishing some fly scripts, it’s a bandaid solution that can be bypassed by just, not using the PlatformStanding state type. I personally use this state type for ragdolls in my game, but I know I’m not the only one who uses the PlatformStanding state type.

The obvious fix to anyone who wants to use this particular anti-exploit is just to remove that block of code, but this also is just not a good countermeasure for fly exploits.

Closing Remarks

There’s nothing wrong with making anti-exploits. They’re a necessary addition to any game, and small fixes can go a long way.

But when developing one, you should have user experience and practicality in mind. A bad anti-exploit is just as good as no anti-exploit. People who flood this part of the forum have good intentions, but bad implementations. I’d like to emphasize that it’s okay if your ideas and implementations aren’t great. Learning is an important step in making a good, versatile anti-exploit. Criticism may sting, but it’s a necessary component if you want to make any resource.

Don’t harass or bully anyone who may be guilty of any of the bad practices listed. Politely let them know that their methods aren’t the best, and move on. Don’t be rude.


I’m not sure if you this is included in respawning, but another good approach is setting the player back to their last “valid” cframe.

if speed > humanoid.WalkSpeed then

Also, I feel like another thing that you should touch on is security through obscurity, i.e. obfuscating the source code or not releasing it. Chances are if you need obfuscation to make your anti-exploit more secure, your anti-exploit isn’t very secure.

Other than that, very well-made topic.


+1, was just about to say the same thing. IMO, it’s less annoying for legit players if they get teleported back to where they were a frame ago, and slightly more annoying for exploiters because they’re effectively locked in place, and I’m pretty sure :LoadCharacter takes longer than just teleporting them back.

Other than that, I think that this post does a good job of explaining why an anti-exploit won’t work in an actual game :+1: (though, I do believe you could’ve blurred the name of the faulty anti-cheat in question).


You make a VERY good point there. That couldn’t be more true.

Great observation. That perfectly sums up every thing that’s wrong with all the anti-cheat posts in the resources category.


The Number one Rule when making an anti-cheat/anti-exploit is to NEVER EVER TRUST the client.

Yep. All it takes is for your character to accidentally get flinged, and then you’re through.

I agree with all the points you made in this post. Great tutorial!


very valid, very true;
the jist of this is that there are MANY kids/unknowledgable people who think, and i dont hold it against them, that they’re helping big time. but the issue is there are always greater resources out there, especially if you’ve only been doing lua for, often times, a few weeks at most. None of them will read this, but if they do: please stop plastering your bin anti-exploits just because you coded on it for 10 minutes, it doesn’t help anybody and you’ll feel bad from the monstrous amount of criticism.

also i remember that code snippit from somewhere :^)
(also yes i am aware how harsh my message is)


I wanted to leave this on just a like but I can’t. This is one of the greatest posts I’ve come across and finally someone has said this. I’ve seen so many questions and so many resources revolving around anticheats and only one of them has actually been useful/good (the developer left the platform now but not before reporting multiple exploitable features on Roblox to the public).

It’s quite sad that this is the reality but Roblox hasn’t been able to fully patch injection and tampering of the client since it’s existence. The biggest exploit ‘patch’ was FilteringEnabled but at this point in 2022 it’s just considered common sense to not allow direct server modification of a game from the client.

I definitely support the creativity and the anti-exploit developers who are actually trying to make a difference by discovering methods to detect hard to find/hard to patch exploits but at the end of the day vanilla clients are a LOT weaker both access and execution wise than exploit clients.

I’d really love to have some kind of support about exploit patches from Roblox but I have yet to see proper responses from their team regarding how/when/if they will ever patch exploits (they’ve said it loosely in the past few years but never released a statement).


Well articulated. Thanks for taking the time out of your day to address this.

I really love the way you phrased the end point that developers have good intentions but bad implementations. The anti-exploit scene should be a collaborative effort of the developer community to help each other in securing their games but unfortunately there’s a lot of competition and bad practice being shared that’s actively harmful to security discussion that should simply not exist.

It’s one thing to want to develop an anti-exploit for people to use and all but often each experience will have very niche weaknesses alongside common inherent engine flaws and it’s important to tailor discussion around the problem and an abstract solution instead of trying to be the one-fits-all or “authoritative”/“popular choice” on fixes. We’re in this together against bad faith actors.

Experience security is a topic taken seriously by a large swath of, if not all developers, so it’s also important not to be fruity with words and yet stay respectful and contributive towards this topic. We’re all winning when we have more information going around to help us allow players to enjoy our experiences the way they’re intended to be played with little to no interference from bad actors.

Great work. :heart:


Also; for my own anti-exploits, i usually work on an internal “warn” system, that way you can alleviate inconsistensies due to lag and whatnot by just wiping them after an interval, depending on how many warns, the punishment would become more severe (eventually leading to a ban, obviously)
but generally you should, and have to be, leniant enough so that there are no false bans under any circumstances (hence the warn system)


I feel like you’re saying exploiting is something Roblox can patch very easily, which isn’t true because even tech giants like Valve can’t make a fool-proof anti-cheat.

hence valve, or at least games like cs:go, have the so-called “overwatch” team… division… thing, that are basically the same as roblox admins (but alot more active and numerous in direct comparison to roblox’ mod to player ratio)


But that is comprised of CS:GOs playerbase. tbh, I would worry a bit if the team of people in charge of terminating my account if I did something wrong was 50% children. Of course, that’s just a hypothetical situation. Maybe Roblox could have security measures in place to prevent children from getting into the “Roblo-Watch” team.

But Overwatch isn’t an anti-cheat anyway. If an exploiter fired a honeypot remote, Overwatch members wouldn’t know they did, because it wouldn’t make any visual changes. Only a script specifically listening for the honeypot would know it’s an exploiter, and if anti-cheat bans were sent through Overwatch for review, Overwatch members would think it’s a false-positive and would lose trust in the anti-cheat.

Anyway, maybe my fears are never going to happen, and maybe an Overwatch in Roblox would work flawlessly with no incidents. But, IMO, I think it would be a better idea if games implemented this individually.

that’s true, but it was mainly just a random idea being thrown out; it should definitely be done by the games themselves, but there should still be properly reviewable sources to determine about properly banning someones account from the roblox site (for mods/admins/whoever bans people)

Hello @ellienonekomimi

Your explanation is very interesting, but it honestly doesn’t quite fall into this category, and it looks like you’re commenting on something you don’t understand, If you have so many good ideas, create an anti exploit yourself and publish it, At least other people publish their resources even if they are not perfect.

You can’t deny people to publish their projects, everyone is free to do so then it’s up to you to get the best resource.

You misunderstood the point of the post.


You’re right. It’s not my place to police what people can and can’t do on the forum. It wasn’t my intention to stop anyone from developing anti-exploits and posting them here.

My goal with this post was to educate those who develop anti-exploits, and explain what practices should be avoided when making them. As I said, many developers post their resources, get met with backlash, and get their posts locked.


I don’t know if other developers have had experience/noticed this, but I’ve seen less persistent cheaters going the route of resetting CFrames/teleporting the player over kick/bans. Here and off-site, I used to be making the same thing on other engines. Kicks are almost a challenge for them to come back and try again.

Honestly, your post is no better than many others already created, there are many others more complete topics,

Almost every day the #resources:community-resources section is blessed with an anti-exploit which can’t even do its job because it indulges in some bad practices.

This is incorrect and perhaps even offensive to those who have published resources, it is obvious that everything is not perfect, But what the developers publish are amazing resources, I repeat then it’s up to you to decide the best one or create your own anti cheat with their ideas / code

Before you judge other people’s work, create a better resource and then judge others.


create a better resource

Is this not a community resource to help people better their own anti-exploitation efforts? Knowledge can be better than handing someone code they don’t understand.


With all due respect, that isn’t a healthy mindset to live by, especially in the development field.

I don’t develop anti-exploits, but I can spot a flawed anti-exploit and point out why it’s not very good at its job.

If I buy a product, I reserve the right to critique and give feedback on it. I don’t need to make a better product before I’m able to call out anything which is wrong with it.

I am not discrediting anybody who makes these resources. There obviously is hard work put into making some of them, but as you said, nobody is perfect, and those imperfections can undermine the whole purpose of the project.

I mean no ill-will, my only intent was to educate.


I am just going to say this: Your title “Why Your Anti-Exploit Sucks” is very harsh and arrogant.

I agree with everything else in this post though. its very well put and logical. Well done :happy1: But don’t assume that we all script the same way.