Analysis of the source code isn’t required to conclude that this (like any other public / non-game-specific) “anti-cheat” is not suitable for use in production or any practical environment outside of a .RBXL file rotting in your home directory. Systems to prevent or mitigate exploiting must be game-specific, as they have to account for game mechanics and the attack surface of implementations (such as sprinting, teleporting, weapons). They must also compromise between being able to detect broad ranges of cheats and remain accurate enough to prevent false positives.
That being said, simple code review immediately brings out both design issues and bypass vulnerabilities in the few existing “checks”.
The ping check, to start with, is fairly redundant. No game is supposed to implement a system to punish a player specifically for having high latency or a period of no connection. This is not just because players would inevitably trigger this check, which makes it a bad idea in the first place. The underlying design problem is targeting latency instead of the broader problems that “lag switches” cause, which depends on the game, but can often be: “noclipping” through objects or avoiding obstacles, abusing client-side hit registration to damage players while being otherwise invulnerable or at a different location, etc.
This reinforces the statement that anti-exploiting systems must be game-specific. With this check you are only creating false positives while ignoring all other vectors of attack.
On top of the design flaw, the ping “check” is vulnerable to being completely bypassed due misuse of InvokeClient. A pcall is in place to prevent the server from throwing an error in the case of the client throwing one or disconnecting before returning, but this does not address the issue that the client can cause the server code to yield infinitely by never returning, with something simple like this:
RemoteFunction.OnClientInvoke = function()
while wait() do end
end
This, of course, can be fixed by using tasks and a proper timeout (or switching to a RemoteEvent-based system), not that it would negate how useless this is. Keep in mind that this “check” is meant to just “rubber band” the player in case of a loose connection. The player character can still momentarily arrive at an otherwise inaccessible location: Ex. a badge giver, button or other type of restricted area. This would also not mitigate any issue relating to using lag-switches with insecure client hit registration weapons and such. Instead of figuring out the rest of the infinite issues this check has, it’s easier to conclude that it’s useless and will never prevent any kind of practical exploit, and would instead introduce false positives.
The speed check relies on HumanoidRootPart to provide the character’s position. Due to the player character’s network ownership being set to the player’s client, an exploiter can potentially freeze, detach or remove (this applies to any part in the character model) HumanoidRootPart entirely (in a way that replicates to the server), thus bypassing this check. Further additions and checks need to be added to prevent illegal modifications to the character, if you wish to stick to this methodology. “Lee-way” is also added to the maximum allowed travel distance, which opens up a path to a lower-priority vulnerability which allows an exploiter to have higher-than-average movement speed while avoiding detection.
The API for this check allows a player to be excluded (ex. for teleports) which opens up vulnerabilities where an exploiter can use this exclusion time to teleport to an inaccessible location. A potential fix for this is to implement checking for server-sided teleports by using the Changed event on the Position or CFrame properties, as it only fires when this value is manually changed.
Another vulnerability is caused by the “check’s” long-interval-based distance checking instead of calculating a path, which can allow for an exploiter to travel at illegal speeds as long as they stick close (running in a circular motion, for example).
The “check” introduces false positives due to lack of proper implementations as well, such as:
- Cases where speed is applied only momentarily and reset before Humanoid.WalkSpeed is indexed (Lack of a journaling or caching system for all player speeds during a given interval and their timings in order to calculate an accurate maximum allowed path distance)
- Cases where physics forces (explosions, doors, slings, etc, moving platforms) or force instances (LineForce, BodyVelocity, etc.) give the character speed above what would be allowed by the maxTravel number, which only factors in Humanoid.WalkSpeed indexed at a slow interval.
- Cases where the player is falling off of a taller object, attaining a speed from gravity higher than what maxTravel allows
… and many other, which aren’t hard to figure out, but would turn this post into an entire book.
I refuse to comment on the client-sided “checks” as they can always be bypassed regardless of complexity or quality of implementation. Generally speaking, client-sided anti-exploit systems are a flaw on their own and should never be something you waste time on.
This post only has two points: to give insight into the current vulnerabilities in case you want to continue this as some “for-fun” personal project, and to hopefully discourage users from ever publishing or using such public / non-game-specific anti-exploit systems, as their only purpose is to cause headaches when dealing with false-positives and to give a false sense of security.
This post may have quite a few stylistic mistakes as I wrote this fairly quickly and without much organization, so feel free to point them out or otherwise respond to the content.
