Help with an Anti-Cheat system

Help and Feedback Scripting Support
#23

No, I mean that if the ModuleScript is in a location that is replicated to the client, they could read and find vulnerabilities

#24

Not if the module is 100% server-sided (required by a serverscript only).
More information can also be found here:

3 Likes
#25

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.

#26

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
#27

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.

#28

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
#29

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.

#30

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
#31

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.

#32

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
#33

I could just do

Script1:Destroy()
Script2:Destroy()

Done. No anticheat anymore

2 Likes
#34

I know you all already have discussed it but to summarize:

  1. 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.
  2. 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
#35

As i have mentioned before, one of the scripts will always detect the other being destroyed. Your code simply doesnt destroy both fast enough.

#36

it does lol. and also you can just time out the game and delete it that way.

#37

hook my friend hooks are your enemy

hook are there friend here eze bypass

#38

Client based anti cheats will most likely clear most of the skids.(didn’t mean to reply)

#39

can’t you just use ancestor changed or just property changed
I mean you can hook task and make it wait forever whit out even having to bypass it
same for property changed

#40

I use to think like this but skid will use copy pasted script good dev will just bypass it in there script by default if your game populat enogh.

#41

Thing is, good devs will most likely make their script cost money.

#42

skid one-day skid every day they will beg dad for the money

joke aside you really should not think like that it only takes 1 free release and boom everyone has your game at their mercy

1 Like