Didn’t they fix that recently? some staff definitely saw a post about it and responded to it
I am not fully aware if they did fix this, I know they’re aware of the situation but I’ve not heard anything official saying this was fixed.
I found this:
http://devforum.roblox.com/t/server-side-modulescript-source-steal-exploit/28673/24?u=einsteink
But I’m not sure if @ConvexHero ever did fix it, as that “local loadasset” got implemented, but seems to be unrelated to non-replicated (at least parented to nil on the server) modules still replicating their sourcecode.
Yeah, I am not sure if what he said would address the situation. As far as I am aware, the issue is not fixed at this current moment. Since what he said was regarding client-side LoadAsset, not exactly regarding ModuleScripts. ¯_(ツ)_/¯
Also, since this is a master information post, I suppose I’ll give some insight on how you can protect your LocalScripts and ModuleScripts source code from exploit tools such as LuaDec which is used to decompile the Lua bytecode on the client.
It’s best to take @Alkan’s advice and obfuscate your source code since LuaDec - for example - relies on instructions found in the bytecode, if you obfuscate your code, those instructions become more difficult to find which will result in compiler errors on LuaDec and therefore, they’d have broken source code which does not work.
If you call
wait()
script:Destroy()
On the first lines of a script the script runs and the script is then parent locked to nil. Don’t see a way exploits can even get to the script then if it has no parent.
Well, you see, even though you’ve destroyed the script instance itself, since the script is still running on the client memory, exploiters still have a pointer to the script as the Lua bytecode is loaded on their client memory regardless if the instance parent is locked to nil.
This would, however, block the conventional LuaDec methods in some regard as it requires you to pass the instance itself but that does not mean it makes it impossible.
They can get a reference to nil instances and re-parent them but since the parent is locked, they cannot do so but they still have a pointer to it. So, if you knew how to decompile the bytecode without needing to parent the instance itself, you can still get the source.
3 Likes
I guess it’s prob the best way to prevent against the every day hacker.
Yeah, most of those who use exploits such as RC7 and similar things tend to not know the advanced methods such as metatable hooking and whatnot to be able to do these things.
However, I wouldn’t just destroy your scripts as a full solution since sometimes you simply can’t. Like, I have a game where my LocalScripts would not function correctly if they were to be destroyed since I need them in the character for them to be functional.
So your solution would work; if you can do it.
It works for me since i use a single local script to run my entire game. Since I am destroying the script before the rest of the script runs, remote events etc still work even with the script not inside the player gui 
Yeah, that would work for you, just sadly it’s not a solution for everyone. My solution would probably be the best way to protect your source code if you simply cannot parent it to nil without breaking the functionality of your game.
However, as I previously stated, most of the exploit users tend to not know how to do these things as much, the exploit itself makes it fairly easy just to pass an instance to it and decompile the bytecode to save to your computer. Just, if they wanted to get the source of a script without a physical instance, they’d need to provide a pointer to it without a physical instance, that’s where it’s more complicated but it is possible.
It’s kinda a shame really, since personally, these exploits are actually very advanced in how they work and by viewing the source and playing around and having the general knowledge to create such things, it’s not something you can do in 10 minutes. A lot of time is put into finding these things plus every Wednesday when Roblox update their client, they then need to find the memory addresses and replace them which is fuuuuuuunnnnnn to do.
Just, if people were to use exploits for the better of people such as testing to find things to report and have fixed, we wouldn’t have much of an issue. This is what I tend to do, I like to test things and find things out so I can find ways to fix them so other people who have just bought the exploit to go around and ruin the experience for others can’t do it as easily.
1 Like
i go over this in the post, but i still think the only way to truly, absolutely ensure your game is safe is by handling your network code responsibly. there really isn’t any way to make a 100% foolproof solution to exploiting solely on the client alone. while i think there are certainly a lot of things we can do to make it a lot harder to exploit the games, because sites like vermillion have created a market for these exploits, any anti-exploiting methods that are fully reliant on client will eventually be bypassed in some way or another. yes, we can make it hard, yes, we can make it miserable, but we can’t make it impossible.
the only way to do that is by reducing the amount of authority the client has in making final game decisions.
1 Like
I am going to bump this because how important/relevant it is still but I’m not currently developing in FE. I am still learning about FE (I’m hoping me laying the foundation down for it should be an easy flick on). I feel I have it down but I’m still having minor issues about getting the PlayerGUI/Camera and some performance issues.
1 Like
updated the post and moved it into learning resources so it can be viewed publicly (:
4 Likes
I want to make something extremely clear: exploits being level 7 doesn’t mean what you think it does. You can do everything listed in this post with level 2 (the context of normal scripts). Most exploiters rarely ever use anything past level 2 context. The term you’re looking for is “script injector”.
1 Like
thanks, ill update the post with new information 
2 Likes
Apologies to anyone that this may disturb since this is reviving the topic, but I think I may be on to something.
I’ve been at wits with many an exploiter especially old friends, so I already have known of auto executing code, and I really would like some confirmation on this. @crossStarCross said in the above quote that the auto executing functionality loads prior to client logic. Can anyone confirm that this is in-fact the case, or still the case?
2 Likes
IIRC only 1 exploit current has the ability to autoexecute before scripts in ReplicatedFirst.
1 Like
Interesting. Thinking of some anti-exploit methods that in itself become rather simple to update, but at the same time remain difficult for exploiters to break through. I might make a post, or surf through some discords to see if I can find an answer for this as well, but I’m also curious to know if exploits can read exact values sent to the server. I understand that they can read client side code, but I’m curious to see if they can read what values are sent in specific to the server.
One if the best methods you can do is called honey potting
Most of these kids see San event called apply dmg that looks hidden are gonna fire it. And boom you gotten.
Do not name all your functions in a way to indicate if they are down pipe or up pipe.
This way you can easily server side wrap the real ones and honey pots with…hey no ones ever suppose to use this.
Second:
Deterministic data.
This is easier than it sounds. Do all cert checks on the client and the server the same and do some extra on the server.
This let’s you. With absolute certainty know, yo your not a shadow mage, you clearly injected to get past that block.
Flag them. Restrict them from economy and let the hammer drop on next place jump. So they cant associate an action with the ban. For flavor, put a timer too random like 30 to 2hrs then next place login boom done