Client Anti Cheats: Aren't as bad as you think!

With the right tools and knowledge it possibly could.

1 Like

It is technically possible, but most exploiters are skids so they don’t even know how to deobfucate, if exploiters can obfuscate their scripts, then so a local script can, the point of this is to make reverse as hard as possible similar to how BYFRON works, and main reason why they can’t add it to microsoft store version, because It’s code is obfuscated.

By obfuscating code you are basically protecting your scripts from getting stolen and so on.

This is only needed on clients anti cheats, server sides anti cheats bytecode stays on the server so It’s impossible to decompile.

1 Like

I did some test to see who is the fastest, using tick(), since os.time() gave me 0 in the result.
imagen_2023-08-26_134354227
As you can see, they execute the code really fast, actor seems to be faster even though It had another line of code, this is the code of the actor:

local x = tick()
getfenv().script.Parent:Destroy()
getfenv().script:Destroy()
getfenv().script = nil
local result = tick() - x
print("ACTOR FINISHED IN " .. tostring(result))

And this is the code of the “normal local script”:

local x = tick()
getfenv().script:Destroy()
getfenv().script = nil
local result = tick() - x
print("NORMAL FINISHED IN " .. tostring(result))

So we can confirm that actors are faster than normal local scripts, this isn’t really that accurate, because the Environment code executes before printing the result, and not right after it finishes.

1 Like

Doesn’t your benchmark show that normal is faster lol?

1 Like

The actor was the first script that printed the result in everysingle test.

1 Like

Oh well, it’s a bit confusing since normal had a smaller time

1 Like

I guess It’s because of that 5 in the normal result, in some tests they were really close, but actor was still faster, ngl I expected task.spawn() to be the fastest during the tests

1 Like

One of my friends could actually deobfuscate it (it is obfuscated with Luraph)

1 Like

For anyone still reading this topic, there’s a chance that your local scripts might get found in “PlaceScriptMemory” using developer console, this only happens if your local script has a name, and I have the solution.

Create a Server script in ServerScriptService, then copy and paste the code below:
Normal Local Script (Aka without actors):

local ReplicatedFirst = game:GetService("ReplicatedFirst")
local LocalScript = ReplicatedFirst:WaitForChild("SCRIPTNAME")

LocalScript.Name = ""

If you local script is using an actor, then use the code below:

local ReplicatedFirst = game:GetService("ReplicatedFirst")
local Actor = ReplicatedFirst:WaitForChild("ACTORNAME")
local LocalScript = Actor:FindFirstChild("LOCALSCRIPTNAME")

LocalScript.Name = ""
Actor.Name = ""

This will fix the local script appearing in “PlaceScriptMemory”.
(Dunno, if this is exploitable, but there’s it is)

2 Likes

Wow! This is useless!

Yes, that will still run, but RemoteEvents firing won’t, which makes your handshakes incompatible with this :smile:

1 Like

Unless player:Kick() actually works on the client, there’s no way to “punish” the exploiter if they are detected exploiting.

1 Like

A simple crash like this, is enough for any hooks for :Kick(), but again, for the 500th time: THIS IS NOT RELIABLE!!!

while true do
end
1 Like

Won’t this just crash the client?

1 Like

That’s the point, if you can’t kick the player then you can crash their game.
( From the client )

RemoteEvent firing does work? You are probably doing something wrong.

Try it yourself, I copy and pasted exactly like it is and the Remote isn’t firing.

There is a way to punish exploiters the intended way, aka using kick(), just use actors and basically the same code as before but make sure to add getfenv().script.Parent:Destroy(), if you use the regular method then just crash the player like the other people would normally do.

Using actors won’t suddenly make the metatable hooks disappear. If you can’t kick the player because they hooked “Kick”, they hooked “Destroy”, they hooked “ClearAllChildren”, and they hooked “.Parent”, then you can’t crash them either because they will find a way to prevent that.

We need to focus on how to stop hooking, before we do anything else.

Unfortunately, there is nothing you can do to stop hooking. Any hook detection you come up with will be bypassed, and usually quite easily.

I get that the point of this thread is to come up with ways to make effective client-sided anti cheats, but the sad reality is that isn’t going to happen within the scope of Roblox.