What makes a Client Side anti Cheat safe?

Hello Developer forum, I have a few questions and need your opinions on them.
And or responses.

So what really does make a client side anticheat safe?

I was thinking of making a client side anticheat (One time thing, I dont usually do client side and wont continue it if there is any way for it to be bypassed)

But I was thinking of having the name on a “While true do loop” and make the name repeat through a 15 text/Number/Hidden Symbols mix.

Would this be safe though? Why or why not?

4 Likes

Initally, it may work. However it wouldn’t take overly long for someone to realise and find and delete (or modify the anticheat script) so that they can continue to exploit

7 Likes

They aren’t safe, anything on the client will get exploited eventually. Sooner rather than later.

6 Likes

Nothing in the client will ever be safe, however It’s important to sometimes try.

Idea: However I have found some things that are really helpful for the client. An example is I keep 2 client anti-cheat scripts, One to keep the anti-cheat in check, other to run the anti cheat normally. What I have is a remote event connected to both anti cheat scripts, and check to see if one of the anti cheat’s is deleted. The second that happens it sends a request to the server and I have that remote event send everyone to a different server. However I auto-ban the client that tried to delete the client script (I don’t perm ban, as possibly an exploiter could remove this script from other clients), Save the logs & send them to review, and then decided for a full ban. Now can the client bypass this? I haven’t seen it happen, but I am sure that a way can be developed. It’s not 100%, but it’s the best I could think of.

For what your doing no. Exploiters don’t need a name of a script to delete it. It wouldn’t be safe really. And wouldn’t make a difference

1 Like

Nothing. A client anti-cheat will never be safe.

4 Likes

Honestly randomizing the name won’t do much, but if you parent it to nil at the top of the local script it’ll stop exploiters from being able to call : Destroy() on it

Exploiters can only edit delete scripts from their client and nobody elses

1 Like

The method of getting the client to send messages to the server doesn’t really work due to an exploiter just being able to disable your script from calling :Fire server() and then setting up their own system to send messages to the server making it think that everything is ok

3 Likes

How could an exploiter do that? Unless they have access to their individual devices directly.

It won’t actually stop that, but it won’t matter either way. It’s trivial to delete a script using third party tools like Cheat Engine.


Ultimately it doesn’t matter how secure you make your client side security. It’s not needed and you’re wasting time. It doesn’t take long at all to set up proper server side security, and then when you’re done with proper server security that’s all you need.

2 Likes

The problem and solution with client sided anti cheats lies in the fact that it will be client sided - meaning it would be easier to catch injections and cheaters attempting to run scripts. However at the same time it would be a disaster, as cheaters can further manipulate the client and somehow circumvent the client sided anti cheat.

Would be a great concept in theory, but incredibly difficult to maintain in practice. This would also require a bunch of server-side validation to make sure that the client anticheat is not being tampered with in the first place.

2 Likes

Nothing

At the end of the day, the exploiter will probably figure out how to bypass it.

But it’s good to make it as hard as possible to break or work around because that will demotivate skids (new/dumb exploiters) from trying to hack in your game.
Good exploiters might figure out how to bypass it, but they might get bored of having to do that everytime they play.

Here’s a few things I know:

  • Very long scripts cannot be decompiled. (7k+ lines is my guess)
  • Objects parented to game aren’t visible in Dex Explorer (might be patched).
  • Objects parented to nil can still be seen in Dex Explorer.
  • Most exploit guis are parented to CoreGui.
  • F3X building tools scripts have their guis parented to PlayerGui.
  • User input events don’t fire when focused on CoreGui.
  • Global variables and strings are decompiled exactly as they are. This is why storing passwords or some sort of code on the client is a bad idea.
  • New Luau features like type checking and string interpolation could break the decompiler until it’s fixed. I have a feeling string interpolation would just show as string.format or something, wouldn’t actually break it.
Decompiler Example (from what I remember)

Just to clarify, the decompiler reads the bytecode and not some sort of obfuscation of the local script.

Example script:

--\\ Song Compiler

local function Init(song)
     local new = {}
     new.BPM = song.BPM or 120 -- Just incase
     new.Notes = {} -- Will add notes later
     new.Name = song.song.name or song.name
     return new
end

function Load()
   if SongSelector.Opened then SongSelector:Close() end
end

--\\ TEST (Remove)

local song = require(game.ReplicatedStorage.Songs.Test)
print(Init(song)) --> {...}

SongSelector:Open()

Decompiled:

local function u1(v2)
     local v3 = {}
     v3.BPM = v2.BPM or 120
     v3.Notes = {}
     v3.Name = v2.song.name or v2.name
     return v3
end

function Load()
     if local v5.Opened then
          v5:Close()
     end
end

local v1 = require(game.ReplicatedStorage.Songs.Test)
print(u1(v1))

v5:Open()

They can still get all instances parented to nil with getnilinstances, and the instance can also be retrieved through the script itself.

The exploiter can simply delete the remote event. I’m also pretty sure remote events don’t work when parented to nil anyway.

What? They can only change their own client.

Under 30 letters, how? The rule exists to ensure your post is meaningful and contributes to the conversation.

Summary

If your learning to script, don’t bother with an anti cheat yet. Eventually, learn what not to do on the client and what not to do on the server.

If your making a game you want people to play, an anticheat can only help stop bad exploiters. (hopefully roblox’s new anticheat will help even more)

If you think an exploiter can bypass something, they probably can.

1 Like

Well all they have to do is hack the server to add the scripts or remote events. There is many exploits that add things to the server, so adding a pathway to the server, an exploiter can go from their client, to server, to another client. Now is this rare? Yes it is. But it can happen.

Which exploits in particular can add objects to the game’s server? That would seem like a security problem/a game developer oversight.

AFAIK, there aren’t any exploits that add objects to the server without some kind of backdoor that was inserted by the game developer.

1 Like

Well, yes. But then you’re screwed anyway. They can cheat just about anything including modifying the DataStores to set them to win.

I have thought of that. I do check for this, and it’s hard to expain, but it’s almost impossible to delete my remote events. I can show you a video of me trying to delete them.

But what is the point? What security do you gain from preventing the exploiter from deleting RemoteEvents?

It may seem bulletproof but believe me that script that keeps them from being deleted can also be deleted. Do you have another script making sure that other script isn’t deleted? They can just stop execution of both scripts and then delete both of them.

Really not that useful in the long run.

4 Likes

Yup. They are more likely to do that then anything else. And I have systems for that. But I don’t want there to ever be a false postive, so I like to look to be sure.

As explained above in my first post. I have 2 anti-exploiter scripts to keep the other in check. When one script is deleted, it fires a remote event to shutdown the server.