Heads up, you should never look for anti-exploit stuff on the client. Clients have full control over their clients, and can easily mess with your anti-exploit, or even remove it. Hint: Never trust the client. All checks should be performed on the server.
But, I made a script to prevent that.
30chairs
but the client can disable your script?
No, only the server by the Dev console.
I’m telling you, any localscripts on the client can be disabled. Why? The client owns everything on their side of it, so the client can just disable a local script, and bahm it’s off. Exploits allow users to typically execute code, as-well as other things.
1 Like
I think you’re getting it wrong. The server cannot see what the client changes period. If the client changes something on the well, client, then the server will not see that change, making a .Changed uselsss. There is no way to combat this and there shouldn’t be.
Anti exploits should always be done on the server, all anticheats on the client can and will probably be disabled by the exploiter.
1 Like
Well, for the client they can make changes on there self like this.
WalkSpeed
Health
Yes, but this should be checked on the server… not the client. The client can simply disable your script that checks for that change.
You might’ve not known this but any changes done on the character specifically does have client replications. Which is why its not recommended to put anything important in characters 
Here is the post explaining more of the issue:
1 Like
This is why you should do all checks on the server side. You need to learn about FilteringEnabled, it’s important!
1 Like
Yes, But is there any way to prevent that?
Exploiters disabling the script?
You can’t, you need to do the checks on the server.
1 Like
depending on the type of game you can actually imbed your anti-cheat in scripts that provide gameplay experience (i don’t advise it though)
Usually the “anti-cheat” comes along with the gameplay scripts. For example, remote events with client to server calls.
If the client calls the server to purchase an item, don’t trust them at first. Do a sanity check (or an ant-exploit check for easier understanding) and verify if they can actually purchase it. If they can, give a go and let them have it.
2 Likes
tl;dr Do the checks in the server, in a script, recommended to be in ServerScriptService. The client can disable any script on the client side, so it is efficient to check on the client if the player is exploiting. FilteringEnabled wiki guide goes into how this kinda works.
Do you mean Remote Event Security?
These basically fall into the same category, ngl.
Edit: as I said do it on the server, and you’ll be fine.
2 Likes
I agree, but I am trying to figure out.
I will go with what you guys say.
before this gets too off-topic, let’s end it on:
It is possible, but it is virtually impossible to distinguish between admin actions and client-only exploitations, yes there are ways, check for disabled scripts, things that shouldnt be there, etc;
but you’d want to create an entirely different admin for that so you can directly hook an “anti-cheat” with the different commands and users and whatnot
Well, ok that Is what I am going to do.