The exploiter could just make another script to get the key?
Wasting a lot of time on a client-side anti cheat is a waste of time and should and only has to be mediocre at best. Client side will stop some hackers but the determined ones will easily bypass it. Remember exploiters have a control on the client that is so deep that it’s crazy. Also exploiters can litterly bypass the kick function on the client by overriding the metatable for it.
2 Likes
They cannot delete a server script service script, I think this would be your best bet If you needed a proffesional anti exploit (Server-Sided, Client sided) You should check my anti exploit Its called Anonymous Anti Exploit
This is very true! And also He can edit and re-run the anti cheat as there own version!
The best anti-cheat system you can ever make is to never trust the client.
Do all the logic on the server.
Exploiters can bypass anything that’s client-sided, and anything that is replicated to them.
Serverscripts and modulescripts required by one, is safe, as their bytecode is never replicated to the client, regardless of where it is located.
3 Likes
well when you actually use my remote event anti-cheat then they cant
Just gonna destroy the player’s ping?
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.