Exploiting Explained

Never mind, I was confusing the filtering enabled update with the Luau update which changed how exploits could see server-sided content

LuaU also didn’t change anything about how exploits could see server sided content.

LuaU just strips variable names from Local Scripts, so it’s marginally harder to decompile them.


local Hello = true
local Hi = "Yes"
local Cool = workspace:FindFirstChild("Ice")

will be decompiled as something like:

local variable_1 = true
local variable_2 = "Yes"
local variable_3 = workspace:FindFirstChild("Ice")

Same content, just no names.


I am still wondering what does the new beta functions do to help reduce exploiting or does it not?

New beta functions…?

They don’t. There is no secret patch for exploits.

1 Like

Then what does the difference between regular LUA and LUAC? Could be more effective to prevent exploits or not?

There is no such thing as “LUAC” - I think you mean LuaU. You can read more about it on Arseny’s article titled Faster Lua VM Released.

In regards to security, it holds zero benefits against exploiters.


It’s unfortunate that this cat and mouse game will never end. It’s practically impossible to terminate exploiting, especially when there’s multiple types of exploits. However I’m glad to see ROBLOX never fail to stop it.

Is it possible to store everything in Server Script Service and Server Storage to prevent the map being stolen. When I mean putting everything in Server Storage I am referring to loading from the Server storage itself.

No; you still need to send the map to the client so they can actually render and see it.


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)



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. ]

1 Like

Yes they can. Most of the exploits come with a debug library which allow the exploiter to understand what script say.

1 Like

Thank you so much my friend, this has helped a lot of people. Thanks for this great content :slight_smile:

1 Like

Ah, I’m aware of LuaC - I just didn’t identify that’s what they meant with the capslock :stuck_out_tongue:

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.

1 Like

Yes I agree, it is kinda fishy, not to lie.

1 Like

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.