Secure authorization for subscription-based games or services

Question

Let's suppose I'm developing a subscription-based desktop game: the player pays a fee in order to get access to certain levels of the game for a certain time. For example, the player pays $1 to get access to one special level of the game for one month.

Every time the game loads, it sends a request to the back-end API in order to check what levels can the player access, and then enables the corresponding levels for the player. However, the player may use a MITM (man-in-the-middle) attack to intercept and modify the server response so it tells the game that the player has access to every level of the game.

How should the authorization process be implemented in this situation to avoid the player getting unauthorized access to levels?

Let's assume two player profiles for two different scenarios:

• Scenario 1: the player can sniff the network.
• Scenario 2: the player can sniff the network and has access to the source code of the game (not of the server).

Answer 1

Preventing a game from being cracked is difficult. There are a lot if hobbiests out there who crack games just for fun.

I would say the best bet would be to have the game download assets needed for the game to run when the user reaches that level. A sort of "just in time" check. That way they can't patch the game to just ignore or the check.

Another thing you can do is make sure the connection goes over https, and you use certificate pinning to make sure you're using the correct cert.

The reverse engineering stack exchange may be able to give you more suggestions on how to prevent reversing of the binary (cracking/patching)

So to answer the question Scenario 1: use https with certificate pinning Scenario 2: the source isn't all that necessary, a reverser can reverse from a binary (which is how it's done normally). Avoid a single variable check, download assets, and check what the the reversing stack exchange.

Answer 2

Scenario 1: the player can sniff the network.

This can be kind of prevented with HTTPS.
Only, if the player has full control of the client he might patch the client in order to provide and maybe modify the plain text information directly at the application (i.e. game). But this is not covered by your assumptions in scenario 1.

Scenario 2: ... and has access to the source code of the game (not of the server).

Make sure that the source code the client has is not sufficient to play the game, i.e. implement relevant parts of the games logic out of reach of the client: at the server. How this can be done depends a lot on how the game works.

Apart from that you can try to obfuscate the code to make reverse engineering harder, digitally sign any messages from the server so that an attacker cannot fake these (although he might just change the code to disable the signature check) ... But at the end you can only make it harder and not impossible. Knowledgeable players might for example try to write their own server which implements a similar game logic you have in order to be no longer dependent on your servers.

This means is must be easier and more attractive to pay you instead of trying to hack the game. It can help for this if the game is cheap enough to begin with. Or if there are attractive out-of-game items which make it worth to pay.

As for making hacking harder it might be useful to have several versions of the game with different kind of protections in it so that "generic" hacks will only cover few of the game versions which makes it again more cheap just to buy instead of to hack the game. Or make parts of the communication specific for each game installation, i.e. depending on the user id user for authentication. Another way against the spread of generic hacks is to release new versions regularly which interact differently with the server and which would require the development of a new hack, thus frustrating users which rely on the hacks instead of paying.