How To Detect and Prevent In-App Purchase Hacks

Here is a true story. A developer using SOOMLA went live with his game. After one day he already saw over $1,000 in revenues but when he checked Apple’s reports he realized he only made $1-2 dollars. Some other developers using GameAnalytics reported similar situations, although on a smaller scale.

What was happening behind the scenes is that a few users hacked his game and unlocked every in app purchase they could. The developer didn’t even realize that he was subject to fraud before and was very frustrated when he discovered that. The game at hand was a single player game but his next move was to turn that into a multiplayer game to increase the sense of competition. “How would my users feel if they knew that others are hacking their way through the game?” he said to himself. Where is the sense of competition?

Why Fight Fraud

There are some experts who believe that fighting fraud in single player games is pointless. I have a different opinion on this. First and foremost, mobile games are social through offline means. Have you ever compared progress when meeting them in social contexts? That’s the kind of social interaction I’m talking about. I know my sister reached level 190 in Candy Crush Saga although she is not connected to Facebook. How? Because she told me. If I knew that she cheated her way there I would be less motivated to compete.

Another aspect where fraud is a big issue is economy balancing. You would think that the game is more fun if you can simply unlock everything. In reality, that usually takes all the challenge away and a game without a challenge can be fun only for a short period of time. Well designed games have built-in mechanisms to align the pools and the sinks so that there is always enough challenge. Having an endless pool of coins or gold ruins that delicate balance. Even worse, fraud can mess up your analytics with garbage data and lead to bad balancing decisions or even bad and expensive user acquisition decisions.

How are Users Hacking Games

Here are two popular ways in which in-app purchase hacks are done:

• Faking In-App Purchases
• Overwriting the balance file

The first one is done by fooling the game app into thinking it’s communicating with the Apple or Google Play store servers when it actually isn’t. This requires a higher level of sophistication, but applies to all games since it hacks on the infrastructure level. There are multiple programs that hackers have developed and are distributing to allow players to hack their devices. If you have heard of IAP Cracker – that’s one of them.

The second one is more game specific, since every game is storing balances in a different way. This is why there are no recognizable names here. You might have seen some YouTube videos for cracking popular games – they are usually based on this method. Users with access to the file system of the device can figure out which one is holding the balances and how is the file built and then either modify that file or replace it with another file.

Preventing Fraud

While there is no data to back up this claim, I would make an educated guess that most of the hacking is done on devices that have been jailbroken (iPhone) or rooted (Android) and with games that have no backend.

Devices that are not jailbroken or rooted don’t provide access to the infrastructure levels, so it’s harder to tamper with them. However, Apple and Google weren’t very successful so far in preventing users from hacking on a device level, so I wouldn’t rely on that.

So having a server side verification might be the first step, but it’s certainly not enough. You have to figure out how to detect the in-app purchase hacks. The first thing you would want to implement is server side verification. This is a simple tool provided by both Apple and Google where the client side of your game gets a receipt from Apple, sends it to the server which then verifies it with iTunes or Google Play (This is explained well in section 5 of this tutorial).

Server side verification might help you eliminate some of the fraud, but not all of it. Specifically, if the user hacked the local storage, this might not be enough. It is therefore recommended to monitor irregular activities related to purchase transactions. You should compare the transactions report from Apple/Google to the one you have from your analytics provider and try to isolate the transactions that appear in the logs but weren’t really made. Once you found some, you can then lookup the user and get the logs for that user and start seeing patterns that usually indicate fraud. You are likely to find patterns such as these two to be good fraud indicators:

• Two transactions of the same item with no activity in-between
• Over $50 from a single user in one day

You can find more patterns and create filters that would flag these automatically. I would recommend setting up broad filters, flagging automatically and doing a manual review of a short list (up to 20 per day). You can tweak the filter and narrow the criteria if your review list becomes too long.

What you do with the users is up to you. Hiding the related activity from the analytics is probably the first step, but you can also remove their balances or even ban them from the app if you wish.