The server doesn’t even know that the expoiter enables disabling a script doesn’t replicate to the server.
However, you could constantly disable the script on the server. BUT this absolutely won’t do anything.
The server can’t stop client code execution, disabling the local script on the server won’t do anything.
So basically the best practice is to never use localscripts IN THE CLIENT for this stuff?
Yah, client side detection can’t really stop anything. Exploiters can stop any scripts running on their client.
I found an old but interesting post regarding the detection of disabled localscripts.
However, I guess there is no technique to protect localscripts 100%.
There’s just some stuff you can’t really stop from getting exploited if I’m being completely honest. Like an exploiter can just change the CClosure of the script that’s making it so they can’t completely freeze their Roblox Client. When it comes to exploiting your best prevention measures are just to make everything server sided unless absolutely necessary to be on the client. This system requires being on the client since Server Scripts don’t have RunService’s “update” functions and events due to the server not really caring about it (even though it technically could, Roblox decided it shouldn’t.)
In this case however, it seems like you guys are overthinking the possibilites instead of the reality. No matter what you do, your projects can be exploited in certain ways. Stop trying to make the “most secure anti-freeze” script as even if you could, would all that hard work even matter? Someone will just make a completely new function to end up bypassing whatever security measure you just made.
This quote sums up what I’m trying to explain. Don’t over-complicate a system that doesn’t need to be complicated. Sure it’s flawed and can do with adjustments, but trying to make it a high grade prevention method is just oversight.
However, the client can setup their own remote function which returns a value. Bypassing the fact that the remote only works if the script is enabled.
For eg:
Client deletes the actual script:
Runs a script which sets up a listener to that 'disabler checker 'remote, here’s a pretty easy bypass of that system.
game.CheckerRemote.OnClientInvoke = function() --return some value end
Not even. They could just simply prevent OnClientInvoke from returning anything and cause the thread that invoked the RemoteFunction to hang. Typically why you will almost never see OnClientInvoke/InvokeClient being used. There is always a manual two-way remote communication going on in that case or use of coroutines.
I’m actually very surprised this post is still up and available.
There doesn’t seem to be any reliable way to detect freezing. A WindowDragging event similar to UserInputService’s WindowFocused/WindowFocusedReleased events would be very helpful.
