As you probably know, MTA allows both server- as client-side scripts. There is however one large security with this: for per-player minigames, as for example the idea's for a training minigame I've posted in the VIP forums, the entire minigame needs to be available on the player's installation. This means the file itself gets posted on his/her harddrive, and using a simple copy-/paste people will be able to use it for their own servers.
Ofcourse this isn't something we want, therefore I'd like to use this topic as a place to discuss how we're going to make sure this doesn't happen. If you have any idea, no matter how rediculous it is, on how to implement some security, please post it in this thread and we'll discuss it later on.
Idea's coming from myself:
Compiling all client-side scripts
LUA allows you to compile scripts prior to actually using them, which is exactly what we'll be doing. All scripts running on the server which will have client-side impact must be compiled at all times, to prevent people from easily copying them. There are, however, ways to decode these scripts, as easy as the click of a button, so we might have to look for some kind of encryption to include with them.
Using security-tokens
Before a script may actually run, I think it's a wise idea to send a specific token to the server to check whether we're actually allowed to run the script. Lock everything until we're allowed to run. Even if people copy-/paste the script onto their own servers, they won't be able to run it due to our token-system.
The security token and locking the whole thing before allowing the script to run - with that in mind i was thinking of just using the player's serial number to check if that serial number is actually currently playing on the server. I don't know if that is was you mean.
Just thinking, if we start the lua files' names with . would they become hidden in Windows? That'd be a good way of doing things -- they'd see an empty folder?
(02-21-2008, 08:21 PM)tomozj link Wrote: The serial number checking sounds pretty good.
Just thinking, if we start the lua files' names with . would they become hidden in Windows? That'd be a good way of doing things -- they'd see an empty folder?
That's thinkin' outside the box! However, if someone want's to find it (they really like it and want it's on their server) they WILL find it. Like Peter said, it HAS to be there. Hence the need for some sort of encryption.
I was thinkin' password style. An insanely long password (encrypted?) that is givin' to all players by default through in-game access rights.
Knowing that if I try to explain this any further I'll potentially make myself look like and idiot, I'll stop here and let you guys look further into that.
I've attached an example of an obfuscated .lua file to this post. If we use something like this (with an automatic obfuscator which I will write) it won't be too hard to produce some security. The player-serial seems somewhat odd to me: it's quite obvious that the player is playing on the server if he's running the script.
Something like an activate command seems like a better option to me, just don't do anything at all until we get properly activated.
I think Badeend means, that you make a check in the script to see if a player is currently playing on the LVP server, and if he is not he can't play the minigame.
I had another idea, mainly aimed at the human psyche for the reason to confuse people trying to use our scripts. Let's say the spawn system got four callbacks it receives from the server, we could use them like this. Pay close attention to the descriptions associated with the actual names;
[table]
[tr][td]Name[/td][td]Description[/td][/tr]
[tr][td]lvpEndSpawnScreen[/td][td]Initialises the spawn screens, makes the resources and setup the player itself.[/td][/tr]
[tr][td]lvpSetDefaultSkin[/td][td]Send to the player when his/her password is incorrect.[/td][/tr]
[tr][td]lvpStartSpawnScreen [/td][td]Send to the player when he/she needs to log-in using a password.[/td][/tr]
[tr][td]lvpIncorrectPass[/td][td]Spawn the player into the world.[/td][/tr]
[/table]
Aside from that, I've actually included the file I was talking about this time. Sorry =p
The combination of an activator and the obfuscation should dissuade all but the most determined thieves from stealing the code. Since the obfuscation adds extra unnecessary code, are there any performance concerns or is most of the extra "useless" code only parsed and executed on the initial loading of the script?
I don't like the idea of misleading callback names though, since that has the potential to confuse our own development team.
I assume this means that LVP 3.0 will start out closed-source then, since this step wouldn't be necessary otherwise.
I think the intensions were to make LVP 2.x open source and keep LVP 3.00 closed source indefinitely (wait until a time such as when MTAM dies). However with the situation between LVP and SA-MP I don't think it's as mandatory to give something back to the SA-MP community?
Anyway, back on-topic. I think the callback names are pretty misleading, and could in fact confuse ourselves more than prevent others. The obfuscation looks extremely complicated, which is great as I doubt anyone will bother with messing around with that code.
That on top of compiling the code, messing around with callbacks' names and maybe hiding the files from being browsed to regularly in Windows Explorer might prevent them for a very long time?
I guess that we could even discuss with the MTAM development team if they're planning to protect people's code from thieves by implementing their own security measures in the future.
The idea indeed is to keep the gamemode closed source until it runs for a few months, after which it will be semi-open sourced like LVP 2.x is. Just to get a head start and popularity in the MTA scene, where LVP will be unknown for quite alot of people. If we open-source immediatly, some other server might grab our code and immediatly got the same futures we got. The fact stays the same; immediatly going open-source with a gamemode like ours would kills us.
Next to that, I would like to purpose to keep as much things on the server-side as possible. LUA is way lighter than SA-MP's Pawn, giving us a considerably high advantage. Early tests of mine have shown that the server is capable of executing ~2 million LUA-commands (getServerName & setElementPosition) every second, which is a huge amount. Ideally we'd just use the client as an interface for client-side functions; creating our own RPC system.
M dies). However with the situation between LVP and SA-MP I don't think it's as mandatory to give something back to the SA-MP community?