Hello!
I was wondering if I can make 2 Anti Exploit Scripts.
For the following:
Client
Server
The Anti Exploit Client, checks on the client.
The Anti Exploit Server, checks on the server.
Or Should I just put it all in 1, and make it server sided.
Yea, sorry if this is short, but I am asking a question.
Quick Poll
0 voters
There are some things that simply cannot be detected on the server alone. Your main anti-cheat should be one on the server. The client anti-cheat should be used as an extra little layer of security but it cannot be relied on for total security since exploiters can just bypass it. However client anti-cheats are often effective against skids.
You can’t 100% secure the frontend and never will, but you can always 100% secure your backend.
The client can easily disable anti exploits on its side, it’s up to you. A server-sided anti-exploit is fully invulnerable and should be more prioritized.
A client-sided anti-exploit might stop some people who aren’t that knowledgeable with exploitation but for those who know what they’re doing in exploitation, they’ll get rid of it. So, it might help but very little.
In general, it’s worth it to do the server-sided anti-exploit and the client anti-exploit is optional and not worth the time but it’s all up to you.
You should have a LocalScript in StarterPlayerScripts and a ServerScript in ServerScriptService. The reason for this is that ServerScripts cannot detect as many things about the LocalPlayer as a LocalScript. Also, if a hacker deletes or disables the LocalScript AntiCheat, the ServerScript can detect that, and shutdown the server.
Good Idea, I might put that in my list of things for the anti cheat.
Yeah that is what I did for my anti cheat. I created it myself lol
There are certain things that in theory CAN be detected on the server that ROBLOX does not give you. For example, there is a way to have the server keep track of the character controller and it’s movement and automatically correct the client if it’s offset. This IS possible but it’s a tacky system as you would need the client to predict the pattern of input so there’s no input lag on the client’s input. This way the server is the only one seemingly moving the character and the client is just a “false replication” in a sense. However this is easier said than done and a drawback to it is if a player had 400 ping then the game is basically unplayable if your game requires a lot of movement cause the lag between the player will cause the client to always be corrected cause the client is too far offset from the server so the client continues to correct the position.
Incredibly tacky concept and I know I just brought this entire concept out of a post that was meant to be yours about your own anti exploit but I thought I should share it cause it’s a potential solution for 90% of all exploit usefulness.
I have made an anti-cheat myself, and I did it from client to server. Having another localscript check if the main script is disabled or not. Though, it’s generally best not to trust the client. Sometimes, there could be some false-positives. Be aware that your anti-cheat that checks from client can be in some way bypassed.
You can copy scripts that the client requires, put them in starterplayerscripts and add code which checks on your Anti-Exploit(AE) scripts. However as mentioned above they can just edit the exploit code
you could for example make a localscript that waits for all items in the player’s PlayerGui to be loaded and once they are use player.PlayerGui.ChildAdded:Connect() to kick the player if it finds anything else added that shouldnt be there. however it depends what you’re trying to do in your game. whenever you’re adding guis to the player(s) you would need to disable the script.
That wouldn’t work, because exploits mainly parent to CoreGUI.
Even more advanced ones just draw on your screen without using a ScreenGui at all.
What I do for my games is I make a client and a server anti-exploit just for more security. In case my local script did not detect anything, at least I have the server and vice-versa.
Keep in mind that exploiter can fire Remote Events client sided so they can in some way cheat. Think youself as an exploiter and what if you fired a remote that is somewhat the main way of “winning” your game. You would need to add some sort of security checks so players don’t get a feeling that somebody else can cheat their way to faster stats which will make them uncomfortable and unpleased.
If an exploiter knows you are doing a client-side script to check for UI injections, they can also inject a script into your checking script to disable the checking, just like they injected into CoreGui.
A simple example is a store; ask the server, “can I buy this sword?”, and don’t tell it, “I can buy this sword.” The server should be the one checking everything from currency to experience points to levels, since it has the final say in what’s really happening. You should always be ready for someone on the other side of the bridge to outsmart you, and make absolutely certain the code you wrote is well tested for cases like someone throwing a
NaNat you or expecting an object and getting a table that looks like an object.
Quote from @Autterfly in this post.
When you’re coding your game you must always think of what the player can, and can’t do. If you understand that, you will gradually understand what not to do. For example, if you are to let players buy something in your game, you want them to be able to buy the sword, but you don’t want them to buy it for free. Think of all attack surfaces, all the ways an exploiter can harm your game, and fix it.
The server is the messenger, the client is the computer. Don’t overload the messenger with things that the client can do.
The server exists for the following things:
The server does not , and again not , did I say “not” twice? Well, I mean it. It does not exist for the following:
So basically, it would be better if you make a server sided script only which deals with anti-exploiting. Any client side security mechanisms will be bypassed, always detect abnormal things on the server.
Anticheats generally should be done server sided because client side anti-exploits are easy to bypass. A good server side anti-exploit is impossible to bypass.
Basically, I based off other dev forum posts for my reply, and some things I have said belong to the proper owners that have said it in their own post.
Efficiency tips for MMORPGs? - #5 by Affenity
How you should secure your game - A beginner guide for secure networking and developing anticheats
Exploiting Explained
If you would need assistance making your anticheat give me a message on discord and I might be able to assist. Viken#0243
Good Point there, but there is a point of having 2 anti cheats, Server and Client.
I quoted this message from another poster
The server is the messenger, the client is the computer. Don’t overload the messenger with things that the client can do.
If you want, just go for it but I do not suggest it.
Ok, I’ll took all your ideas…
It’s best to have 2 Client Anti-Exploits that over-ride each other if one is disabled. If they are disabled, you can make it re-enable itself making it impossible to disable them. You can then add a check to see if the script has been deleted or removed and kick the player.
Edit: I already have this feature in my game making it impossible to disable or get rid of the Client-Side Anti-Exploit.
Just to let you know and anyone thinking of doing the same thing, that can be easily bypassed by the tools exploiters have access to.
You always have to remember exploiters have literally COMPLETE CONTROL over their client, nothing can change that.
Exploiters can
It is pretty much pointless to create anti exploits on the client as it will only stop the exploiters who don’t know how to script. Even then, once exploiters that actually know how to script release their exploits, it actually becomes completely pointless.
As, I had mentioned the ServerScript is a backup to the Client-Side Anti Exploit. Therefore, It blocks any damages on the Client side by over-riding any localscripts that may be added to the game.