luac.mtasa.com and us

[darkdreamingdan]

In September 2013, we launched a service to compile Lua files for your MTA servers, hosted within our web network - https://luac.multitheftauto.com . Currently, the service offers some basic encryption abilities and some (admittedly imperfect) protection to prevent decompilation, and an API so that users can compile scripts as simply as possible.

Over time this service has been gently encouraged in MTA Server debug warnings until it has become fully enforced. Now, all compiled scripts are required to go through this service or they will not run on your MTA Server. We've had no choice but to keep quiet on the motivations behind this process, but this post seeks to clarify the circumstances for which this had to happen. We can only apologize for the clear disruption this causes servers (particularly larger ones), but hope that you'll agree that when we say that we were backed into a corner.

Keeping our users safe

MTA is a complicated mod where we have multiple stakeholders that we have to consider. The main ones are hosting service providers, server owners, and our players. It's our job to ensure that all stakeholders are catered for, and crucially, they are kept safe. This is particularly a problem for players. We simply cannot trust server owners to always provide a safe environment for players - a scenario where a server owner baits players into joining to distribute viruses is unfortunately a reality that must be dealt with.

Enter Lua bytecode. For those unaware, the junk that you see when you open a compiled script is called "bytecode", so a compiled script or bytecode are more or less the same thing. Over 3 years ago, a lecture by Peter Cawley at the Lua Workshop 2011 presented a number of bytecode exploits in Lua 5.1 and 5.2. I actually spoke to some resident Lua experts over at Freenode who only reiterated concerns surrounding the use of bytecode in Lua. The consequences of such a discovery is clear: a booby-trapped script can be sent to unwitting players who have their systems exploited. Around the time luac.multitheftauto.com was launched, a proof of concept exploit was released - exploiting the Lua engine in the game Company of Heroes 2.

I can't recall exactly when we first became aware of the dangers of having bytecode enabled, but I think it was towards the end of 2012. We started taking serious consideration over the issue in early 2013. I actually contacted Peter regarding our options over this. After plenty of research we established a few possible ways to deal with the issue.

What our options were

1) Disable compiled scripts. This is the most obvious answer, and the best way to guarantee safety for our users. Researching how other software dealt with this exploit revealed that this was the best option. Now we get back to stakeholders: by doing this we guarantee the safety of our players and the future of the mod, but agitate all our server owners in the process.

2) Implement a way to detect malicious scripts. If the client and server had a built in way to detect the scripts that are malicious, then we could simply block those. Unfortunately, none of the team are experienced enough with Lua's intricacies to stand any chance at implementing this ourselves. A 3rd-party Lua verifier was actually released, but only for Lua 5.2. There are a number of issues with this. We don't support Lua 5.2 - so we'd have to spend time upgrading it in MTA. This might not sit nicely with things such as the then in-progress OOP implementation. The main issue is that there was no active development on the verifier, with the last commit being in September 2011. This is arguably fine for something that's 'finished', but after further indications that the author wasn't actively looking at bytecode issues, worries of a 'cat and mouse scenario' began to creep in. Even if we adopt this verifier, there's a chance more bytecode exploits are found - and when that happens we have to wait for an inactive project to be updated. On top of all of this, compiled scripts in Lua 5.1 aren't compatible in 5.2, which means everything would have to be recompiled anyway.

3) Make sure that all compiled scripts are safe. This third option is subtly different to (2). What if we can verify compiled scripts are safe by making sure the compiler is safe? If only a single compiler can be used, then no one could booby-trap their scripts. This would further require a way to prevent users from modifying scripts used by this compiler.

Initially, the consensus was to disable compiled scripts completely, and we had been discussing ways to replace the functionality of compiled scripts. Protecting scripts could be offered by some form of encryption - but we're not cryptographic experts and could never guarantee protection of scripts - in fact script protection was more of an idea and didn't really have a solid roadmap. It made me wonder whose responsibility it actually was to protect the content of scripts. Either way, all the existing compiled scripts would be rendered incompatible with a newly introduced encryption system.

I've already gone into detail over why option (2) proved to be impractical, which left our third option - providing our own compiler. By ensuring all scripts are compiled by https://luac.multitheftauto.com, we know for sure that they are legitimate and have nothing harmful in them. So, why not distribute an offline compiler? We also have to prevent against script tampering - i.e. scripts compiled with our "official compiler" then modified afterwards. We prevent this using code-signing technology - the same certification system we use to sign the MTA client itself. In layman's terms, we put an MTA "seal of approval" so if someone tampers with the MTA client executable, the seal is damaged and things break. The same principle applies to scripts compiled on https://luac.multitheftauto.com. It's simply not possible for code-signing to happen offline since we're the only ones who can stamp the 'seal'.

Hosting the compiler gave us the opportunity to implement some extra features that server owners may benefit from, such as anti-decompile, and some basic encryption. It also opens doors in future - we can potentially take further action against some of our shadier scripting community. I'd also like to point out all this research and the final decision happened over several months of deliberation - how we stop the exploit, when we can implement it, and how we tell the community about it.

Why we remained silent

This was an extremely delicate situation. If this post had been made back in 2013, we would have effectively announced to the world that there's an security hole sitting in MTA waiting to be exploited. Equally, by not coming clean we would basically be forcing server owners to pass scripts through our servers and not explain why. Overall, we felt the safest choice was settling for the latter, despite issues we might face. We chose to make our online compiler, but phase it in over the period of almost a year.

Before now, I've responded to angry server owners by pointing out the benefits of things like the script encryption, but the underlying motivation has always been about bytecode exploits. It's inevitable that things like anti-decompile are being cracked, but there are now new avenues to enhance protection to make things better for server owners.

We announce this now because we feel our players are largely safe. To keep it this way, we urge anyone who's found an exploit or even got around our compilation to check our Security bounty scheme.

What does luac.multitheftauto.com actually do?

There are various rumours over what luac.multitheftauto.com actually does, and what we do with your scripts. The answer is simple: you send a script to the server. The server then puts it through a standard Lua 5.1 compiler. It then signs the script. If you opted for encryption, the script is encrypted using a private key. Then it gives it back to you. Nothing is stored, and there's not even anything automated to read the code in the scripts.

Hopefully everything I've said already makes it clear that there's no reason for anything else to happen.

We have no interest in stealing your scripts

Which leads me to an important point: we don't want to steal your scripts. We don't care for drama or politics, only for our user base. There is no motivation for any of us to steal your scripts. This should be self-explanatory - it makes no sense for us to introduce a way to hurt the users of our software.

"But what if you wanted to sell the scripts for your personal gain, and probably world dominance?" I hear you cry. I say this: if we wanted to steal your scripts, don't you think we would have come up with a much smarter way than to invite people onto our website to upload them? We're developing a piece of software that's designed to interact with servers to send and receive files. You do the math.

Other concerns that are commonly raised is that server owners don't want to risk their scripts being exposed in case our server is hacked. Once again, for reasons outlined above, we don't store your scripts. That's a waste of our webspace. We only care for compiling them, and making sure they're sane. Nothing is stored on our servers.

Another one is that by making scripts go through us, we're making scripters rely on the indefinite existence of https://luac.multitheftauto.com . What if we can't afford the rent and the website suddenly goes down? This is a valid point, but for reasons stated above we have no choice but to compile the scripts ourselves, on our web server. Moreover, the server browser master list and other services are already hosted by us - so some form of dependence on MTA's services is uncontrollable.

Will things ever go back to how they were?

As you can see, we spent a long time figuring out how to deal with this problem. It's unlikely things can ever go back to traditional offline compiling. But keep in mind the reasons why this was introduced. If you have experience or possible avenues that could be explored, we're always open to suggestions (or even someone implementing it themselves). At the end of the day, we try to make sure all our users are happy. So if there is a Option (4) out there, it's not something that's already ruled out. In the meantime, we've tried to bridge the gap by offering an API, and some members of the community have developed tools to help.

Thanks for reading

[Et-win]

Read it all, well explained. Good job for everyone who is into this and trying to make all scripts save. Good job for everyone.

Still I'm wondering what is the best and savest and not can be stolen: Compiling or Encrypting? (Guess Compiling?)

[Woovie]

Read it all, well explained. Good job for everyone who is into this and trying to make all scripts save. Good job for everyone.

Still I'm wondering what is the best and savest and not can be stolen: Compiling or Encrypting? (Guess Compiling?)

You can do both...

[botder]

Read it all, well explained. Good job for everyone who is into this and trying to make all scripts save. Good job for everyone.

Still I'm wondering what is the best and savest and not can be stolen: Compiling or Encrypting? (Guess Compiling?)

Does not matter. I can decompile both.

[Bonsai]

Read it all, well explained. Good job for everyone who is into this and trying to make all scripts save. Good job for everyone.

Still I'm wondering what is the best and savest and not can be stolen: Compiling or Encrypting? (Guess Compiling?)

Does not matter. I can decompile both.

Tough guy.

But the majority can't.

[Et-win]

Read it all, well explained. Good job for everyone who is into this and trying to make all scripts save. Good job for everyone.

Still I'm wondering what is the best and savest and not can be stolen: Compiling or Encrypting? (Guess Compiling?)

Does not matter. I can decompile both.

Tough guy.

But the majority can't.

Even if only 1 can, that 1 can share it and ruin it.

Anyway, sorry I really have no idea about compiling and encrypting, so what is the difference about compiling, encrypting and both together?

[xXMADEXx]

Read it all, well explained. Good job for everyone who is into this and trying to make all scripts save. Good job for everyone.

Still I'm wondering what is the best and savest and not can be stolen: Compiling or Encrypting? (Guess Compiling?)

Does not matter. I can decompile both.

Good for you, now go eat an apple in the sunset. We don't need scumbag thieves.

[darkdreamingdan]

Even if only 1 can, that 1 can share it and ruin it.

Anyway, sorry I really have no idea about compiling and encrypting, so what is the difference about compiling, encrypting and both together?

They're completely different things. Compiling is something that converts plaintext script into what Lua "naturally" reads in memory - bytecode. This process always happens - Lua always converts plaintext into bytecode before it loads, but doesnt change the file. By compiling you allow Lua to skip this step and load directly. Server owners use this technique because the bytecode is harder to turn back into plaintext and therefore is harder to steal. It's actually a misuse of the feature - it's meant to make things faster to read for Lua itself (because it doesnt have to translate anything), but not meant as a method of obfuscation.

Encryption on the other hand scrambles data with a key (or a password) so that you need that password to decrypt the information back to how it was. This password is hidden within the MTA client and luac.multitheftauto.com. Encryption is normally intended to be used to secure data and prevent tampering.

They're mutually exclusive tasks, so it should be self-explanatory what doing one or the other does. Bear in mind that luac.multitheftauto.com is a compilation service. No matter what, you're always compiling. If you want more information over these terms, i suggest you read up on Wikipedia.

[botder]

Read it all, well explained. Good job for everyone who is into this and trying to make all scripts save. Good job for everyone.

Still I'm wondering what is the best and savest and not can be stolen: Compiling or Encrypting? (Guess Compiling?)

Does not matter. I can decompile both.

Good for you, now go eat an apple in the sunset. We don't need scumbag thieves.

Stop throwing words at me, which I don't deserve. I am not going to tell anybody how to do it nor abuse it myself to steal scripts - I can do my own and without server scripts it's pretty pointless. To be honest, one of the safest ways is to disable the script caching in the first place.

[Et-win]

@Talidan: Thanks for the explanation!

[HunT]

What about that ?

[xXMADEXx]

What about that ?

I'm pretty sure that means it detected an error in your script..

[HunT]

Bit Fail tnx

[tosfera]

This sure did clear up some question marks for not only me, but I guess for a lot of people. Thanks for this!

[Atton]

Would it not be a better idea to ban bytecode like Garry's Mod does. Then create a system where the server will read lua source code then encrypt it with a randomly generated key. Then send both key and lua source to the clients memory and destroying the key after the data is decrypted you could also add a compiler stage to this.

Just thinking that might be easier and this should work fine with basic AES and the random generator header files in C++.

[darkdreamingdan]

Would it not be a better idea to ban bytecode like Garry's Mod does. Then create a system where the server will read lua source code then encrypt it with a randomly generated key. Then send both key and lua source to the clients memory and destroying the key after the data is decrypted you could also add a compiler stage to this.

Just thinking that might be easier and this should work fine with basic AES and the random generator header files in C++.

I feel like your entire proposal is already answered in the original post. There's also nothing stopping people implementing this exactly in Lua itself - there are AES Lua encryption algorithms out there.

[Atton]

Would it not be a better idea to ban bytecode like Garry's Mod does. Then create a system where the server will read lua source code then encrypt it with a randomly generated key. Then send both key and lua source to the clients memory and destroying the key after the data is decrypted you could also add a compiler stage to this.

Just thinking that might be easier and this should work fine with basic AES and the random generator header files in C++.

I feel like your entire proposal is already answered in the original post. There's also nothing stopping people implementing this exactly in Lua itself - there are AES Lua encryption algorithms out there.

Fair enough but it would be awesome to see this as a built in feature in the future.

http://www.codeproject.com/Articles/138 ... ption-Decr

Also that might help with learning AES.

[darkdreamingdan]

Would it not be a better idea to ban bytecode like Garry's Mod does. Then create a system where the server will read lua source code then encrypt it with a randomly generated key. Then send both key and lua source to the clients memory and destroying the key after the data is decrypted you could also add a compiler stage to this.

Just thinking that might be easier and this should work fine with basic AES and the random generator header files in C++.

I feel like your entire proposal is already answered in the original post. There's also nothing stopping people implementing this exactly in Lua itself - there are AES Lua encryption algorithms out there.

Fair enough but it would be awesome to see this as a built in feature in the future.

http://www.codeproject.com/Articles/138 ... ption-Decr

Also that might help with learning AES.

If the key is randomly generated, then what's the point in caching to the hard disk? You can't ever reload that script which you've downloaded because you'll never know the key again. We already offer an option to not cache scripts to hard disk so they're never downloaded too. So i'm not sure how this suggestion is useful besides making it slightly harder for people to reverse engineer the script from memory.

[Atton]

If the key is randomly generated, then what's the point in caching to the hard disk? You can't ever reload that script which you've downloaded because you'll never know the key again. We already offer an option to not cache scripts to hard disk so they're never downloaded too. So i'm not sure how this suggestion is useful besides making it slightly harder for people to reverse engineer the script from memory.]

The data could suffer the same destiny as the key. It is a bit like a wooden box and key both of which are on fire and the client reads them before they turn to ash. Using a different key each time would make it much harder to reserve engineer rather then using the same RSA key for every script.

I'll draw a bit of a map.

Server >> Key Gen >> Code Mutilator[Optional] >> Server Encoder[AES] >> Output Data w/ key >> Client >> Memory >> AES Decoder >> Decoded data to memory >> Key destroyed

This makes it so there is no one key that can unlock every script in MTA and would just make reverse engineering too hard.

Edited August 15, 2014 by Guest

[Anubhav]

Atton, this won't work easily.

There are many programmers who can try to edit some MTA code ( if they have the source code ) and make it not to destroy the key and store it with resource. Not sure if I am right, I am not expierenced in these things.

[Atton]

Atton, this won't work easily.

There are many programmers who can try to edit some MTA code ( if they have the source code ) and make it not to destroy the key and store it with resource. Not sure if I am right, I am not expierenced in these things.

viewtopic.php?f=130&t=56172&p=543184&hilit=net.dll+source#p543184

From what I know net.dll is closed source and it handles the decryption in MTA good luck on editing it.

[Anubhav]

Oh... Sorry, if I disturbed. I wasn't sure about this.

[ixjf]

If the key is randomly generated, then what's the point in caching to the hard disk? You can't ever reload that script which you've downloaded because you'll never know the key again. We already offer an option to not cache scripts to hard disk so they're never downloaded too. So i'm not sure how this suggestion is useful besides making it slightly harder for people to reverse engineer the script from memory.]

The data could suffer the same destiny as the key. It is a bit like a wooden box and key both of which are on fire and the client reads them before they turn to ash. Using a different key each time would make it much harder to reserve engineer rather then using the same RSA key for every script.

I'll draw a bit of a map.

Server >> Key Gen >> Code Mutilator[Optional] >> Server Encoder[AES] >> Output Data w/ key >> Client >> Memory >> AES Decoder >> Decoded data to memory >> Key destroyed

This makes it so there is no one key that can unlock every script in MTA and would just make reverse engineering too hard.

Like Talidan said, this only makes it slightly harder to reverse engineer, it isn't much better than what MTA already does. As long as the decrypted code is in memory, no amount of encryption you put behind will ever keep it safe, it's there, decrypted.

[Arnold-1]

i think that i have a good idea.

it will be an optional feature, every server will be able to make their own key generator, adding some random data to the serial and encrypting it several times, which makes it no way possible to decrypt.

And in this way, every client will have a different key in every server, which makes the number of keys = servers * clients, i guess that i have some logic in my post.

[Bonsai]

There won't be anything like this. Ever.

Also, I don't think its needed. Disabling cache + serverside stuff won't be downloaded anyway.

Thats all you need.

In the end, MTA stuff isn't that valuable at all.