I’m working on an anti exploit script. Since a lot of the exploits people are using in my game can only be detected through the client, I’m making this portion of the anti exploit client based. So I have a question, can exploiters delete this script?
wait(0)
local folder = Instance.new("Folder", nil)
script.Parent = folder
while wait(1) do
-- Anti-Exploit stuff here
end
The script creates a folder and sets the parent to nil, and reparents itself to the folder. From what I understand this shouldn’t show up anywhere in the explorer, so exploiters shouldn’t be able to delete it… right?
Any localscript can be disabled or deleted no matter how many strange obstacles developers will put in place. Sure it may slow them down, but as soon as one smart guy figures it out, he can just distribute it for script kiddies to use.
Unfortunately exploiters can access and delete your LocalScripts, no matter their location. They don’t need to find it in the explorer to delete it.
Even if this does appear to work on the surface, I would not count on it, as the script is still located somewhere, and therefore can be tracked down and removed by exploiters somehow or other.
I did a little bit of testing - it seems to work fine as long as you add a short (a RunService heartbeat wait will also do) at the beginning.
The reason why this might work is that Roblox’s internal order goes as follows:
The player loads in, along with the LocalScript.
The LocalScript runs, starting a thread that runs perpetually. The script is then set to a folder, which is parented to nil.
The objects are destroyed, but because the code itself was not disabled, it continues to run.
This seems to be the behavior, because using :BindToRenderStep and :UnbindFromRenderStep, I was able to stop the function from the client-side console. Using a while wait() do (not recommended) loop or a heartbeat loop without a variable would likely make it more difficult to track down and disconnect.
I wonder if this is how backdoor scripts hide themselves during runtime as well? This seems to be a very clever way of hiding something.
The script is also not visible to the player through the explorer, nor can it be found through the console (which is the pseudo “exploit console” that I usually use to check for holes).
For OP, I’m not sure whether or not this is the best idea to use this (Roblox may interfere with it due to nil setting, it might be spottable by an exploit before the player loads in) and I would recommend server-side checks instead, but I guess it couldn’t hurt too much.
Setting a instance to nil is a old trick people used to use to try and hide scripts. Its basically worthless now because exploits these days have access to tools that can view scripts that have been parented to nil.
There are “other” ways, such as call a remote function to make sure the local script still returns, or use another local script to check for the first, and use the first to check for the extra local script. But they are all bypassable.
Also, I dont know if this was just coincidence, but when I used two local scripts and detected when the other one was removed in each script, even when I remove them both at the same time it would detect. So that could be a possible get-around.
Exploits come with some variation of a function that returns an array with all the elements parented to nothing. There’s not much that can be done about it, since it’s custom non-Roblox functionality.
@mc3334 there are no workarounds. Scripts can be disabled by exploits without being removed.
