Someone already tried to hook, in my test game, and none of the hooks worked, with every single executor.
You can’t stop hooking, It’s pretty much undetectable, even when you connect every single object in the game and look for changes, there are some hacky way to detect them, but most of the time they are unknown.
It’s a temporary solution, as with every other method described throughout this thread. Actors will be bypassed and certain currently unreleased executors already do. If it’s only temporary, it’s not good enough, and when I say temporary, I mean it will be completely redundant, not that it will need to be updated.
Synapse already bypassed actors, with their run_on_actor, but fortunately, It requires an instance, and since the instance gets destroyed, and It doesn’t even have a name, assuming that you’re using the nameless method, so It doesn’t show up in script memory, I guess It’s literally the best method rn without doing these hacky ways that can kick innocent people, the best thing exploiters can do rn, If I had to guess is to get every single thread and somehow get the threads that are made by local script and stops them (Even then, handshake should still work, and It should still kick them), I think handshakes using this method only works with remote events, and not remote functions
What about obfuscation? Can we try that?
Obfuscation, isn’t needed on this method, since It runs faster than executors, the only reason why the test didn’t show up as 0, It’s because It’s doing the getfenv() process, and It only prints after It finishes it (It’s still stupidly fast), so we can confirm It loads before the game starts, ofc If you add services and stuff on the top, executors are going to be probably faster than the script, so you need to make sure to add the getfenv() on the top of the script just to be safe, I don’t know if the loading is different in big games, since most anti cheats test are done in a baseplate, Obfuscation is only needed with scripts that don’t hide themselves and stay in the game environment as normal, or to protect your code from being stolen, and since the executor’s decompiler aren’t even accurate at all exploiters need to fix the problems to have a fully running script, which will be pain If I had to guess.
You can go and obfuscate if you want to make sure that exploiters aren’t stealing the code, but again It isn’t needed, at least on baseplate games.
Fun fact: Remote Spies don’t work with actors 
To prevent that, I think you could just set their pos on server to their pos when they were kicked when they move to prevent them from doing anything?
I meant they do get disconnected from the server, exploiters can remove the kick GUI, and still interact with their client, but they are technically disconnected.
Yeah, I was able to remove the disconnected ui, but not the blurry background. I will see if you could move your character by setting root part pos.
There’s another way of hiding the environment of the local script without using getfenv(), sadly I don’t know how to do it with debug.info(), and that’s by using module scripts, I figured this out, because if you try to destroy a Module, after requiring it, the module will disappear from the game, but will continue to work.
We can abuse this behavior to destroy the parent and module but keep the local script code running, you can do this by calling Destroy() inside the Module script, so the local script will continue to work as normal while having Its environment destroyed.
The first thing that you need to do, is to create a local script, I would recommend adding it to Replicated First, After adding the local Script to Replicated First, you must add a Module Script, I recommend parenting it inside the Local script, Anyway to call the Module Script, use this code, Place it at the Top of the local script:
local ModuleScript = require(script.MODULESCRIPTNAMEHERE) -- This will require the Module Script
script = nil -- This will make the script variable Nil
-- (I don't know how to get rid of the warning)
This will require the Module Script immediately, and set the script variable to nil, Inside the Module script, you can do something like this:
script.Parent:Destroy()
script:Destroy()
return nil
-- Added return, or It will throw a error
Anyway, this is pretty much what you have to do, I used this method, and It worked, let me know what you think, dunno if there’s a downside using this method.
the warning shouldnt even occur if you put your LocalScript into ReplicatedFirst
This is what you should do if your script is in ReplicatedFirst
script.Disabled=true
script:Destroy()
If its not inside ReplicatedFirst (gets cloned and then put somewhere else)
script.Disabled=true
task.delay(0,game.Destroy,script)
I think your method is good but you forgot one thing
- set localscript.Disabled to true (it makes so your code is not based on the localscript anymore so even if the script gets removed its still gonna run)
this is how I would remake your method:
LocalScript in ReplicatedFirst
script.Name=script.ClassName
script.Disabled=true
task.spawn(require,script:WaitForChild("Module"))
script:Destroy()
script=nil
ModuleScript parented under LocalScript
script.Name=script.ClassName
script:Destroy()
script=nil
--do something cool here
return nil
1 Like
Just realized, that you don’t even need module scripts lol, you can just directly call the Destroy() method at the top of the script, or do anything to the local script in general when It’s loaded.
Also, I found two ways to basically make local scripts basically impossible to decompile, the easiest way is to make it a server script with the run context to client, the other way is semi impossible, and that is to make a table that has pure garbage, and It’s extremely long, this will crash decompilers
You can use memory checks for scripts, this will 100% kick exploiters, even with a simple print("Hello world!"), It can also detect inject if they inject in game, instead of menu, the only bad thing is that when the player character respawns It triggers it, and you’ll have to add a check to make sure the game is fully loaded.
1 Like
Try it on some old devices and/or low-end computers, it will probably false positive.
There are ways to make them very specific and reliable but its less recommended.
2 Likes
From my experience, scripts remotes parented to nil fail to fire remoteevents. This may have changed though.
2 Likes
This only occurs if the remote is in nil
1 Like
It also happens with remote functions, if you do something like return
The scripts aren’t parented to nill, they are paranted to null which is something from C++ If i had to guess.
Also it only happens with Remote functions if you are trying to get something with return, remote events should work perfectly fine.
The only false positives that I have found are mainly on studios, since apparently selecting an instance with the explorer triggers it, specially if you select the local script for testing purposes.
I haven’t found any other one in game except for the character respawning and game loading, I think adding new local scripts might trigger it but haven’t tested it yet, I tested in both my pc and mobile, and nothing happened.
uh… it will run when u set the callback AFTER destroying.