Community need new luac compiler!

[hustlover]

I have a lot of written scripts that I compile and believe in data security.
But it's stopping me now: 

[mod snip - link to some "script decompiler" - dont post this]

 

[Jusonex]

The compiler has never been meant to be 100% secure. It can't even be fully secure since the MTA server still needs to read the script files.

However, it doesn't look like the decompiler in the video supports "obfuscation level 3" which is much better than the other two.

[Saml1er]

Server owners can also set client scripts cache to false. In this way, scripts will be downloaded and directly executed instead of being saved on the client.

<script src="client.lua" type="client" cache="false"/>

As Jusonex mentioned about luac.multitheftauto.com, it's not fully secure because scripts must be deobfuscated before loading them for execution. Anyone that understands reversing can copy the logic from MTA's binaries and create their own "decompiler".

[Dutchman101]

The decompilation key for level 1 obfuscation (as listed on https://luac.multitheftauto.com) has been circulating in certain hacking groups for a while because it had previously been compromised.

In response to level 1 obfuscation becoming insecure, we created level 2 - "More" option.

While level 2 obfuscation is a way stronger level of obfuscation, nothing is completely secure. Every single time the current highest level of obfuscation gets cracked, we try to implement a new one as fast as possible. Everything can be breached. So to keep your scripts as safe as possible, you should always use the highest level of obfuscation that https://luac.multitheftauto.com offers, and perhaps also take measures like someone else posted directly above me.

Generally speaking, only scripts still obfuscated with the previous, outdated level encryption are susceptible, we advise a re-compile whenever you see that luac.multitheftauto.com starts offering a new level of obfuscation.

As I said, nothing is secure. Whenever our latest obfuscation level is cracked, we will take our best efforts to implement a new (tougher) level to replace it for those who want heightened security. Please note that it takes both people that wouldn't usually spend their time playing games (but use their cracking skills for darker purposes) to crack each new generation of obfuscation, and quite some resources to achieve that. Also, alot of people on MTA contend that securing your resources with compiling is a matter of "best effort" (atleast preventing very easy theft, a first layer of defense) and might even be unnecesary/useless for various reasons. However, as I wrote earlier, we take it seriously to continuously offer you the most secure options to aid you in that quest.

 

While nothing related to the possibilities we offer for compilation is completely breach-proof, there's some reasons why the chance you and your scripts become a victim is low, and also why decompiled scripts are often renderred largely useless (thus dealing no harm to you as creator), are pretty low; (open the spoiler)

Spoiler

For TL;DR, skip to the bottom and read the last paragraph only. Especially the last lines state some present risks that cannot be minimalized.

- when a level of obfuscation that we offer has been cracked, it takes someone who knows how to use a bare LUA environment and hook that .luac file & apply the decryption key that has been extracted from the cracking process. It is unlikely that someone possessing these skills will want to target specfically your server's scripts.

- the risk that above factor yields increases when someone tries to make decompilation accessible to everyone without knownledge easily, by creating an app that allows automatic decompilation with a GUI. This is what happened today. However, the commercial nature of this developer (we won't be naming him) aimed at making big bucks, and the price of the tool he's selling, means that there'll be a very limited public to use his decompilation tool because getting your hands on it isn't as accessible as using it. Therefore, the potential amount of folks that are now easily able to decompile your scripts, is pretty low and considering the amount of servers on MTA, the chance they will target your scripts is as hisg as getting hit by a bus tomorrow. We actually have to thank the developer for atleast not giving the tool out on a grand scale, for free, as we cannot take away his compulsion to create it in the first place. By the time however that buyers of the tool start to leak it publicly, (if at all due to the price they paid for it) we have already long implemented a new layer of obfuscation.

This does not mean we approve or condone the development & sale of tools like these, but we're trying to convince you, users potentially concerned about security now, that the risks are pretty low in this situation. Besides that, you can take additional measures that were mentioned, such as enabling the no-cache attribute in meta.xml for your scripts to not be stored as a .luac file for clients.

 

Also not least important, the results of decompiled scripts are rendered largely unusable. This further decreases the risk any decompiled scripts from your server will inflict serious harm to you as a server owner. The reasons being;

- serverside code is often missing because one cannot get their hands on server script files, unless directly shared. Typically, someone takes compiled .luac script files directly from the client resources download folder to try and decompile then.

- variables and other strings/things that a Lua 5.1 decompiler cannot intepret, are lost completely. This means that any script (except for a 3-liner) is rendered broken (unable to run) right after decompiling, until it's manually fixed.

The thing that matters here; "fixing" decompiled scripts is pretty hard if not nearly impossible to do, because rewriting a serverside part the coder has to imagine (guess) how clientside used to interact with serverside code and then write the serverside (designed specifically for the decompiled client code) from scratch, which will often take a lot more time and trouble than just writing it all  yourself without any stealing or decompiling.

The next difficult part is replacing variables and other strings the decompiler doesn't understand, with things that would make sense, trying to resemble the original script. However, without any clue to what used to be the value, it will be worse than guessing, and you'll have to thoroughly study every single line of the whole script to understand what that argument, value or variable used to be like, potentially even doing so while  its also neccesary to account for the serverside (also missing) to get that overview needed to replace the things decompiling broke. When the script requires serverside, knowing that for a fact you'll have to write it from scratch, it's often impossible to resemble the clientside variables/broken decompiler output, because knownledge from the serverside code could be required to fill that in.

The difficulties of fixing decompiled scripts increase as the script is bigger or less basic. Ofcourse, the original video that was attached to this topic, used code that consisted of just 1 scripting function and 3 lines, trying to convince potential buyers that it would output the decompiled result as clean as it was written for the demonstration. But you will figure otherwise once you have personally seen the output of decompilation.

After all, these difficulties will result in that the scripter trying to steal others their work, will end up spending more time (if finishing at all) to fix up the decompiled code, than if he were to write it by his own. It already takes a pretty experienced scripter to fix up all missing variables, values and arguments etcetera, and turn it into a working script. So that means a scripter who'se able to revive it, is automatically able to write it themselves; decompiling the work of others is never an alternative for novice scripters who just want to spare themselves some hard time. So basically, there's no merit in decompilation, except for maybe getting to know how a certain scripter achieved some functionality in their scripts, by just looking at the functions and procedures used in the output. It can also serve the goal of enabling themselves to do harm to a server (like finding hidden backdoors or commands in your scripts, finding vulnerable scripts that can either be LUA injected to, or resembled (thought out) into abusable ingame bugs, therefore it's very important to never store sensitive information or data in compiled clientside script code and also, as scripter, pay attention to Script security (click) and do enough (sanity) checks so that exploits and vulnerabilties don't exist in your code.