Protecting Your Online Game Resources

This article is focused on how online game developers can try to secure their resources from being downloaded in 5 minutes. Resources might include graphics, sounds, videos, text/scripts, code, or any other files that make up your game.

Over the past few months I’ve been looking at browser-based online games and some of the security practices (or lack of) that are used and have compiled a list of simple things that you should check if security is something that matters to you.

If it doesn’t matter whether players can obtain all the content in a matter of minutes, then this article is irrelevant. Otherwise, you might want to check a few things before deploying your game, or if it’s already in production, whether you can still patch a few things up.

There are many reasons why someone might choose to want to protect their data, and there are many arguments on why it is “meaningless” to even try to secure data, but that’s not something I will discuss here.

Background

Game data security is difficult to accomplish (though I tend to say it’s impossible to secure your resources). Often times, the player has all of the data on their computer. You can employ security techniques like encryption, compression, obfuscation, or other ways to try to make it harder for players to just click on the files and share it with their friends, but in the end if someone has the technical know-how and can reverse engineer the methods used, then the security is broken.

With online games, however, developers have the advantage where players may not have all of the required files on their computer. Instead, the server can choose when the client will receive the files.

Note that I am assuming a client-server architecture, where the server holds all of the resources and the client makes requests for content.

Considerations

Different security techniques have different costs associated with them. Some of them are pretty much free and just need to be configured in your software or hardware.

Others may require time and money, such as the overhead incurred from additional processing that is needed.

Some may even cause frustration for players, for example if all resources are sent only when they are requested. Depending on the size of the file, it may take some time to download, and that would ruin the gaming experience.

Therefore, whether you want to implement a method or not requires you to consider whether the trade-off is worth it or not.

Techniques for Securing your Resources

The following is a list of methods that I’ve put together based on my experience looking for security holes. Some of them may be so obvious that you’re wondering how someone could possibly overlook it, but everything that I write here is based on circumstances that I have observed myself (and therefore have successfully acquired resources without having to play the games).

Check your access controls

In any online game, players have access to all of the requests and responses that are made to the server. This can be done in a variety of ways, such as using a packet sniffer like WireShark to capture all of the traffic. If it’s a browser game, and if the browser supports network traffic inspection (eg: Firebug for Firefox, Developer Console for Chrome), those would be options as well.

Typically, this means that I know the URL to your server, and perhaps the directory structure you are using for your resources. So for example, if my browser made a request to “http://game-server.com/res/images/weapon1.jpg”, I’m going to check the following URL’s to see if I can access them

• http://game-server.com/res/images/
• http://game-server.com/res/
• http://game-server.com/

If you haven’t properly set up access controls, I’m probably going to get a directory listing with all of your game content.

Secure your dev environment

Usually a game has at least two environments: a production server, and a dev server. Any changes that need to be made or new features to be added can be thoroughly tested on the dev server, and when it is ready to be released it can be pushed to the production server easily with confidence.

However, access controls are not only required for your production server; you also need to make sure your dev server is set up properly.

One might ask how an outsider such as myself might find my way to your dev server. My experiences have shown that devs have done things like

• Dev server URLs left in the comments
• Content being served from the dev server
• allowing me to guess the dev server URL

Many of these are simple mistakes, but they are quite costly.

Secure your API’s

A number of browser-based games process requests using server-side scripts. For example, I might make a request to

http://game-server.com/weapons.php?id=4

Which would return some information about weapon with ID 4, possibly as a JSON object containing data about the weapon that the client will use to render.

Now, being clever, a player might figure out how you’ve designed your API’s so now maybe they’ll try to pass in 5, 10, 58, or 38423 and hope to get some data that they shouldn’t have access to.

The best that can happen is that they’ll get an error message and direct them back. However, if you haven’t properly checked whether the client can actually query that information, the server will send the information as requested. Or worse, your whole server might go down due to an exception…and so on. But these are software issues and not related to the scope of this article.

Now, this might not be too bad, since I can build a website that shows information about your game and your players may actually be more satisfied since they now know exactly how they may want to proceed. But if the same technique works for content that players really shouldn’t be accessing without having played the game for some period of time or paid money for it, then management may not be happy.

Serving predictable names

If the client made the following requests

http://game-server.com/res/images/weapon1.png
http://game-server.com/res/images/weapon5.png
http://game-server.com/res/images/weapon14.png

Is there possibly a pattern to the way your resources are structured? What are the chances that if I request for weapon13.png, I’m going to get an image of another weapon?

Some developers use very predictable names, and the reason why they do so is understandable. However, that doesn’t mean the name of your files need to be so straightforward.

There are many techniques that programmers can use to provide arbitrary filenames and still provide manageable code, and there are many techniques available for generating filenames as well. This could be done using particular algorithms (hashing, for example), or it could be done by typing a bunch of characters randomly on your keyboard and assigning that filename to the object.

If a player sees this

http://game-server.com/res/images/dashijsah98weu8934321.png
http://game-server.com/res/images/fsjaoki23j90s7f.png
http://game-server.com/res/images/lkjcxzew095490ikmfskdjn2.png

It’s much more difficult to predict where your resource is.

Sending too much data

Regardless how you send data to the client, sometimes you might be sending too much data. This depends on what kind of content is available in your game, but suppose you have an object-oriented design where a particular object has a lot of different attributes assigned to it.

This object is probably something that will be used on the server side, and also used to render on the client side. For example, if you have a character object that holds a name and an image, and you want the client to render that character, you might choose to serialize the object and stream it to the client.

The problem with this approach is that if you’re not careful, you may end up serializing all of the attributes of that object, most of which may not be used by the client so the client wouldn’t notice anything strange, but anyone monitoring packets will capture the extra data.

If you are sending data to the client, you should take care to check exactly what you’re sending.

Summary

While it is very difficult to secure your resources, there are things that you could do to make things somewhat more difficult. There are also a number of things that might take no more than a few minutes to check, that could prevent your whole server from being compromised.

This is just a list of things that I’m aware of, and I’m sure there’s more out there. If you have anything that you feel should be added to the list just leave it in the comments!

Spread the Word

If you liked the post and feel that others could benefit from it, consider tweeting it or sharing it on whichever social media channels that you use. You can also follow @HimeWorks on Twitter or like my Facebook page to get the latest updates or suggest topics that you would like to read about.