Wanted to brief commend the effort to make a and improve an anti-cheat. These are really helpful, since exploits (especially physics based ones) affect a lot of experiences. Anti cheat development, discussion, and sharing lessons learned is a great direction for the community to move towards, since in the past anti-cheat development has been very “hush hush”, a topic of rare collaboration, etc.
I would definitely recommend giving this some solid playtesting and polishing. You’re mentioning that you released something yesterday and made massive changes to it (which is great!), but it’s important to polish and aggressively test prior to release, that way you’re providing people with a true resource, versus a work in progress project on the way to being a full resource. Keep going at it hard, I’m sure the process of revision and feedback integration will make the eventual final product something very useful to developers everywhere.
Just by looking at the code of this “new and improved” version I can already see that it is equally as bad, if not even worse than his previous version, the only part of his code I can see that actually looks like it functions well and without much flaws is the check for noclip. His anti speed exploit check will only work under the assumption that the exploiter is both using the native humanoid state handler for movement and the assumption that the exploiter isn’t spoofing the speed that is being provided to the Running state.
And the next one is his “anti fly exploit” which, to put it simply, won’t even work in a realistic scenario. It relies on the assumption that all fly exploits enable PlatformStanding, and also on the unrealistic assumption that the developer or some native engine feature or Roblox gear does not enable PlatformStanding. This resource does more harm than it does good in my opinion.
I do believe another thing to note as well with the “anti fly exploit” is that the client can very likely also just prevent replication of the fact PlatformStanding is enabled to the server entirely without issue, because it won’t affect how their client determines their character’s physics.
EDIT: I don’t mean to sound rude if my post came off that way btw, just stating that his resource was practically just as bad as his previous attempt which relied on an incredibly poor method.
This is really good for me since it might save me time in the future. I have some suggestions, maybe when a script changes a humanoid’s walk speed for example, or anything really, the script will have an attribute called “Changing Something” == true. The anti-cheat script will then look over all the scripts and see if the script has this attribute set to true. If it’s not, that means it’s a script being used by an exploiter. Then the anti-cheat script will kick the player. I don’t know if this idea will work though, as I have no experience with anti-cheat systems. Edit: nvm, that might be too much of a hassle for the game developers.
Also for the fly system, instead of platform stand maybe check if the player’s feet are touching any parts with the function GetTouchingParts(). If they are, check if the player is jumping, if yes, don’t do anything, elsewise, kick them.
There is one huge issue here. Your code relies on security through obscurity because you trust the client to send valid information.
The platformstanding check purely relies from information from the client and as such can be totally bypassed.
Same goes for the memory checks.
While the .Running check is calculated server-sided, the issue is that it only fires when the humanoid changes to the running state, the exploiter can simply prevent the .Running state from firing and completely bypass it.
So what you instead should do is adopt a completely different mindset in countering exploits. Don’t think of “Banning the hackers” or Security through obscurity.
Instead adopt an idea called Security by design. Your anti-cheat should be part of your validation system, instead of something that “Bans the hackers”. Don’t think of offensively fighting the hackers, but think of being defensive.
You should think of your anti-cheat as more of validating the data rather than punishing exploiters.
It should ideally only prevent the invalid actions instead of punishing, and should be completely secure.
You should also realise why trusting the client is bad. Its not just because it is, but because you can’t control it and thus attempting to do so is security through obscurity.
So this doesn’t mean that your anti cheat cannot use information from the client, but such information has to be 100% verified, otherwise it’s useless.
It seems like a lot of people are posting their (valid) criticisms with your AntiCheat system, so I thought I’d just remind you that learning is apart of the process. Everyone explaining the faults with your system once made those same mistakes. You can’t expect to release a full proof system on your first try!
You should be proud of yourself for releasing some open source work that hopefully others can learn from too.
Goodluck on your next version, it’ll be even better than the last!
And these children will get exploits from experienced programmers/exploit creators who know what they’re doing. It only takes one person to make an exploit that is designed to bypass your anti-exploit before it becomes widespread and used among any games making use of your anti-exploit
And here too, the same as the above applies. It won’t take long for exploits to be made specifically geared towards bypassing your anti-cheat. Trying to rely on the fact that “children don’t know how to exploit and only get them from others” is NOT a good ideology to work from when making an anti-exploit.
You should always be designing you anti-exploits under the understanding and thought process that someone who is experienced in programming or exploit creation can and will play a game using your anti-cheat, and that person can and will create an exploit to bypass your anti-cheat, whether it is public, paid, or private.
The last thing I’ll mention is that you shouldn’t rely on checking the .Velocity of a part if that is what I understand you mean when you plan on using instead when checking the speed of a player, because that too can be manipulated by their client due to how physics works.
humanoid.Running:Connect(function(speed)
if speed > humanoid.WalkSpeed + 5 then
p:Kick("\nORANGECAT Anti-Cheat:\nPossible Exploits\n(walkspeed of "..math.round(speed).." detected)")
end
end)
I don’t think you can get the client walk speed from the server like this.
So if that was a few days ago and you said it was a disaster and your 1st time… what would change today lol, I’ve never heard of learning an entire coding language in 2-3 days. This one does seem better tho.
No, v1 of ORANGECAT was from 2 days ago and was my second time (my first attempt was EpicAntiCheat). v1.1 wasn’t made that long ago, I stayed up late at night to update ORANGECAT to v1.1 and just updated it now. I have known Lua for 3 years, so I didn’t just learn it. I researched better methods of doing the checks and coded them. The fly check uses raycasts now and the speedhack check checks for the magnitude in the distances between the old point and new point, it ignores Y so you don’t get a false positive for falling.
Instead of creating an entire different post because your old anticheat that released 2 days ago was a disaster why would you create a new one instead of just updating your old one…
more importantly: an anti-cheat should never automatically kick players upon detection to begin with unless the detection method has a 100% guarantee that the player is in fact exploiting, and there aren’t many exploits where detection methods can 100% guarantee they are actually exploiting and not just a false positive.
How about making network ownership of player who are suspect to be exploiting to nil,To the server,So they can’t hack and false positive,Will make the player thinks their internet is bad,After sometime you make the player network ownership back to the player