Jump to content

luac.mtasa.com and us


Recommended Posts

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...

Link to comment
  • MTA Team
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.

Link to comment
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.

Link to comment
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?

Link to comment
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.

Link to comment
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.

Link to comment
  • MTA Team
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.

  • Haha 2
Link to comment

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++.

Link to comment
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.

Link to comment
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.

Link to comment
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.

Link to comment

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 by Guest
Link to comment
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.

Link to comment

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.

Link to comment

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.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...