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.
the client has the access code, aka this wont work.
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.
You’re better off securing your remotes, instead of having some “remote encryption.”
I believe a much better and easier solution has already been made: Rate limiter module for Remotes.
You should be running checks for everything sent from the client on the server, and use this module to prevent Event spamming.
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.
Don’t forget them code review bots.
Don’t forget, obscurity is not security! Never rely on obfuscation in production code (and if you’re doing it in development code, why?)
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.
I’m pretty sure decompilers beautify the code so you are wasting your time if you use something like this Lua minifier.
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.
I know, lol. I have just seen some people using that and thinking it does something, which is why I said if you use something like this.
Exactly what I mean. It just makes it harder but you should not put something like a roblox cookie or server details there.
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.
Don’t rely on client for everything, animations, tweens are fine on client but if you are doing important statement checking, do it on server instead.
and, obfuscation is not a good solution for the long run.
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.