At this point you have to be trolling. There is no way you missed the point of the post this hard even after it being explained to you.
4 Likes
The problem is that most of the “amazing resources” are not amazing, let alone resources.
4 Likes
This post was not directed at those who don’t make these mistakes.
2 Likes
As the person who wrote the code that he used in those screenshots, I am happy he wrote this post. Just because it was my second attempt at making an Anti-Cheat doesn’t mean I shouldn’t be told it sucks. Criticism can lead to being a better coder. If no-one told me how bad ORANGECAT Anti-Cheat V1 was, I would have thought that using humanoid.Running was a good idea for speedhack detection which is not good at all. I rewrote the anti-cheat and learned a few things about ROBLOX itself so I won’t make that mistake again. If no one makes posts like these, they won’t know why people are calling their new resource bad or why cheaters are bypassing their anti-cheat.
9 Likes
Alrighty, going to leave my take on this post.
I agree with you, Anti-Exploits can be quite bad, especially if they aren’t thought about thoroughly before production. It has always been, and always will be the most practical to stay away from the client as much as possible, In fact this has been reiterated one too many times, that’s kind of getting old now.
On to my next point, this post already exists, in the form of one you just linked in your original post, as well as another one that can be found right here: A complete guide ~ How exploits work & how to best prevent them - #5 by Autterfly. I would recommend searching before making a post that already exists (just so it doesn’t end up like the AC posts)
Last point, about the whole “title is harsh thing” being said in this thread, they really aren’t wrong, but nor are they right. I do believe the title could be something more like “Why Anti-Exploits have the tendency to fail” or something less personal. The “Your” directs it at people which is, in general, not good practice. (a bit ironic…?) I personally don’t care, people can say what they want and it doesn’t really affect me personally but yeah the title is fine if you really feel like getting up in there face (and risking it)
In general the post is fine, this thread is fine, and people just need to think more about their Anti-Cheats. I do not intend on replying to anything that may have not been thought over. Just my 2 cents.
3 Likes
Haha, Valve has been made a mockery of many times for their anticheat. You can bypass it using garbage code with ease.
Some games with high-quality anticheats (that Roblox could partner with the services used/develop their own) are anticheats like Riot Vanguard (Valorant) and EasyAntiCheat (Epic Games/Fortnite).
Of course creating an anticheat is not easy, especially on a game that revolves around user generated content however Roblox has also denied developers the proper access to patch exploits themselves and has given little to no support regarding the issue. They have brushed it off time after time and it’s gotten to the point where it’s a major problem.
yeah… im not giving some chinese company my credentials.
(even if epic is chinese owned aas well and has bought kamu, the company who created easyanticheat)
2 Likes
In case anyone else believes that Roblox hasn’t done anything since FE being forced, I think that it’s fair to mention them creating a faster Lua VM which had some new security measures, as well as them usually “patching” exploits every week when there’s an update (although, usually these aren’t very effective and get unpatched after a few hours).
Also, what is this “proper access”?
Ironically, at one point it was referred to as a “rootkit” because it turned on at boot and installed a driver onto your computer without permission.
2 Likes
Valorant’s anti-cheat is very bad. It blocks random programs. It conflicts with WallpaperEngine, the program I use for my wallpaper. It is also very sketchy requiring to be started at launch and needs a restart to disable/enable. I don’t trust it and many people would quit ROBLOX if it was used.
5 Likes
I love how this topic is formatted. Anywho, this is a good topic for anyone trying to learn how to develop proper anticheats.
For users that don’t know what properties are good for serverside exploit checking, here are a few:
- HumanoidRootPart.Position (get the previous frame position and current) and get the magnitude of both of them. Something like so (PreviousPos - CurrentPos).Magnitude
- 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.
For the noclipping every frame, it sounds extreme, but it works amazingly. Running it with Parallel Lua and optimizations (listed below) you can easily make an anti-noclip that scales with large player counts and relatively low script activity.
Raycast noclip optimizations:
- Parallel Lua. Use :ConnectParallel on the RunService.Hearbeat connection.
→ This ‘combines’ all threads to cut down on a lot of lag. Not entirely sure how it actually reduces lag, but it does if you check out Script Performance before and after implementing Parallel Lua. - Create a “chunk cache” system where noclippable (anchored=true, cancollide=true) parts in a 50x50x50 area are cached. This can be done with GetPartBoundsInBox. Players can then request already cached chunks instead of repeating GetPartBoundsInBox every frame.
→ The reason you’ll want to do this is because if you have a huge part count, even with Parallel Lua, running small raycasts every frame will cause a lot of lag if it has a massive FilterDescendantsInstances list. The smaller the filter list, the less script activity it’ll use up. - Don’t check for noclipping if the player hasn’t moved.
→ If the player hasn’t moved less than 0.01 studs, they’re standing still or moving at a snails pace. You shouldn’t perform raycast checks unless the player is actually moving.
If anyone has any questions or additions to my optimizations, let me know!
4 Likes
I’ll use this reply as a reply to four responses to my post.
Regarding the idea that Roblox hasn’t done anything since FE being forced, that is indeed false. I am very aware of Roblox’s “patching” and “security improvements” over the past few years however we have yet to see a patch that critically effects exploits globally (similar to one on the level of Filtering Enabled which caused many popular exploits to go offline for months if not years).
Regarding my discussion about “proper access”, I will explain exactly what I meant. By “proper access” I am talking about the access to read and/or modify instances in CoreGui, have more client state changes available, access to Roblox-locked services that would benefit the anti-exploit community if they were unlocked, etc. I forgot to add how useful it would be if developers were able to hook functions in order to block them from being used. This would be a MASSIVE step towards proper security of games.
I do understand that what I am asking for “proper access”, that it is indeed a possible security risk hence why I said it’s extremely hard to patch exploits on a game that revolves solely around user-generated content.
The last thing I’ll address is the comments about the anticheats I mentioned and China. As for Riot Vanguard and it’s false positives, I completely get that. It’s very annoying to have random programs blocked by an anti-cheat however bugs are a key step to improving a product. Let’s also not forget that Riot Vanguard is a much better anticheat compared to the weekly Roblox “patches” on exploits (fixed by every exploit within 12 hours).
As for China and it’s data laws and whatnot, I was using those anticheats as examples. I said that Roblox could partner with them, never said they had to.
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.
3 Likes
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.
2 Likes
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.
2 Likes
I meant in Roblox. Tuejdujrfjjfhj