Game security crash course

First let's answer the question : Why should I care ?

In most studios security appears to be optional, we can look at Pokemon Go's release for example, its API was reversed in a couple of days after release and bots started to appear very quickly making the game very frustrating for regular players. Within a month they banned the aggressive bots and started issuing C&Ds to open source bots, but the damage was already done, the gyms were mostly owned by bots so the incentive to level up and boost Pokemon was gone. Bots and cheats will ruin the user experience, playing a FPS against someone using an aim-bot is frustrating, it's impossible to win. 

So why are studios not doing security correctly ? The answer is simple, they underestimate the impact that bad security will have on sales and user experience and believe that it's just not worth doing.

I. Understanding the risks

Bots and cheats are a business, like every business they analyze the market before working on a product, so here are the things they look for when analyzing the market:

So if you are making a single player game, you do not need to worry about cheaters or bots -- you might want to worry about DRMs but this is not the topic of this post. Again let's look at Pokemon Go, they have a huge player base, players are competing to dominate gyms, there are transactions but not among players only micro transactions to buy items to make your progress faster which brings us to the last point, it's very time consuming. This game was a perfect candidate for a bot so they should have worried about security before release, they did not even though it was predictable.

But Pokemon Go is one of those games were preventing cheats and bots was never going to work, they needed to presume bots would be there from day one and build detection mechanisms based on behavior. Let's think about a scenario we can relate to, our company is building a FPS, it's a very competitive genre and very difficult to prevent cheating because of the fast paced gameplay and how just having a radar can give a player a huge advantage over other players. It's a perfect candidate for cheats because players want to have this advantage, winning with an unfair advantage is still winning.

II. Building security

We now know that the game is a potential target, let's come up with a strategy, but first the bad but obvious strategies:

The first one is not such a bad idea because it will delay hackers and make cheat development for the game more expensive, it's probable hackers will decide to look at another game because of the development cost and time. But it is a bad idea because it just moves the problem to other games and as other games decide to add security your game will again become a target.

The second one seems obvious, anti-cheat is what we want so why not build an anti-cheat software, kind of like an anti-virus that runs alongside the game and defeats cheaters ? Well anti-cheat software is pretty much an anti-virus except here the user is on the side of the virus, so you have to assume that the machine you are running the anti-cheat software on is compromised and everything you receive from this user is not trustworthy.

These strategies have one thing in common : both are client side. The only part of the game you can trust is the server side, the most up to date anti-cheats are trying to use machine learning to detect offenders, as far as I know, it only works for very simple games, it will not work for the FPS game. The best solution is to build security in the gameplay mechanics, think about the edge cases of your gameplay. For instance, for player to player transactions, player A can sell an item to player B for an added fee. Of course we set the fee to some arbitrary amount and we are all set, then an engineer implements it in game and in production we realize that there is an exploit in there, the exploit is simple: sell the item at a very high price and by doing so both players receive gold. This is an integer overflow vulnerability, I will not go into details but the issue here was that we did not set a range of acceptable prices. And this is a real vulnerability that I encountered on a live game.

Keeping security in mind while building gameplay mechanics will take care of most exploits your game could contain but what do we do about cheats that do not interact with the server:

Here we see a radar and a wall hack, the correct way to think about this problem is not to try to detect it by doing behavioral analysis to see if players look through walls or to add an anti-cheat software but to turn this into a server exploit, this exploit exists because the server sends information about players you should not be able to see, it used to be nearly impossible to run this kind of tests server side due to performance limitations but nowadays the hardware we have is capable of doing more work.

III. Work with the players

This is the opposite of what I have been writing all along, but some studios are trying to find a set of trustworthy players in the game's community that can help make the game a better place. The scenario is the following: A few players report player X because they think he is cheating, a trustworthy player can watch replays of the games where player X was supposedly cheating and can validate or not the reports. I do not have any numbers on the success of this approach but working with the community is usually a good idea to show that you as a company care about the customers.

The aggressive approach that is to sue bot and cheat developers is a terrible idea, this is how you get bot and cheat sources to become available to everyone, and you cannot sue thousands of people. Also a hack being open source means that many different versions will appear making detection a lot more work. Understand why players feel like they need to bot or cheat, it usually means a mechanic is not rewarding enough or that you can gain a huge advantage easily. 

IV. Recap