What’s stopping them from just recreating the client-side security, but just getting rid of the security part of it and just responding to any of the server’s requests?
To Correct you, exploiters can get ModuleScripts in places like workspace and ReplicatedStorage because they are replicated. They can read them.
2 Likes
You can lmao Ripull used one and 3dsboy bypassed it
1 Like
Of course they can read them, they are replicated to them.
Everything that is replicated can be accessed by them.
However, to correct you: They cannot access the bytecode if required by a serverscript, since it’s not replicated to the clients.
Not sure what you’re trying to point out here.
No, I mean that if the ModuleScript is in a location that is replicated to the client, they could read and find vulnerabilities
Not if the module is 100% server-sided (required by a serverscript only).
More information can also be found here:
3 Likes
The hacker will not have enough time to destroy both at same time without one firing, basically 1 nano second makes difference.
Here’s an example:
I have created 2 scripts inside workspace
The code for first Script:
workspace.ChildRemoved:Connect(function(part)
if part.Name == "Script2" then -- checks if second script gets destroyed
print("YES")
wait(0.01)
print("1")
wait(.1)
print("2")
wait(1)
print("3")
end
end)
Code for second Script:
wait(2)
workspace.Script2:Destroy()
-- the order here does not matter, since both scripts in your case checks for eachother.
workspace.Script1:Destroy()
If you run this, output will be just “YES” - even though it will have time just for 1 line, if you replace the print with RemoteEvent:FireServer() it should have time to fire.
What you didn’t think of is that they can disable the script(s).
They can also hijack connections.
And, even if they decide not to do the above, they can just remove the scripts before the other script even notices it.
3 Likes
To detect disabling the script, we can just use script.Parent.Script2.Changed(), also the script will notice it, since as i have mentioned - second script will still make output even after it’s deletion with the first one (also in second script - the one which deletes both scripts - it firstly deletes itself and then the first one. About the hijacking connections, i have no idea what you mean about that.
Actually about the disabling idk now, i’ll test it.
To detect disabling the script, we can just use script.Parent.Script2.Changed()
No. Your scripts won’t have time to react if an exploiter decides to get rid of your scripts.
You should do the logic on the server, NOT the client.
Anything that’s client-sided can be bypassed.
1 Like
I have just tested it, it still prints “YES”, meaning it still had time to detect other script’s changing + printing it. 2 lines of code + maybe it also waited 0.002 seconds.
Script 1:
script.Parent.Script2.Changed:Connect(function()
if script.Parent.Script2.Disabled == true then -- checks if second script gets disabled
print("YES")
wait(0.01)
print("1")
wait(.1)
print("2")
wait(1)
print("3")
end
end)
Script 2
wait(2)
workspace.Script2.Disabled = true
-- the order here does not matter, since both scripts in your case checks for eachother.
workspace.Script1.Disabled = true
Also both are server-sided scripts.
Also both are server-sided scripts.
It won’t replicate, everything the client executes is client-sided.
Nor will they be disabled / removed, because the server-script won’t know that the client even edited it, as it doesn’t replicate.
1 Like
What won’t replicate? This is just an example of a script having enough time to do something. To actually kick player, instead of printing “YES” it will Fire a remote event, which will afterwards be detected by server-sided script, which will kick player.
As much as I’d like to write something long regarding this topic, I won’t.
All you need to know can be found here.
Updated documentation link: here.
Never trust the client.
However, most exploiters have no clue on what they’re doing, in most cases a client-sided anticheat can be helpful at times, but that won’t help when the more experienced exploiters decides to play around in your game(s).
2 Likes
I could just do
Script1:Destroy()
Script2:Destroy()
Done. No anticheat anymore
2 Likes
I know you all already have discussed it but to summarize:
- Any sort of localscript magic you do can always be bypassed. Don’t try to put an anti-cheat on the client because it will always be removable.
- If you want to make an anti cheat, do it on the server. For example, if you want to check the position of the camera, have a local script send over the info, and then handle it on the server. E.g. check if the camera movement is snappy (aimbot). But remember, they can always send false values (e.g. (0, 0, 0)) so always check that it is something valid (If the player clicks on an object that would not be possible to view if the camera was pointed towards 0, 0, 0).
2 Likes
As i have mentioned before, one of the scripts will always detect the other being destroyed. Your code simply doesnt destroy both fast enough.
it does lol. and also you can just time out the game and delete it that way.
hook my friend hooks are your enemy
hook are there friend here eze bypass
Client based anti cheats will most likely clear most of the skids.(didn’t mean to reply)