Note: Until comment 25 on this thread, everyone is expressing valid criticism of V1 because it had some not that great checks. Those were replaced with solid checks in the rewrite (V1.1)
FEATURES:
Server-Sided Anti-Speedhack
Server-Sided Anti-Noclip
Server-Sided Anti-Flyhack
ORANGECAT uses a plugin to auto-update so you get the latest version and don’t use the old versions (I am new to making Anti-Cheat so I improve this a lot)
When you first load the plugin, it should ask for script-injection permissions. I added that so the plugin doesn’t do a failed install the first time.
You should see this when you first install or open a project without ORANGECAT Anti-Cheat:
(currently appears when playtesting because plugins don’t respect RunService:IsRunMode())
This should appear next:
This is from the plugin requesting the latest version from Github
After you press allow, this should appear:
If the plugin updates, this should appear:
After that, there will be 4 new instances. 2 are settings toggles. Those are in the a folder named “oranegcatac” in ServerStorage. You should also see an “ORANGECAT” script in ServerScriptService which contains the main code.
Here are some of the kick messages you can receive: (slightly reworded as of V1.1)
Remember: Any anti-cheat can be bypassed. Having an Anti-Cheat does not mean you do not have to secure your game.
Links to the source and the installer plugin are at the top of the topic!
PlatformStand is widely used with fly scripts. The only instance that triggers this state is a deprecated skateboard platform. If you make use of this state, this anti-cheat isn’t for you.
this can hardly be considered an anti-cheat;
the code is very lackluster with absolutely no safety;
alot of games make use of sprint buttons for example, it would just be a hindrance.
merely checking for platformstand is rather stupid, since you can fly without platformstanding.
the only alright thing here is that the server (appearently) checks if there is a valid response, however that is also easily circumvented by just faking a response.
all in all, from the replies i’ve seen you’re not the most knowledgable yet and you really should not churn out arbitrary “anti-cheats”
You’ve reiterated this quote many times in this one post, but what have you really learned in the past 24 hours to make this less ‘crappy’?
Your client-based code is literally just a copy of your old version
You also literally copy and pasted your initial server script
I do not believe that this does have sufficient checks and the ones that do are very ineffective at preventing exploits (the .Running event can have a false-positive if let’s say a player gets on a tycoon conveyor, and an exploiter can just hook the remote-event & spoof the memory to a random number, there’s also a lot else wrong with this that I just don’t have the energy to get into it)
This can happen, but if the player is not walking it shouldnt be an issue
That’s the reason why I was planning on removing the check
The “ORANGECAT1” script and the localscript are there as a check before I implement better checks.
The initial server script was quite literally a memory check. No matter how bad this is compared to another anticheat, it does its job of having basic checks (unlike EpicAntiCheat).
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!
