Build Anti-Exploits on the client without the client deleting the script?

So what I want to do is keep my game clear of exploiters, my current idea is to make it on the client since I will be doing things such as checking for Velocity, WalkSpeed and a bunch of other stuff that would require loops but if done on the server would consume quite a lot of resources.

My Idea is to make a anti exploit script on the client and then have a remote function InvokeClient every 10 seconds or so and check if the anti exploit script still exists.

But then a counter would be to just delete the remote function so I thought:

What If I logged the last time a player was checked for their AntiExploit script? Here is a quick example of what I’m trying to do:

local PlayerLog = {}
local checkInterval = 1

game.Players.PlayerAdded:Connect(function(Player)

PlayerLog[Player] = os.time()

end)

while true do
wait(checkInterval)
for Player, lastCheck in pairs(PlayerLog) do
local scriptExists = RemoteFunction:InvokeClient(Player)
if not scriptExists then
PlayerLog[Player] = nil
Player:Kick("Missing Script")
else
PlayerLog[Player] = os.time() -- updates last check
end

if os.time() - PlayerLog[Player] >= 10 then -- if we didn't get a check return after 10 seconds...
PlayerLog[Player] = nil
Player:Kick("Was unable to access client")
end
end
end

So would this work? Are there any work arounds this system? Thanks for any feedback I receive.

2 Likes

There is NO way to stop the client from doing as they please.

Although very basic and simple protections on the client will catch out a large number of exploiters, you must still have good server-sided security.

Don’t try to check if the script is there, or run checks; it’s just moving the problem and an exploiter can easily bypass it.


I'd suggest reading this topic, it has a lot of useful details: https://devforum.roblox.com/t/exploiting-explained/170977
3 Likes

Could you tell me a way a exploiter would be able to bypass this method? I’m curious on how far I can take this.

Exploiters can do basically anything. They can edit the source of client-sided code without you knowing (so they can change the client so it doesn’t actually check stuff, but still fires the remote, etc.)

You should focus on making a good game experience while minimizing damage exploiters can cause.

I’d also suggest reading this for more details about how to combat cheaters.


1 Like

Completely Understand and I script most of my things to be a secure as I can possibly make it. What I’m trying to do is to create a Anti exploit for the client side (to avoid consuming a lot of resources on the server). I’ve read several topics on anti exploit and I understand how the client works. I was just curious on how someone would bypass this specific method.

An exploiter can delete your script and create a new one to handle the InvokeClient method.

1 Like

As said, the client can do whatever they want on the client.

i’m quoting a lot of things here, but it’s because this message is really important; never trust the client, anything can be bypassed.

2 Likes

What if I had something to re update the invoke client like a loop or something.

This is simply impossible. If you’re looking to stop exploits you should only ever do this from the server. I wrote a pretty in depth article on anticheats and I would recommend reading it or any other resources you can find.

Also, my justification for this is simply that any code running on the client can be stopped, redirected, changed, etc. It’s just simply impossible to rely on anything client side.

2 Likes

Exploiters can still bypass that.

If you use a sort of formula, you have to store that formula somewhere to keep the client and server in sync, and exploiters can still the formula there.

This is not an issue you can truly solve on the client.


Implement basic client-sided cheat detections, yes, it will catch more people than you notice; but you should focus on server-sided protections and sanity checks.

Being too strict like this will result in latency, bad player experiences, and many headaches.

Exploiters can bypass Player:Kick() and remote:FireServer() with exploit-only functions such as getrawmetatable() if done on the client.
If you want actual solutions then have your anti-exploits on the server.

Like everyone said, there’s no 100% way to protect the client.

What you should instead do is make exploiting as boring as possible.

yourScript:Destroy() 
remote.OnClientInvoke = function() 
    return true
end

If they disable your script, the loop will stop working. If it didn’t, they can spoof __newindex and block all your attempts to set the callback.

You could implement a return check to mitigate that, but then again, an exploiter can simply bypass the specific functions of your script, such as spoof WalkSpeed instead of deleting it entirely.

1 Like

This kind of question has been asked many thousands of times and the answer remains the same. If you try to fight the client on their own machine, you are losing. There are no “what if I”. The client can manipulate anything on its own end. Period, full stop. You aren’t going to win that battle.

I’m not going to say that it doesn’t matter what you do because you can always - after you fix your game first, please - attempt to make it more difficult for exploiters to get through for a period of time, but otherwise you’re going nowhere trying to make client-side anti-exploit. Secure your server first.

1 Like

Alright thanks, my server is actually already secured, I was just wondering if I could fix the client sided exploits such as Velocity exploits and etc.

I’m curious how blocking specific functions works with luau now? Before luau they could get functions by name (can’t remember the method that allowed this) but with luau names aren’t there anymore.

No, that only applies to local variables. Exploiters are still capable of hooking functions like game.Destroy or __newindex of the instance’s metatable.

The only thing which luau changed in that matter is the process of overriding globals like print or warn, since they are now cached in the individual function’s constants, so in order to replace them, exploiters need to change them there or call getfenv() on the function to deoptimize it.

3 Likes