I know that you can create indestructible behavior in code by creating a spawned function in a script that destroys itself or also do that in a module script being required by a local script. You can learn this kind of context behavior here.
What does this actually mean to exploiters in comparison to easily dealt with client-sided anti-exploits? I doubt you can make indestructible client-sided anti-exploits so couldn’t they just break this anyways?
Code still stays in memory, most exploits can still access it - the LocalScript object isn’t tied to the code.
So even if you destroy the script the code will still run in a thread, just won’t be displayed in the viewing tree.
Just don’t try hiding scripts to stop exploits.
Read this reply: How do i stop Exploiters from attacking my game? - #6 by Autterfly
So they’d easily disable it right? Is it necessarily any different from local scripts that aren’t destroyed?
Most exploits have a way to get nil instances in the game. For instance, this is taken from documentation from an exploit that I found with a quick google search.
So even if you delete the script it can still be found by calling this function, and then some exploits that can decompile can easily read your code and then find what it does.
The thing is, destroyed instances aren’t the same as nil parented instances, they’re locked and can’t be recovered I believe.
It’s basically just code from a script that is locked to nil parent.
I was going to ask someone I know to test it, then I realized one crucial thing. They have a script that can see the localscripts in ReplicatedStorage, ReplicatedFirst, or anything the client can see. So even if you destroy it when running it. They can still see the script in the place it was originally.
Edit: I’m using a version of DEX that I put in my game to test it. You can see that the script is there in StarterPlayerScripts still. (I used YeetScript in this example)
This is probably a horrible method but you could make a local script to check if another local script (which houses the anticheat) is disabled. If it is disabled then it could ban the player.
Again, probably a horrible method, but it will get the job done for the first few bans or kicks.
I will never assume hiding code solves exploits and never have but I want to know how differently an exploiter deals with this in comparison to a normal undestroyed local script? Will there actually be no difference of which you do?
I’m just curious, I don’t actually rely on client-sided anti-exploits of course.
Hiding the anti cheat scripts will probably get the job done for a few bans or kicks, but in time, the exploiters will catch on to your method.
Add me on Discord and I can talk with you more about this. (I sent you a DM with my Discord)
But just know. For my test I did. I had this code
script:Destroy();
print("Destroyed script ran!");
And I asked someone I know to come in and test it with an exploit. And just by calling a function named getscripts() that their exploit had, they were able to get, and decompile it.
One thing I believe you could do as a safety measure is have a loop running, and checking the Disabled status of the script. And if it changes, then fire the server and ban. Because there shouldn’t be anything else that can disable the script in your game.
I don’t need to know about anti-exploit client-sided solutions, I’m fine.
Thanks for telling us how it went with real exploitation.
