Recently, I’ve been working on developing an anti exploit script. I’ve used both server and client detection methods because some client values don’t replicate to the server.
I know that exploiters can easily delete anti exploit local scripts. However, its obviously better to include an anti exploit because some exploiters, who just download exploits, won’t know how to delete these scripts. That’s why I wanted to make this article on how to make the most difficult script for an exploiter to destroy.
I thought of changing my local anti exploit script to a module script, and then requiring it, as module scripts continue running even if they are deleted.
I have also been doing research on other anti exploits, and I’ve seen many alter the environment with:
Now, I know that it is impossible to rely on a client anti exploit script running cause it’s running on the client, and you should “never trust the client”. However, we can make it as hard as possible.
Any ideas/suggestions you can give would be appreciated, Tweakified
Yes, you should probably publish it as a module script, then require it. But there is no true way to hide your LocalScripts or protect them. Try to do everything in a server script with modules.
To make it hard as possible though, I’ve made my code in module scripts, and I’m trying to require them in a local script.
However, when I delete the local script which requires the module scripts, the module script becomes ‘unrequired’, basically it stops the module script. Is there any way to get around this?
You don’t need to hide LocalScripts as code on the client can stay in memory even after managing to keep the thread going and removing the LocalScript object physically.
What you need is a better client-server model that just minimizes the risk of having LocalScripts’ source be of any benefit.
Edit:
It’s definitely possible but that’s not something relevant to the the point I proposed, which is essentially not to bother hiding scripts.
Thats not possible as many of the values which anti exploits check do not get replicated over to the server, so we need a client based anti exploit. If you have any ways of getting around this please say.
I already know its impossible to guarantee that exploiters can not delete it. However, protecting it as much as I can through deleting required modules, etc, is much better than having a local script which is named “Anti Exploit”
What I do is I disable all local scripts I don’t need/while im not using them, and I also constantly check for un-identified local scripts so that I know the user isn’t executing something
There is not really a way to hide localscripts from exploiters. If exploiters do not have server access,then you can hide them in two services, but I do not know if that will run the script. These services are: ServerScriptService and ServerStorage. You can secure your localscript with obfuscation, but that doesn’t make your script fully secure.
In reality, the true best way to ensure that your AntiExploit cannot and will not be tampered with is by having it implemented solely on the server side. Although there are some caveats such as those which you mentioned, those can usually be implemented in a different way on the server (ensuring velocity stays under a certain limit, checking for Instances getting removed from characters for no apparent reason, etc.).
Some exploits don’t even use a LocalScript instance at all to execute code. I won’t be specific as to which one but yeah. I can provide an example in DM’s if necessary.
I do agree with this reply though
“Hiding” your LocalScripts is just a band-aid fix for lack of proper client <-> server communication.
I disagree, like you can’t check everything via the server due to replication. So you want a local script to check stuff as well.
I know you can’t rely on it, but its still useful to use. For example most fly exploits use bodymovers to fly. However, you cannot check that on the server directly. However you can on a local script.
True but again a client anti exploit is useful as most exploiters don’t know what they are doing and just download exploits from the internet and run them. This means that most have no idea how to disable these checks.
Again, I’m not saying the client anti exploit should be the first line of defence. However its worth implementing to detect those novice exploiters.
They can easily find nil instances by using this: Click here.
Another method (excluding nil instances): Click here.
All of this information is open-source, anyone who has access to the internet can bypass your LocalScripts if they want to.
Don’t waste your time writing a well-designed anti-cheat system on the client when it takes less than a few seconds to make it completely useless. NEVER trust the client with any information.
Exploits have a bunch of functions that let them access the client’s environment, like these ones:
getfenv() -- basically getfenv but for the exploit
getrenv() -- to access the client's _G and shared
getsenv() -- to access localscript environment
getmenv() -- to access modulescripts environment
debug.getregistry() -- to get the lua registry (aka getreg)
getnilinstances() -- get all instances parented to nil
Most exploits with getsenv() also have getmenv(), so changing it to a module won’t help that much.