Hello, I'm Falados the lead coder on Enigma Online More info here I would like to design this project to combat cheating as much as possible. Most of the time, closed-source projects have an easier time because they aren't exposing the client-side network protocol, and thus any hacking attempt needs to start with some reverse engineering. However in an OSS online game at least the client's (And in some cases, the server's) source code is freely available, and thus exposes the underlying network protocol and other various and extremely useful bits of information in finding exploits or weaknesses and using them to gain an unfair advantage. This is not to say closed-source are immune to that, but they are at least marginally less prone to that problem if they are designed well. What my real question then is, are there any good resources to help one such as myself make a truly secure open source online game? Any techniques that can be applied that make it difficult, even with the source-code available, to hack, cheat, and potentially ruin the game experience for other players?

Obscure your data stream using a decent symmetric cipher and an asymmetric key exchange. Even the closed source MMOs like UO, WoW and DAoC are hacked to death, because you can easily tap into the client before and after the messages are sent or received from the network layer. When you open source your client you're basically inviting somebody to make their own client with any goodie they want.

So really the bottom line is you have to do a lot of validation on the server.

One of the things that I did on one MMO I worked on was put in detection of map hacks. When you came across to a map chunk it would do a CRC of the chunk data and compare it to a table and if there was a mismatch it would send a cheater packet to the server. Of course the hackers don't know about this so they couldn't combat it, and we banned many people.

On the same MMO, I did a check of the application that launched the client, because a lot of the hacks would launch the client so that they could easily patch the memory. The client would add an extra layer of encryption to a packet that was sent with the name of the program that launched it. This obfucated it enough that the hackers just saw another garbage packet. Lots of bans from that trick too.

Sadly, I'm not sure that any of these would be useful with an open source client because it would be so easy to work around the checks.

But in this case, what I'm saying is that I do not have the option to obfuscate the client, because any attempt to do so is easily detectable. The only true measure of the games security is just that, how much actual security features are built into the game.

Also, on the topic of Public Key Encryption, which I am also considering, There are some encryption export laws that I fortunately or unfortunately have to worry about. Are there any good encryption methods for PKE that don't have this problem?

The only thing the client needs to send is the direction the player wants to move in (NOT the new location of the player - the server works that out for itself) and any actions the client wishes to perform.

The server sends the client details about what is currently visible to the client - nothing else. If you keep to this rule the only thing the player can do is reprogram the client to do repetitive tasks automatically (i.e. like mining), which should be easy to pick up on the server.

Don't even send any monster detail other than which model it uses and which animation it is currently performing - the client simply doesn't need to know.

Quote:Original post by MENTAL
The only thing the client needs to send is the direction the player wants to move in (NOT the new location of the player - the server works that out for itself) and any actions the client wishes to perform.

The server sends the client details about what is currently visible to the client - nothing else. If you keep to this rule the only thing the player can do is reprogram the client to do repetitive tasks automatically (i.e. like mining), which should be easy to pick up on the server.

Don't even send any monster detail other than which model it uses and which animation it is currently performing - the client simply doesn't need to know.

This seems all well and good, however there comes a problem when the server is doing all this computational work for X amount of players. X being a large number. What my solution was, is to let the client send this information max Y amount of times, Y being some low number, and the server letting this go unmonitored for Z amount of times ( Z is random & 0 < Z < Y ) until it validates it. If the data the client is sending is invalid. (EG, the server detects the player going through a wall, or that they are in an area that they shouldn't be) the server decreases the Y value for that player, and corrects the mistake (Placing the player in a valid location). Over a relatively short amount of time cheating then, are movement packets from these players constantly validated, where as for normal players that are abiding by the rules and are not sending invalid movement requests, the server isn't 'preaching to the choir' so to speak.

Although this itself may not be a good scheme... I'm not sure. I guess I may have to account for massive processor load for larger amount of players. Can't have your cake and eat it too.

Perhaps. WoW is exported to China and I don't remember the exact size of their keys but they are big, so that's something to consider. Even if they do something different with the "official" China version of the game, people in China are running the US version (I don't know where they're getting it...). In general I think yes it is an issue that you probably want to watch for. Use OpenSSL, and link to the DLL, or use another similar scheme then it's probably not your problem.

But like I said, you have to validate everything the client is sending you (well at least everything you think is important) on the server. You'll have to do speedhack checking on the server among other things. Most closed source clients do a lot of this on the client side, and some on the server. With an open source client you'll have to do it all on the server because as far as you know the other end isn't even using the same client. It could be a completely different program. Even a headless bot running on a PDA!

Well, I need a find a way to make it both secure, and still not have the server, in essence, play the game for all its connected players.

I see that you're from the USA. I thought the export restrictions on crypto there were lifted years ago?