Jump to content
  • Advertisement
Sign in to follow this  
Falados

Obscurity is not good Security

This topic is 4831 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
Advertisement
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.


Share this post


Link to post
Share on other sites
This question comes up every now and then. Perhaps it's time to put it into the FAQ.

Security means many different things to many different people, but here are some basics:

1) Anything that you trust the client on WILL be hacked (if your game is at all popular). Thus, you need a trusted server that keeps the authoritative game state and makes authoritative decisions to avoid that problem. (peer voting solutions are not only horribly complex; they are also still cheatable)

2) Once you have good central authority, you need good authentication. A kerberos-style ticket system is one authentication solution. See my game-auth page for more.

3) If your game is susceptible to macro-ing, then you need to change your game design to get around that problem.

4) Griefing is the hardest thing to guard against; a combination of game design and community policing as well as active developer involvement can help, but it's a large support cost. Note that community policing alone can be used as a griefing tool: a gang of people decide they don't like some outsider, and the outsider gets "policed".

5) Don't go overboard. In the end, your goal is for the maximum number of people to send you money. If you find yourself shifting goals towards banning the maximum number of people, then you're in trouble.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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!


Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!