Although your implementation is rather good, it is not foolproof. Never trust humanoid states, they can be spoofed from the client. An exploiter can change their state to Seated, Climbing, Ragdoll or FallingDown and use their advantage of network ownership to fly or use other movement-enhancing exploits.
There are methods to solve this issue, such as implementing sanity checks for each state to ensure that conditions are met and followed for each of the states, such as being able to identify how a player falls. You can also sometimes disregard the negative change in a player character’s Y coordinates as that is a simple solution to prevent falling from being tagged.
As others have stated, never rely on client anticheats. Work on your serversided checks and experiment with different concepts of being able to detect cheats and to justify normal behavior.
This is true, to an extent.
99% of exploiters are script kiddies who don’t know what a variable is.
1% of exploiters are talented programmers who usually distribute specialised exploits for x game.
Your security will always get bypassed if there is enough need.
What I do is listen to the humanoid state change on the server and check that humanoid walkSpeed and if any of the stats that I contain in a table are greater then they are supposed to be I ban the player. As this could get mistaken for a player who may of accidentally gotten flunged.
Still most dont use random pastebin stuff they use scripts from a popular site known as [DATA EXPUNGED - link has been erased user can’t acess removing traces…]
which has a big community even most videos link it the codes they provide has best anti exploit breaker and help guides to help get rid of anti script if the code can’t do it automatically and you got to do it manually.
still client scripts may work but they are not the best for long term solution and dont put your anti script bulk on it
Client anticheats are a complete waste of time, it is factual that they cannot in any meaningful way prevent exploiters. The simple truth is that by developing both a client-sided and server-sided anticheat you waste time on infinite hopeless client sanity-checks which can reduce performance and disregard that about infinite methods there are to achieve advantageous behavior.
Server anticheats function very differently from client-sided ones. With serversided ones you mainly aim for logical checks to ensure that the client complies with laws of movement and Roblox physics, thus making your anticheat reliable and fairly small. The result of a good serversided anticheat is that you are practically able to stop most or all movement exploits and make your entire system unbypassable, meanwhile all client-sided anticheats can be bypassed.
The client has untold power, exploits themselves enhance this power even more. Exploits are able to manipulate property and function indexes, intercept remote events, disable scripts, alter physics and more. It is simply futile to attempt to control an environment which is way more powerful than your scripts.
Exactly but most exploiters don’t even know that half of that is possible.
Ofcourse it’s a waste of time making an in depth client sided exploit.
A simple ban/kick on walkspeed change for the percentage of users who can’t (or haven’t yet) bypassed it. It has to be combined with a server side anti exploit.
Just a simple if statement and boom. half of all the exploiters in your game are gone. The other half has to be warded off with server anti cheats.
I hope you realize how you’re contradicting yourself. If you have a sufficient serversided anticheat you do not need to provide “special treatment for the 80%”. It is not just a waste of time to develop an “in-depth” client-sided anticheat, it is a waste of time to make one in the first place. There is no logical reason to have one if your serversided variant is effective. The practice you’re suggesting is bloated and bad practice, simple as that.
I never meant to say that you should only rely on client side exploits.
There’s always going to be false positives considering lower spec devices and bad internet connections might behave suspiciously for the server side detection. In my opinion something is better than nothing.
Your assumption that “lower spec devices” and unreliable internet connections can in some way false-flag anticheats relies on assumption that your anticheat has no method to gracefully handle cases of abnormality. It is only logical that unless a check you’ve produced is extremely accurate, you should not ban or kick the player. Having a client-sided anticheat on top of a server-sided one would also not resolve this issue. Your idea also contradicts, you state that serversided ones can be partly false-flagged by unreliable connections (physics freezes, freezes mid-air), and although that’s true, in no way is having a client-sided anticheat as well going to resolve that. You will still be making the same checks on the server which can still yield the same false-flags.
in no way is having a client-sided anticheat as well going to resolve that
I was thinking more obvious changes like walkspeed being set to 100, jump power to 100 etc.
I understand what you mean but I’ve seen games get ruined by anticheats which detect false positives from normal gameplay (booga booga for example) which makes me want to reduce the possibility of them occurring. But in the process the anti exploit would probably become too forgiving.
Please don’t take this as me trying to convince you that my initial/current idea was correct but me providing my viewpoint.
This is a common theme I see on the devforum, that client checks are useless. I know from experience that client-side checks are not totally useless, and for the most part can perform very well alongside server side anticheats. While all client anticheats CAN be bypassed (as mine have been too), most players who come through my games don’t know how to bypass these. This is a huge window of exploiters that CAN be stopped via client sided checks. There is simply some things you just can’t determine from the server. For example, in one of my games, there’s server-side checks for speed, teleporting, flying, the usual stuff you CAN tell on the server, then on the client there is additional measures. In my game, players use classic swords to fight. There is loads upon loads of ways to cheat in sword fighting that you can’t determine on the server – resize other players hitboxes, resize your swords hitbox, teleport other players body parts to the front of your sword, change your swords grip, there is countless ways of doing these things. The only method of partially stopping this on the server is by determining the distance of the two players, and setting a cap to how far the swords can damage. This is simply not enough, and exploiters will still always have the upper hand in these fights using the aforementioned exploits. This is where the client-side comes in. With my client side check, I can use a .Changed event on the sword’s size, the sword’s grip, player hitboxes, and a good bunch more. To date, this has allowed me ban ~4,000 exploiters this year, all while doing nothing. This enables me to have a smaller moderation team, a more enjoyable experience for players, and overall everyone is happy. None of this would be possible without client-side checks, so while they can be bypassed, that doesn’t mean they aren’t worth giving at least a little bit of time into making. To review exploiter reports and ban the 4,000 players it showed me would have taken a good amount of time, far more than the two hours it took to write the client-side anticheat.
I would like to interject that your case involves a serious flaw in your game. Classic linked swords are a massive security vulnerability. This is due to their working mechanism, which revolves around the handle’s Touched event. As you should already know, even if the handling of it is serverside, the tool is under the network ownership of the client. This creates perfect grounds were clients are able to physically expand their tools or otherwise modify their positions client-side and make hits register regardless.
I don’t argue with the results of using a client-sided anticheat, you being able to ban upwards of 4,000 exploiters is great news, although I do not believe that your solution is at all effective. Instead of porting your gears / tools to methods that mitigate this massive security hole - such as with using Touched alternatives which do not rely on client physics (Raycasting, raycast-based touch implementations, Region3), you make a client-sided anticheat which hopefully prevents most of the exploiters from having any effect. This is in my opinion bad practice, as I’ve explained with work on your hit-registration methods you can completely mitigate their exploits without any exceptions. Whereas with a client anticheat you put a basic barrier in their way which a mediocre exploiter could bypass without effort and call it a day.