This. Exactly this. Anti-cheats that rely purely on the client never work and never have worked. Poorly made “anti-cheat” resources like this one are even the sole purpose I wrote an entire guide on how to write your own anti-cheats, the correct way, and even went over why certain things are good and why others are bad.
2 Likes
This is true, Network Ownership allows the character to be used by the client.
You cannot set the Network Owner to the server, because this will cause delayed movement.
However, your speed anti-hack can stop flying.
So maybe, there are benefits.
Also, ping checks are not as useful.
And you can easily get ping from a player by using Player:GetNetworkPing
Btw, do not use RemoteFunctions.
RemoteFunctions can cause the server to error or stop working.
(More info here)
You also need to focus on the “non-physical” hacks.
Which include Hat bypass(Moving hats around to potentially make an inappropriate images), Permanent Death Bypass(Which is used for reanimation) ,and Humanoid Removal(Which can be used for god mode).
Creating
FE++ is a good example of a “non-physical” anti-exploit.
(Also if I’m wrong with anything please notify me 
)
This does not rely solely on the client. Additionally, the anti-cheat memory check only activates when the window is minimized, it disables once the window is re-focused. Things such as ping and memory checks can only be done on the client, due to Roblox restrictions.
looking at your code again, I can see the speed check doesn’t rely on the client, however the memory check definitely won’t work on most exploits, and the ping check relies on asking the client for information (you don’t even account for the possibility the client overrides the invoke callback, with your current code, the exploiter can completely bypass it by overriding this and either never returning, causing it to stop working for all players, or return fake information)
My advice would be to stop trying to focus on preventing exploits from the client, and rather, focus on preventing exploits based on their visible effects as seen from the server’s perspective. And also if you absolutely must have that ping check that asks the client for information, redesign it in such a way that the request can timeout after a certain period of time (like half a minute) to stop the check being disabled for all players as a result of the exploit.
On another note, your “screenwatch” ability won’t work if the exploiter fakes information being provided to it by their client, but I don’t imagine that one is as significant.
1 Like
The ping check is not made to stop script-based exploits, it is instead made to stop lag switching, or toggling your internet connection (this can be done via third party software or just disconnecting and reconnecting to internet). Lag switching can be done in combat games to freeze players, shoot them, reconnect, and deal damage. This is made to fix that.
Additionally, I wrapped the RemoteFunction in a pcall on the server, for error handling.
1 Like
Unfortunately, a pcall in this event does nothing to help your case. As far as I can see, your entire while true do loop will be halted until the RemoteFunction returns, regardless of the pcall. In fact, you shouldn’t even be placing this code inside of a while true do loop to begin with, this should be placed inside of something that won’t be permanently halted in the event the client messes with the callback function on it’s end to make it wait indefinitely.
I’d suggest using RunService.Stepped or some other RunService step event instead to prevent this case from ever occurring. I was well aware the ping check isn’t focused on stopping exploits from the client-side, which is why my criticism of it was more focused on how easy it was to bypass it due to this critical flaw in its design.
I have nothing against ping checks either, they are a perfectly valid and good means of preventing the exploits you mentioned as long as they don’t have such critical flaws in their design.
It can be spoofed using hookfunctions, can raise false positive
If you hover over the link you will see the actual link lol
I just need to memorize the links lol
Yup; okay lets not derail this conversation now lol 
1 Like
We’ll see
1 Like
In his case, the ping check cannot raise a false positive or be spoofed because it isn’t meant to make sure a player’s connection speed is within a certain range, it is meant to identify when a player is using a lag switch to simulate being completely disconnected from the server temporarily, and I highly doubt anyone who would play Roblox has internet bad enough to trigger an anti lag-switch check.
If you run PlayerInstance:GetNetworkPing() It can only run on client meaning it can be spoofed! everything on the client can be spoofed.
The DevHub only mentions that the method can only be called on the LocalPlayer when used in a LocalScript, meaning it can’t be called on other players when used in it.
“For client-side LocalScripts, this function may only be called on the LocalPlayer.” Player:GetNetworkPing (roblox.com)
If it can’t be used from a (Server) Script (Studio’s down so I can’t test it right now), the DevHub page should be updated to note this.
1 Like
This is a misunderstanding of the wording there. That actually tells you that when it is used on the client, the client can only get its own ping, and no other player’s, but the server can get the ping of any player.
Please explain to me how the client can magically fake a perfectly fine connection, whilst at the same time, intentionally causing their connection to have a temporary lag spike using a lag switch? I am trying to emphasize that unless this is magically possible, then you cannot “spoof” an anti-lag-switch check, which is precisely what he is doing here.
1 Like
If :GetNetworkPing was run on the client, I believe an exploiter could hook it to always return the same value, which I think was what @CodedJer meant.
1 Like
this isn’t what the ping check in this anti cheat is doing to begin with, it sends a request to the client and sees how long it takes the client to respond to the request. This cannot be spoofed by people using lag switches (the people the ping check is intended to catch) because a lag switch for the most part, completely blocks any requests coming from the server or being sent to the server in order to simulate a large lag spike.
Don’t you know that anything on the client can be spoofed? literally everything.
Thats what I’m saying! and also everything on the client can be spoofed.