A synapse decompiler has been used to compromise my client-side code for a complex aimbot anti-cheat.
With the source code, I believe it wouldn’t be impossible to create a workaround.
Should I attempt to rewrite my anti-cheat? What can I do to prevent this happening again? Will the new LuaVM make these decompiled scripts harder to read?
You shouldn’t rely on the client for anti-exploit since it can be removed, the new luavm should’ve stopped exploiters for at least a bit. To prevent this from happening again, add a server sided check. You might want to rewrite it if it’s absolutely needed.
If you believe your anti-cheat was compromised, it would be best to alter it to patch any exploits that may be created to workaround yours.
However, theres a slight rule you should remember when creating anything thats on the client:
Dont trust the client ever
The new VM will add a layer of obfuscation when decompiled so will make it harder to read. However people can still figure this sort of stuff out. If you’re trying to make an aimbot detector for what I assume is a FPS game, I would listen (on the server) for any wacky character movement e.g. rotating 180 degrees super quickly and then getting consistent headshots. You could slowly build up a “trust” rating which on each “offence” is added to until the player is kicked, reducing the amount of false positives.
At the end of the day, your local scripts will be loaded into the client’s memory so they can decompile it even with the new Lua VM. So, I recommend handling all exploit detection on the server or just handling rudimentary checks on the client but remembering to not rely on them as the sole method of exploit detection.
I had to use the client as I was listening for inputs. It’s a third person game with shiftlock enabled, so the ‘wacky’ rotation idea wouldn’t work but it’s a valid point.
Couldn’t I use a closed module to hide my client-side code? Should I consider obfuscating my client code in the future using a plugin of sorts?
A closed module sounds like an equally as good idea but can’t exploiters just delete the exploit detection script off of their clients?
Anything thats on the client, the client can alter, change, delete, take, etc. You can’t prevent them from doing that.
(Have a script detect if another script was deleted on the client as well won’t work, they can just delete both at the same time 
)
Was considering running a loop in both the current client script and a new client script checking for eachother’s existence. I assume that’d prevent the deletion aspect.
Yeah, I had a similar experience with my gun system where an exploiter was able to (change?) my gun’s client script to where it was firing the damage remote multiple times, technically duplicating their damage.
Instead of making it client side, make it server side. Client side code is super easy to get access to, and bypass. Server side code cannot be read nor bypassed, Synapse X can only decompile Local and Modules.
Wouldn’t inputs on the server be delayed by their latency, and therefore be inaccurate?
You could fire the client, and then the client returns the input, and if you fire the client, and you don’t get anything back, then that means the person messed with the LocalScript that is helping the server, so you simply :Kick() them.
I believe this is fighting a losing war. An exploited client could return fake arguments.
It’d be useful to see a Roblox employee issue a detailed analysis on best security practices.
@Mr_Purrsalot
Any and all client side code can be decompiled, you cannot do anything to stop this. The code is loaded in memory and exploiters will always be able to access it.
Never trust the client, ever. Anything you do on the client can and will be bypassed in some capacity by exploiters, any checks that you want to be reliable will need to be done on the server. Sudden movements, high shot consistency/headshot rate etc. etc. Anything that you can think of that isn’t normal player behavior, then flag it. If a person gets a certain number of flags, kick them.
In short, the exploiter will always have the upper hand. Always. Do your checks on the server
Here’s good practice. As everyone else has said, don’t trust the client. Period.
After reading about your security, I cannot stress this enough. You are absolutely playing with fire trusting the client to do security checks. Your client-side code can and will be decompiled, even if you temporarily change it. Don’t even consider security checks on the client.
What can you do? You mentioned this game was a third person shooter, and players are using aim bots. Other people mentioned this, but you could figure out if someone was cheating on the server. In your case, I would probably keep track of all the damage a player does to other players, and if it seems like they’re doing way too much damage in too little a time, give them a penalty. I would certainly add more checks to that but I don’t know the specifics of your game. Hopefully that’s a good starting point.
There are so many ways to go about detecting exploits on the server. You just need to think more creatively. Good luck.
Probably not a good idea, some people can get like 29 kills a life.
He means in the matter of seconds, if someone gets like 5 kills in 4 seconds, something isn’t adding up.
Unless there’s a crowd of people standing and you backstab 5 of them with a knife 
A knife, not a weapon. We are talking about aim bot, aimbot works by making the projectiles go towards a person’s head in example.
To add on to what @Kensizo said (which is precisely where I was going with that), I also said “I would certainly add more checks to that but I don’t know the specifics of your game.”
I wouldn’t just blindly assume someone is exploiting based off one single factor. My suggestion is just a high-level starting point that can be applied to any game. Edge-cases like these will occur when you make an anti-exploit, and it’s up to the developer to implement a suggested method in the best way for their game.