You should not have a problem with admin hacks.that’s why this was not covered. If you have a problem with admin hacks then you have used a free model. Try to avoid this and great it yourself! If you need help them just watch a tutorial! Reply if you need a link or have questions about other ways of hacks. (There a some ways people can hack and CREAT admin. I will cover this if y’all want)
NOT my WRITTING
LuaC refers to the Lua API in the C language; Roblox embeds their version of Lua through C which allows games to actually run Lua scripts and is exploited to achieve Lua script execution with external programs. LuaU, Roblox’s new lua VM, removes debug information and restructures their old bytecode format to make it harder for exploiters to actually exploit games.
Best thing I’ve found about what we can do is possibly kick the player if there’s any new GUI added into the workspace with a specific name that each executor might have using FindFirstChild and other methods which I do not want to disclose as it could very well neutralise my anti-exploit, me and my fellow programmers were working on that and have accomplished in kicking players using Protosmasher and Synapse X from the game.
Of course for this method, you will need to actually own those exploits and test them and analyse their working methods to get this done, but I guess it’s worth spending 50 USD as it could very well determine the success of your game/group on a whole new scale by reducing the number of exploiters on a notable scale.
Despite ROBLOX doing their best in their ban waves and methods of spotting an exploiter, every developer has to personally make changes in their game and make sure all the remotes and scripts are protected in a way they can’t be tampered with. Most of the exploiting occur due to unprotected remotes and datastores in the game that are exploited to the exploiter’s needs.
Instead of looking and working for an anti exploit, try and create a safely protected game.
The anti exploit part comes after you have a proper air tight security in your game / places.
[ For those who don’t know what Protosmasher and Synapse X are, they are the most famous and effective paid exploits on the internet. ]
Yes they can. Most of the exploits come with a debug library which allow the exploiter to understand what script say.
Thank you so much my friend, this has helped a lot of people. Thanks for this great content 
Ah, I’m aware of LuaC - I just didn’t identify that’s what they meant with the capslock 
From what the user was talking about (comparing Lua to “LUAC”) I suspect they were referring to Luau.
In regards to Luau, it doesn’t make it any harder for exploiters - they’ve had no real impact due to Luau except the removal of variable names from their decompilers.
Yes I agree, it is kinda fishy, not to lie.
I must admit, I’ve been involved with backdoor removals quite recently, I’ve started to see a trend of backdoors which seem to look similar in appearance to Lua-C, which sometimes are loaded with an API for Lua-C alongside the backdoor payload itself.
Lua-C from what I understand, primarily looks like bytecode, meaning that it’s possible the backdoor I saw recently was either that, or some other form of obfuscation, although I have asked friends of mine and they’ve said the same I did, in that it isn’t obfuscation.
I just thought of this now but could a exploiter be able to bypass FE and be able to take the whole game or it will be not even possible?
Wow, I’ve read this thread before any posts have come here and after some long time I see like 50 thousand posts here.
I didn’t want to make a whole thread about this, but I thought about the whole concept of “Client Sided Checks”. Basically, you make a Local Script as an anti exploit so you can detect exploits from the client side. But, the thing was people can just delete that script, and kabam it’s gone. But, I’ve been thinking about this for a while: what if be set the Archivable property to false(it wouldn’t be false at first, but it sets the property to false in the actual script)? Wouldn’t that stop the script from getting deleted?
This is about what it would look like:
script.Archivable = false
-- Rest of anti-exploit script
An answer would be great!
Nah. It only stops its instance from being cloned. Even then, the property can be set back to enabled. If it’s on the client it can simply be bypassed one way or another.
Yeah, exploiters can delete/edit and rename a script from a game but the changes are only local to the player.
It’s not about getting kicked for deleting scripts for the whole game, no exploiter can make any change to the server thanks to filtering enabled.
EVERY change is local to the player and if you want to kick a player messing with the scripts have a separate script checking for the presence of the scripts and kick when the value is false.
I probably don’t know what I’m talking about here, but I did a test of client sided anti exploits a little while ago and found success with having two scripts: one that was the anti exploit, and the other being a checking script. Both scripts contained code checking if the other was moved, renamed, deleted, etc. When I tried doing something like removing both in one command line the other script would kick me before the next line of execution could start (which was deleting the other script). Inside the script you could keep references to certain instances without using something like script.Parent just to be sure that the script would be unaffected if successfully moved somehow. And the only weakness I can think of is if the exploiter ran the deletion code before the scripts got references (that don’t use script.Parent) to each other. This, I’m assuming, would be hard as the code would be run in PlayerScripts.
How would you bypass this? Am I missing something?
You can bypass this by just stopping the scripts. Exploits can force both scripts to error at the same time, yield forever, or just completely stop. It’s a losing game.
That makes sense. This would be such an easy solution otherwise. Another question: how can they make the scripts yield forever/error/stop?
There are many ways. Common ways you might see would be overwriting variables the script uses, whether global or local. Constants can also be swapped or changed completely. Hooks can be put into place so when your specific script or maybe even all scripts attempt to access something in the DataModel they get met with the wrong or manipulated data.
Ah, alright. Another follow up: is it worth doing the method I mentioned but not relying on it? Personally, I’ve never heard of this method and I may be underestimating the amount of people that know about this, but if you were to implement this as a non-necessary additional layer of protection from the people that don’t know how to stop the scripts (again, I may be underestimating this) it would be quite useful for stopping (I’m guessing) a large chunk of exploiters.
Sure, absolutely don’t rely on it. Make sure it’s only aimed at exploiters, won’t hurt general player base, and that you don’t spend too much time on it. You’re making your game for the players not the exploiters.
Amazing post, very descriptive!