In that case use a real solution like adding an open-source license. With licensing you can guarantee nobody will touch it.
I understand obfuscating a bit of the frontend to make it a little harder for exploiters but obfuscating entire script systems to sell is obsolete imo.
Obscurity is not integrity, confidentiality, anonymity, or authenticity. Itâs designed to hinder the performance and ability of decompilers. Itâs not a defense approach, itâs a translation.
Say you obfuscate the code which takes in unsanitized input, that doesnât prevent the user from exploiting SQL injection, cross-site script attacks.
Say you obfuscate some code using strcpy(), that shouldnât prevent buffer overflows and control hijacking.
If it actually does prevent the above situations, the original code logic has been changed. Which is not great for obfuscation.
If youâre going to implement a defense, it should aim to prevent specific attack vectors. Obfuscation aims to prevent decompiling, and shouldnât be used to claim a game is secure from script executors. For security and the works, hereâs this awesome topic.
As a programmer, I donât see obfuscation as a good practice for development. @xJxck_yy But cool topic, thanks for posting. Obfuscation seems to be quite popular on Roblox and despite the controversy on its use, it is interesting to discuss and talk about. I think a good addition to this would be a more in depth guide to how obfuscation works and achieves its goal.
Obfuscation is a very useful thing Iâve found in Roblox. Many people think itâs malicious as the principal uses of it are hiding backdoors.
Iâve seen many users say that it would be harder to debug. My solution would be to keep the script hidden and disabled in a folder in ServerStorage, that way you can disable the obfuscated code and then enable the non-obfuscated code and fix it.
This doesnât makes your script exploit-proof, people can still use it but their source code is hard to crack.
Iron Brew is the best obfuscator.
Youâre right. Obfuscation is just accomplishing the task that makes code hard to read for a user and a decompiler. If youâre giving out obfuscated code, it might be tricky for your consumers to read the code but they can redistribute the obfuscated code just the same.
I advertise against obfuscation in any development practice, but especially with marketing. If you plan on selling an obfuscated product, youâre going to lose value in the following ways.
Youâll be selling the code functionality, but not code logic. In development, functionality and what the program should be accomplishing is going to change; only selling functionality will prevent consumer developers from adapting the script to fit future needs. This shifts all updates and maintenance of the script to you, where this now becomes a service.
Developers cannot determine how the code works. This creates a trust system, trusting that you have no malicious code in the product and that youâve employed secure, correct, and efficient methods in your script.
I apologize if this sounds at all negative, but thatâs not the goal of this. I hope this can clear up some things, feel free to ask any questions. I do agree with some points of this thread and disagree with other ones. Let me know what you think about this.
Itâs notsecurity, itâs just a way to hide your potentially malicious code from script kiddies who have no idea what theyâre doing. You canât rely on it for all your security as most exploits can hook your functions. Although as @Amiaa16 has said, itâs not a bad thing to do with your already secure scripts as it may stop people who donât know what theyâre doing.
Thereâs a lot I should say about this. First is the status of these obfuscators
Synapse Xen is discontinued as far as weâre aware of.
Luraph is easily crackable now.
Ironbrew 2 is discontinued, but V3 is in the works.
I donât recommend all of these obfuscators as @T_eethyz has said.
Then the deobfuscation:
All obfuscators can be cracked depending on the person or company dealing with it / the complexity of the actual obfuscator. Like Luraph has been fully cracked by one guy but ALL obfuscators CAN be constant dumped, so I still donât think you should ever use obfuscation to hide your variables as their values are all loaded and can be printed out. Even more advanced users can edit your variables without even deobfuscating your code. Letâs say you fully deobfuscate an obfuscator, you should be left with the script that has 0 debug information (no comments or variable names) but it is still readable just not as easy to read as before. So again, obfuscation should not be relied on as all of your codes âsecurityâ.
@xJxck_yy I totally get where youâre going at though and thanks for posting! I had fun typing out this response because Iâm not doing a ton of things.
I hope this could have helped someone, and if you still have any questions donât hesitate to reply to this or PM me.
After playing it for a bit, you see how fluid and responsive everything is. The problem is that itâs all (Iâm positive of this) client-based in terms of handling if someone gets hit by a spell or something.
Itâs extremely vulnerable to exploits because of it. However, securing remotes and ensuring people canât remotely kill others in game, say, would serve as a detriment to the responsiveness and fluidity which makes the game enjoyable. Other secure, sort of similar magic games which use wands like these sacrifice the speed which I can tell for many, matters, because itâs nice to not experience constant delays which if it involves sending spells at others and timing it right, is important. In this case, it makes not much sense to sacrifice speed to me.
Thatâs just an example, (likely the only case I can think of) where being secure isnât beneficial to the gameplay involved.
Otherwise, I 110% agree with you.
Synapse Xen is discontinued;
Ironbrew is discontinued with the source code currently available;
Quite sure that Luraph also has been cracked.
WallySecure is also a good obfuscator and so is clvbrew (invite only I believe) but Iâve been banned from WallySecure for rules that arenât clearly existant, so I donât suggest using their server for anything other than obfuscation ok the owner cleared up confusion about it.
Iâd prefer you use WallySecure because itâs the best obfuscator out there in my opinion. It is extremely customizable and depending on the security you want you can choose the options. clvbrew is not as secure as Wally, but since itâs barely accessible nobody has made any tools to even constant dump it. clvbrewâs constant enc works like a charm, so you can use both.
All in all, do not obfuscate scripts unless you are selling them. And especially, try avoiding to obfuscate local scripts.
CLVBrew and Aztupbrew are both being actively updated rn, and they are forks of Ironbrew. Iâll highly recommend you do not use Aztupbrew because it does not provide any better protection than Ironbrew, and itâs easy to constant dump it. CLVBrew encrypts your strings, Wally if you select the option or you use the macroâs it will encrypt your strings. Same goes with Luraph, if you use the macro âLPH_ENCSTRâ your string will be encrypted. Iâve constant dumped Luraph, AztupBrew and WallySecure. WallySecureâs and Luraphâs string encryption indeed does work, while Aztup brewâs does not.
I ran some tests again, Wally ran the script I specified before in less than 0.1 seconds.
Luraph is currently free, and so is Wally. Both are publicly available.
In the Ro-av community, tech groups add whitelists to their products and obfuscate their scripts. Obfuscation is not wrong but uhm, I wouldnât recommend doing it for purposes listed on this thread.
Hey, creator of WallySecure here coming to tell you WallySecure (compared to clv) isnât slow anymore and there is a way to fix that: WS_FAST_EXECTION (a new macro) can actually improve performance to match clvbrew:
As you can see, the new macro provides speed that is almost equivalent to clvbrew. Basically, you should be wrapping your whole script in this macro as it is what will bring the best performance. Keep in mind that VM obfuscation will still have a large impact on performance no matter what:
I agree. Simply due to the fact that it comes with an exploit program is enough reason to not. Even less reason to do so is the fact that it is discontinued.
You can get to know what are the bytecode instructions(LOADK, SETUPVALâŚ) . Itâd pretty easy if you beautify the file and you compare it to the [rerubi source] [1]Itâs hard to explain, I would have to show you what I mean while screensharing.