Jump to content

darkdreamingdan

MTA Team
  • Posts

    2,778
  • Joined

  • Last visited

  • Days Won

    4

Everything posted by darkdreamingdan

  1. 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.
  2. 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.
  3. 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.
  4. 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
  5. I've been compiling a list of retailers that sell GTASA (incomplete), this may help you: https://wiki.multitheftauto.com/wiki/Where_to_buy_GTASA Otherwise, any boxed/DVD version will work. For example: http://articulo.mercadolibre.com.mx/MLM ... pc-150-_JM
  6. It was fixed in this revision: https://code.google.com/p/mtasa-blue/so ... ail?r=6608 Make sure your client build number is higher than 6608 by getting the newest build from https://nightly.multitheftauto.com Like a dictator using your players as test subjects great what next. Ahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahahaha.
  7. Well, its a version that runs in Windows, look at this video so is this game a version which could be COMPATIBLE with MTA SA? No. Is the Steam version available in your region? http://store.steampowered.com/app/12120/
  8. Lightweight is key here, plus the fact it's highly embeddable. Python's expansive libraries actually pose a security risk terms of client-side scripts - it would have doubled implementation time trying to make it safe.
  9. It should be possible to script this, if you really want it.
  10. MTA uses relatively novel and complex technology, and hence installs and interacts in an entirely different way to other GTA mods.
  11. You should still be able to do this. You just can't use an auto-fire macro to do it. Shouldn't a macro still work? Just limited on its rate of fire to the intended amount? Yeah, that.
  12. You should still be able to do this. You just can't use an auto-fire macro to do it.
  13. https://wiki.multitheftauto.com/wiki/Resource:Runcode
  14. showPlayerHUDComponent can currently be used for hiding the radar. There's no easy way to do blips only that I can think of, but I'm not sure why it would be all that helpful?
  15. I honestly always thought this was an SA feature, and would do this in single player.
  16. I would give a gentle reminder that we do not force anyone to donate any cash towards MTA. Nor do players who do get an advantage in game. We have been encouraging a donation drive over the past few years as a result of losing our original income source (a developer who could no longer pay all the costs of running MTA). This drive has allowed us significant breathing room, and allowed us to significantly increase the quality of our mod. Most of these things are invisible to the user, so I'll point out some things that the money has gone towards: We've completely moved to a new dedicated server that is better equipped to deal with the relatively heavy CMSs that run on our MTA network. We previously have had problems and had to take things offline. We've invested heavily in the masterlist. Originally we used to rely on a 3rd party for our master server browser list, but due to instabilities this became unreliable. We now have multiple mirrors for the server browser list and players can get quicker access to their servers. We now have sufficient bandwidth to host our installer without the requirement for mirrors. This was particularly an issue during new releases, when we would have to hold up release to wait for mirrors. We've been able to invest the technology in MTA itself. MTA is now code-signed - this provides verification for Windows and for anti-viruses that MTA is a legitimate piece of software. This requires us to pay a relatively large sum annually to buy a signing certificate. Previously we'd have problems with anti-viruses interfering with our software, but the signing has improved this significantly. Code-signing has also been used to protect our users. Tampered files of MTA and 3rd party libraries we use leave vulnerabilities exposed that could otherwise damage our users. We've been able to plug these holes. We've been able to invest heavily into our anti-cheat, with the purchase of software. This has a huge improvement for players, and I won't even delve into how our anti-cheat compares with competitors, because there's absolutely no contest. Finally, we have the capital to purchase licenses for software in future. While our budget isn't huge, this could open the door for extra features witihn MTA. It also allows us to purchase various digital copies of GTASA so we can investigate compatibility. These are just some of the things MTA has invested our money into. By the way, have you even been to the SA-MP website in the last 5 years? Again, I have no problem with them having their own funding sources, such as Ads and the "Hosted" tab in the client. Everyone has their own costs for running a project like this. But you should get your facts straight.
  17. No HLS support unfortunately. So it's gotta be Flash, unless you have any other suggestions. Great job on that though.
  18. Nice. We're having discussions over Flash support, and wherever possible it would be of great benefit if you could prioritize the use of html5. YouTube and Vimeo in particular (Twitch lacks Flash). This is simply because Flash poses various issues (security, compatibility etc). So if you could have some stuff to force html5, that would be great (there might be some further functions for user agent hacks in future).
  19. I was going to say per-player would be sufficient. Though a remote killswitch might be useful. One other important question - can the libraries easily be updated? We probably need to be prepared to update as rapidly as Chromium can update, so fast dll switches perhaps? Or can we link the libraries to our source code (I guess it's closed source so can't add a source dependency)? I know it's already implemented, but in that respect it might be worth looking at CEF https://code.google.com/p/chromiumembedded/
  20. Great job jusonex, this is something I've been wanting to see for years. I think option 1 is fine, with an additional global blacklist from option 3 (and no defaults). I have two questions: 1) How is library filesize looking with Awesomium? What overhead does it add to the overall MTA installer? 2) Can we feel secure over browser exploits that could threaten our clients (regardless of permissions and blacklists)?
  21. I think the point is, this system provides an extra layer on top of previous compilation. If someone cracks the encryption, they're left with a traditionally compiled script - something which is no worse than previous releases.
  22. Could you post a screenshot of this? I'm not sure what you mean exactly.
  23. Chinese Taiwan has been added. I've also granted you the ability to add translations to it. Everyone else, i'll sort out permissions for translating next weekend.
  24. Try the Scripting introduction: https://wiki.multitheftauto.com/wiki/Sc ... troduction
×
×
  • Create New...