LÖVE

I am currently working on a project and it had me thinking of issue over open source games and licensing.

My project will involve multiplayer, and this is where the problem really creeps in. If the code is open for anyone to view, then the door is open for somebody to cheat. I.E. If I was to use LUBE, somebody could quite easily write a Love app that pretends to be my app and feeds it with false info. Now I could write something to attempt to counteract this to check the authenticity and forbid the opportunity to arise. But is it really worth it for something that probably won't get played by more than 5 people? But if the project was slightly bigger and did attract more people, or on the off chance a small project is quite succesful. Would you not release the source to try and eliminate any foul play, or have the auth checks seperate, and not include them in the source?

Or does anybody know of any common practices that counteract this? I appreciate that Love is primarily used for small rapid devlopments, which normally produce those easy to play, fun arcade games we all love. But this is a long term project and I am trying to aim for slightly outside the comfort zone and create something that will be worth the work.

I was thinking about that lately, and everything I thought about was trivial to 'hack', so if you find yourself a good way of protecting I'd be happy to hear so. (perhaps file checks, but those can be 'hacked' as well)

I believe the server should be made in such a way that any client is welcome but is only able to act within the rules of game as defined by the server. For instance, you do not send new coordinates of a player since that could easily be circumvented. You can, however, send a command to keep walking. This obviously allows for someone to "corrupt the game" by making other servers - do you consider this an issue?

In some games, it might also be undesirable to allow any client as AI's/bots could, for some games, vastly outperform humans (e.g. because of reaction time, the ability to constantly stay active, or lack of human errors). These, I do not know how you would deal with except the usual tests and obfuscation, which simply take away the full automation but do little against the abilities if actively employed by a human operator.

Well I have thought of a possible method. It would mean that you can only play multiplayer with a released version. Source code would still be available, but you would not be able to play multiplayer from that source unless you played someone who was using the build from the same source you used.

If you create a little routine that manipulates an input based arround a string. Sort of like an encryption where there algorithm is influenced by a global string set in the source code (which is only used in the released version, left empty in source). This way in multiplayer a random string could be sent to the player, which goes through the routine and is then returned. If they are both running the release version then the output from the routine should be the same on both ends, confirming it's the same version, thus you should be able to trust it.

Edit:
Reply to Osuf

I understand what you are saying, that it should be designed so that any instructions sent over the network are inputs that the player themselves would be inputting. I thought about this, but you start to get problems when for instance in an RTS, an unit automaticly attacks based on certain circumstances. Now because of latency, the unit would start attacking at different times on each others screen. So you have to use the networking to cofirm some aspects which could be cheated.

Neptar wrote:I understand what you are saying, that it should be designed so that any instructions sent over the network are inputs that the player themselves would be inputting. I thought about this, but you start to get problems when for instance in an RTS, an unit automaticly attacks based on certain circumstances. Now because of latency, the unit would start attacking at different times on each others screen. So you have to use the networking to cofirm some aspects which could be cheated.

Could you elaborate on this issue. The attack would be initiated by the server and the state of the world of the respective clients would be updated. Certainly, latency is a factor, as always, but I do not see how the alternative provides much of a significant improvement (some improvement at the cost of other things, granted).

I think my example was poor. But as you mention the server would initiate attacks and positioning etc, it would be the brain for organising what goes on and makes sure everything follows those rules. But in reality the server is just one of the players, who is also acting as a client. What is to stop this person faking server packets for these false instructions. So that in circumstances where there is a stand off between two units, his units always come out on top. He could achieve this by altering the source and running from that.

I hope that makes sense. But I think my solution in my previous post could make sure that the serverside 'rules' are authentic.

Neptar wrote:I think my example was poor. But as you mention the server would initiate attacks and positioning etc, it would be the brain for organising what goes on and makes sure everything follows those rules. But in reality the server is just one of the players, who is also acting as a client. What is to stop this person faking server packets for these false instructions. So that in circumstances where there is a stand off between two units, his units always come out on top. He could achieve this by altering the source and running from that.

I hope that makes sense. But I think my solution in my previous post could make sure that the serverside 'rules' are authentic.

I don't think that would suffice, you could just check the data sent and send the same data in your modified version. An option would be to send a random string from the client which the server routine uses in a difficult-to-crack C routine in order to generate the source summary which is then sent to the client (by a C routine, mind you, or you may end having it run on a legit copy which is not the active one) and verified with an equally mysterious C routine. I do believe that such a check should be optional and would personally just leave it out entirely.

luac?

"The main advantages of precompiling chunks are: faster loading, protecting source code from user changes, and off-line syntax error detection."

It's probably easy to reverse engineer, but much better than nothing.

I thought about luac, but it's just as easy as including it anyway (and possibly overloading the functions you want changed), so that won't help. The best idea so far was the key left out in source distributions, but that's just packet sniffing, find out what is the authentication bit, spoof that, done. So as I said before, can't think of a way you can't get around, except for making sure the server only accepts legal commands.

bartbes wrote:I thought about luac, but it's just as easy as including it anyway (and possibly overloading the functions you want changed), so that won't help. The best idea so far was the key left out in source distributions, but that's just packet sniffing, find out what is the authentication bit, spoof that, done. So as I said before, can't think of a way you can't get around, except for making sure the server only accepts legal commands.

Yes, but you wouldn't be able to sniff it. As the key itself would never be sent across. The key would just be used as an influnece for the algorithm. A Random string is created and sent over the network, when it goes through the routine, it is manipulated in such a way that it will only give the same result if the key is the same. And the key is not included in source, only on the release version. And because the string that is sent out is random, the only way round this would be to sniff out both the string and the response and work out the key from that. Which could be possible, but it would be more effort and hopefully deter people.