I’m about to make it. But I need to make sure this kind of anti-exploit can actually stop events being fired by exploiters. Here is my way:
There is a access code in the sever. If a localscript want to fire an event, it needs to provide the correct code in order to fire it. And the access code will be changed every second.
I’m pretty worried that exploiter might be able to see what’s inside workspace/serverstorage.
Exploiters won’t be able to see contents of ServerStorage unless they have server access. They can see workspace though. They are able to see localscripts content, but not server scripts content. Hope this info helps.
Unfortunately there is no way to prevent an exploiter from firing remotes. An exploiter is allowed to see anything that is loaded onto the client this includes the bytecode for the localscripts and modulescripts that are given to them. With the bytecode they are able to see exactly how the localscript or modulescript works. My suggestion would to do some sanity checks such as checking if the amount there firing the remote is excessive.
verifying if remote event calls with a password, is very unefficiant, due to the client being able to see everything on the client, and I mean everything.
The client would have to fetch the access code somehow so I suggest you use something like Iron Brew so the hackers/exploiters have no clue how to get the code.
Hope this helped.
Yes don’t rely on it, but that doesn’t mean it won’t increase difficulty in reverse engineering your code. You’ll never be 100% secure, but you can make it harder for them to find it. I don’t obfuscate but I see its merits as valid.
Thats not a obfuscator. Those tools are not meant to obfuscate, but to make the file size as small as possible. Its extremely common for JS frameworks.
Obfuscation through obscurity is not true security; I’d could be helpful to add it to prevent ‘skids’ from doing anything, but it should not be relied upon.
Just have the client be unable to command the server; the server should have the final say on everything.
First of all the exploiter could get the access code. Also, if you changed it every single second, clients with a high ping (>1000ms) would not be able to use the id in time.
This is called a “key” system, which I do not recommend.
Key systems are easily beat by exploiters as they have access to everything the client normally has access to, in addition to malicious methods that can read code and memory values.
I would instead just attempt to do server-sided protection that completes sanity checks.