I am absolutely tired of going through these rubbish anti-exploits which could be described as a useless script whatsoever. These so called anti-exploits just fill up the resources category with complete garbage, one after another, and get so much backlash to the point where they get 60 replies in a day.
The next time I see one of them, I’ll be directing them right here.
Thanks for your effort on making a detailed post.
These properties aren’t good for serverside exploit checking. As a player by default, will always have network ownership over all it’s character’s body parts, these 2 properties will be calculated on the client and then replicated to the server approximately every frame - the client can easily manipulate these values.
Speaking of, the way you mentioned to use these properties is also bad. Ignoring out the Y axis of HumanoidRootPart.AssemblyLinearVelocity will result in you only detecting horizontal speed and not vertical, which means you won’t be taking in account of players rapidly teleporting up/down. You need to efficiently develop a system which checks if a player is actually not falling naturally and then perform checks – this can be done quite easily.
- Noclip every frame between current and previous position of their HumanoidRootPart. If the raycast result returns something, they clipped through something they shouldn’t have.
This is prone to false positives, just because the ray hit something, doesn’t necessarily always means they clipped through something. Players who walk close to corners, or closely against weird shapes can be falsely detected for “clipping” and this is quite often! You need to additionally implement a “depth-check” whenever the ray registers and check if the depth exceeds a certain threshold.
This isn’t necessary - ray casting was and still is cheap and Roblox has quite recently done a lot of optimizations for casting rays with much larger distances. Only the last point is a good optimization — ray casting is cheap, but that doesn’t mean you should cast rays unnecessarily every frame.
I’m aware now of why AssemblyLinearVelocity is bad and I now use previous position and current position, but I think AssemblyAngularVelocity property is fine to use.
I think I’m just confused by your reply. The client can easily manipulate them to do spin related exploits, but my serverside script will see that and punish them by taking away NetworkOwnership.
I ignored writing something about flight (Y movement) related exploits because my post would’ve been 2x as long, which is why I stated in my original reply that it was to check for X and Z movement only.
I’ve done a lot of testing with my anticheat and I’ve never had a false positive from walking too tightly around corners. Even when I enable replication lag, I still don’t have false positives like this. Maybe these false positives are from your anticheat/your method of doing so?
I disagree with this. Before adding a caching chunk system that stores legit parts, I would have high script activity (around 10%) for 8 moving players. It was worse before Roblox optimizations, but because I cache chunks it’s less than 1% for 8 moving players, unless they enter new chunks but then they’re instantly cached and return back to <1%. Also it’s <1% for all movement checks for 8 moving players, not just noclipping checks.
Have you tested your anticheat (I assume you have one) with multiple moving players and a with high FilterDescendantsInstances list? A fully finished game that would use an anticheat would not be a baseplate or 1 player servers, it’s important to test for scalability.
If you were already aware of why it is bad, then why are you saying it is fine to use it? By client manipulating them, I am referring to cases where the client manipulates the values in such a way that your server script thinks the velocity is ok, as in just a normal velocity while the client is actually going way faster than that. It is not safe to use any of these properties.
I’ve done a lot of testing with my anticheat and I’ve never had a false positive from walking too tightly around corners. Even when I enable replication lag, I still don’t have false positives like this. Maybe these false positives are from your anticheat/your method of doing so?
No, this is actually common and implementing a depth check reduces false positives significantly and I’ve experienced this my self as well - other anti exploits also suffer from this (assuming they don’t have any proper depth checks).
I ignored writing something about flight (Y movement) related exploits because my post would’ve been 2x as long, which is why I stated in my original reply that it was to check for X and Z movement only.
Okay, but you should have stated that beforehand so I would know - I cannot read minds.
I disagree with this. Before adding a caching chunk system that stores legit parts, I would have high script activity (around 10%) for 8 moving players. It was worse before Roblox optimizations, but because I cache chunks it’s less than 1% for 8 moving players, unless they enter new chunks but then they’re instantly cached and return back to <1%. Also it’s <1% for all movement checks for 8 moving players, not just noclipping checks.
Have you tested your anticheat (I assume you have one) with multiple moving players and a with high FilterDescendantsInstances list? A fully finished game that would use an anticheat would not be a baseplate or 1 player servers, it’s important to test for scalability.
Have you ever concluded a microprofiler test? If so – how high are your frame times each frame for those checks? A proper microprofiler test is the way to go about benchmarking your anti cheat.
If you have had high script activity, then that possibly means you’re doing something wrong. I used to have an old anti exploit of mine which used to perform no clip + a lot of other movement checks in a generally performant manner. Testing it out on a 40-50 player server, frame times never exceeded a frame and remained consistent at around 0.4 - 0.7ms. (The anti exploit was also open sourced but discontinued a long time ago).
I’ll edit my original comment, the comment was 2 weeks ago and I don’t regularly revisit topics I’ve already replied to unless I get a reply.
I’ll add this to my anticheat + my reply, thanks.
My original comment stated nothing about flight checks, just horizontal speed checks. I think that’s enough to tell anyone reading that I was not going over them.
I’m not good when it comes to navigating the MicroProfiler. This is results from one moving player, I’m not able to test multiple players currently.
Roblox can’t prevent ANY kind of client tampering. Once a user has the client on their end, they have 100% control over it and no one can do a thing about it. The single most fundamental rule of any client/server architecture (not just in gamedev) is DO NOT TRUST THE CLIENT.
No amount of obfuscation will prevent an exploiter (at best, briefly inconveniencing them). No amount of patching cannot easily be bypassed by an exploiter. They own the executable and can modify it or impersonate it any way they want, no matter what precautions anyone takes. If they really wanted to, an exploiter could use a packet sniffer and watch the traffic exchanged between the client and server and write their own client, from scratch. You could try to encrypt that traffic, but if the client can decipher it (via a stored key), which it has to be able to, obviously, so can the exploiter.
This is why all input received from the client must be validated and sanitized by the server.
Edit: Formatting.
All anti exploits suck almost nothing that is good is free except to make your own script.
Might wanna find a new game engine then, if you’re going by that logic.
I meant in Roblox. Tuejdujrfjjfhj
