How to make an Server Anti Cheat

[AC_Starmarine]

plus your sending a remote to the client which could be blocked to so you can’t detect changes.

[ScriptedSuper (Scripted)]

You see, the remote is fired as soon as the player successfully joins the game. So they can’t load their exploits that fast.

Also, just remove the script:Destroy() from the localscript and remove the wait(0.01) in the serverscript.

[AC_Starmarine]

some exploiters/executors are insane and could load in the client before they even are officialy “joined” in the game

[ScriptedSuper (Scripted)]

That script should still be able to defend against some exploiters. Something is better than nothing.

[DogGuyTheThird (Fettuccine)]

Yeah. This guy showed his synapse auto inject feature that injects even before the game loads

[AC_Starmarine]

I see it’s good to have some protection but sometimes the false positives are to risky.

[Quwanterz]

There is no perfect server anti-cheat in a game. Every anti-cheat has its own advantage and disadvantage, with much more disadvantage than advantage.

The reason why there are many local script anti-cheat is because of replication. There will be a delay in the communication of players and the server. There are also objects that exploiters will add to the game but won’t replicate to the server. Using a local script, you will see the client’s own perspective of the game. However, this has a disadvantage of the exploiter just deleting or disabling the script.

---

@AC_Starmarine Please send your solution in one message instead of a one-by-one.

@ScriptedSuper

Hmm, maybe something like this would work.

@ScriptedSuper LocalScripts are not replicated to the server. If you try to index an object in the server that only the client can see, it will be nil.

@ScriptedSuper

You see, the remote is fired as soon as the player successfully joins the game. So they can’t load their exploits that fast.

Also, just remove the script:Destroy() from the localscript and remove the wait(0.01) in the serverscript.

No, that isn’t how all exploits work. There are some exploits that load before the player can join or even their client loading.

[ScriptedSuper (Scripted)]

Well, the only way to actually defend against exploit injectors would just be to check the spikes in the client’s memory usage which has to be done on the client. So there’s not that much you can do except try to do some exploit checks on the client but those exploit checks are vulnerable to just being deleted.

[AC_Starmarine]

check the clients memory usage? that is not a good idea as little spikes in script activity could cause alot of false positives.

Unless your game is a 10000 player game, don’t worry about hackers.

[ScriptedSuper (Scripted)]

Yeah I know, which is very risky. I would use it in my game but I don’t want to falsely kick players.

[Quwanterz]

@DogGuyTheThird Anti-cheat in the server is a very broad topic. There will be ups and downs.

Instead of worrying about exploiters, worry about the logics and system that you will add in the server. Every mechanics in the server should be secured, e.g shop system, communication between server and client, and many more.

There will be a lot of false positive when making an anti-cheat. If you focus on making an anti-cheat so much, you will ignore that mechanics you want to add to your game.

[AC_Starmarine]

Any client-side check can be bypassed no matter what. Maybe add some sanity checks in your remotes to see if what the player is firing is even possible in your game. Also add fake remotes like GetAdmin and if you fire that it will ban the player because it would only be fired by a hacker

[DogGuyTheThird (Fettuccine)]

Any Idea how I can Prevent them tho? Like you just said. More protected and secured scripts and remotes. How can I do that?

[iiPotatoFlamesii (poto)]

This doesn’t matter. A “perfect” anti-exploit is never going to exist, because the client will always be able to delete and edit things, regardless of what you do. Also, this won’t work at all in the first place, as you assume they’ll just be deleting scripts. They don’t need to delete scripts, and many exploits have the ability to disable connections entirely, making your method of checking when the child is removed pointless because they can disable it and then remove the script.

[maturegotit (MGT)]

@ScriptedSuper

Well you can’t really do that much against exploiters deleting a localscript. Maybe you can use the script below and make 2 of it just in-case an exploiter deletes one of them.

-- MAKE 2 SCRIPTS OF THIS AND PUT IT IN StarterPlayerScripts!!
script.Parent.ChildRemoved:Connect(function(obj)
if obj:IsA("LocalScript") or obj:IsA("ModuleScript") or obj:IsA("Script") then
game.Players.LocalPlayer:Kick()
end
end)

This won’t work at all (if the exploiter is smart). It’s more complicated.

You need to make detectors for different exploits like speed, teleporting, no-clipping, etc. For things that cause a faster change in position (like speed and teleporting) every second, you should check and make sure all the players’ characters are moving at around the set WalkSpeed. For things like no-clipping, you can create a Region3 around the character, and detect if an object is inside of it.

edit:

Hmm, maybe something like this would work.

-- Note: Make a remote in ReplicatedStorage named GetPlayerScripts
-- SERVER SCRIPT (PLACE IN SERVERSCRIPT SERVICE)
game.Players.PlayerAdded:Connect(function(player)
local playerscripts
local success, err = pcall(function()
playerscripts = game.ReplicatedStorage.GetPlayerScripts:InvokeClient(player)
end)
if success then
wait(0.01) -- exists so that you don't get kicked once the script that fired the remote gets destroyed
playerscripts.ChildRemoved:Connect(function(obj)
if obj:IsA("Script") or obj:IsA("LocalScript") or obj:IsA("ModuleScript") then
player:Kick("You trying to exploit or something?")
end
end
end)

-- LOCALSCRIPT (put this in StarterPlayerScripts)
game.ReplicatedStorage.GetPlayerScripts.OnClientInvoke:Connect(function()
return script.Parent
end)
script:Destroy()

@ScriptedSuper , this won’t work at all. If the client is adding or removing a script, the script will not replicate to the server. Therefore, this won’t work either.

[DogGuyTheThird (Fettuccine)]

Yeah today ive heard about honey pots but cheaters will run every remote event just to make some weak script they will sell for 20 dollars

[AC_Starmarine]

Don’t ever have any thing like money handling or inventory handling on the client. Never give the client access to a system you want strictly on the server.

[DogGuyTheThird (Fettuccine)]

things that I can put on the client like… A shift to sprint or jumpcool down?

[AC_Starmarine]

sure. clients can set the position of the player anyway because the client has network ownership(can control physics and locations) of the character.

[iiPotatoFlamesii (poto)]

Mostly, you won’t be able to prevent them from exploiting the game. The best you can do is secure all of your remotes, and make an anti-exploit that prevents them from going faster than the game allows them (e.g checking the distance moved within a certain time frame, if they jumped several times while never touching the ground, or as maturegotit said earlier, using region3 to prevent noclipping). A server side anti-exploit will only work against stuff that updates to the server, and you really can’t do anything other than that.

You can try to use the Stats service, and check for any spikes from the client which would likely be from injection, but that’s not a 100% method since anything can cause memory spikes.