Protect‌ ‌your‌ ‌game‌ ‌and‌ ‌players‌ ‌on‌ ‌Google‌ ‌Play‌

Developer tools and services to strengthen game integrity and fairness

After building a great game, you want to get it out to players and have it experienced the way you intended. However, the more popular your game gets, the more it may attract attackers and abusers you don’t want. There are many different reasons why people might try to modify your game and abuse your distribution and monetization choices: some may be relatively harmless while others could adversely impact your player community and your business. So it’s important to think about your anti-abuse strategy and take appropriate steps depending on your goals. While there is no perfect solution to protecting a game, in this post I recommend some Google Play tools and services which can help as part of your overall strategy.

Integrity

Attacks on games and players often originate from untrusted environments such as modded APKs, emulators, and compromised or rooted devices. These may not be bad by themselves but, by detecting them, you can make a choice about how your game reacts to them depending on your objectives. For example, you might want to block pirates from playing a paid game whereas, in a free online game, you might want to put all the players whom you suspect of using emulators on the same server.

In this video, I recommend Google Play tools to protect your game’s integrity

Google Play offers APIs for online games to help you more easily detect these situations so that you can then decide on the right course of action. In addition, Google Play has a new developer preview of automatic integrity protection for games which work offline and for online games trying to reduce repackaging.

Manual, server-driven integrity check

Firstly, Google Play licensing ensures that the player is using your unmodified binary that was installed by Google Play. Secondly, SafetyNet attestation lets you know the state of the device your binary is running on.

These checks work well in online, server-driven games when they’re attached to one or more pivotal moments in your game such as game startup, log-in, matchmaking, purchasing, and so on. Performing the checks client-side without attaching them to important moments makes them vulnerable to being removed by an attacker. Generally you integrate these checks as follows:

• Generate nonce: Generate a nonce on your server to initiate the check. A nonce is a unique, random value you attach to each check to make it hard to replicate a positive response in a replay attack. Use as many unique bits of information specific to the request as possible, such as a hash of the user ID, to generate a nonce that is difficult to repeat.
• Request response: Attach the nonce to the check in your game and call the licensing and SafetyNet APIs. SafetyNet integration requires an API key and has a quota limit of 10K requests per day. If you need more than this, you can request a quota increase.
• Receive response: These APIs communicate with Google’s servers. Google’s servers return a response to let you know whether the user has a license for the app from Play and whether the device appears to be a physical Android device that has passed compatibility tests. You should also be prepared for cases when the SafetyNet response times out, which can sometimes happen to avoid abusive calls.
• Transfer response: Your game should return Google’s responses along with the nonce to your server. Validation should be handled server-side to make it harder to remove the check from your game.
• Evaluate response: Your server should check if everything is valid — the nonce, your app’s package name and hashes, and the timestamp — and then make a determination based on Google’s responses about the license and device. For example, if the user has a valid license and the device is trustworthy, the player can be allowed to proceed in the game.

How did these APIs perform in real games? Watch this video to hear how Rovio was able to improve Angry Birds 2 leaderboards and how Supercell significantly reduced unauthorized players from playing the Brawl Stars beta before launch.

Automatic, client-side integrity check

These APIs don’t help for all types of games and use cases. Your game may be designed to work offline, as many paid games and single-player games are. For games with only light server-integration or no servers at all, Play is looking for close partners to join a developer preview, Google Play’s automatic integrity protection.

For games enrolled in automatic integrity protection, Google Play adds a licence check and anti-tamper protection to your game’s code on your behalf when you upload it to the Google Play Console, with no development work on your part needed before testing. The only requirement is to publish your game using the Android App Bundle. A benefit of the protections is that they’ll be improved and changed over time without any work on your part. The anti-tamper protection may also benefit online games that are trying to reduce repackaging. Express interest in getting your upcoming releases protected.

Fairness

For games with in-app purchases, balancing a fair game economy ensures the best overall player experience while continuing to grow your business. Bad actors may look for ways to manipulate purchases and items in order to gain a one-up on other players or for direct financial gain. This hurts other players as well as your business. Google Play Billing has tools you can integrate into your game which can help Google detect and reduce fraudulent purchases and abusive refunds.

Validate purchases

As much as your game design permits, seriously consider moving sensitive data and logic to your server, including validation of in-app purchases. Doing this in your game client-side makes it more vulnerable to reverse engineering. When validating a purchase, send the purchase IDs to your game’s server, check that the ID hasn’t been used previously, then verify the purchase is legitimate with Google Play via the Play Developer API before granting the user entitlement to the item in your game.

In addition, you can ensure purchases are attributed to the same in game account or character profile by sending obfuscated account and profile IDs to Play when launching a purchase. When validating a purchase, send these IDs to your backend to ensure the user receiving the entitlement matches the user who made the purchase.

Fraudulent purchases

You can improve Google Play’s ability to detect and block fraudulent purchases in your game by including some non-personally identifying information about the purchaser with each purchase request. Specifically, you use these methods to attach the obfuscated game account ID for the user to each of their purchase requests and you should attach a second profile ID representing the user across all of your games if you have multiple games. Google’s risk engine uses these IDs to make an assessment of whether this is a fraudulent purchase and helps prevent resale abuse. Top developers have adopted this Google Play Billing feature with positive results: up to a 30% decrease in fraud attempts and reduction of up to 50% in chargeback losses.

Refunded item status

Google Play is testing a feature where games can help inform Play’s refund decision by providing more information about in-game purchases. This helps streamline the refund process and reduce abuse, for example by more easily identifying users who repeatedly refund already consumed items. When a user requests a refund, Google Play will pass information about the request, including the user’s reason for refunding, to your game. Your game shares the status of the user’s item, for example whether or not the user has used it already, and a recommendation as to whether the refund should be granted. Google Play uses this information to help make the right refund decision. This feature is being tested with close partners, you can talk to your partner manager to find out more or look out for wider availability in the future.

Voided purchases

With the voided purchases API, you can request a list of refunded in-app purchases for the user from Google Play at any time. You can then use this to update the player’s inventory and remove refunded items or make other changes to the player’s experience. Doing this both maintains the value of your in-game items and helps reduce the incentive for abusive behavior. Over 80% of top developers are now integrating the voided purchases API and some have seen up to an 80% percent reduction in the value of their refunds. Here are some tips for how to use the voided purchases API effectively:

• Call the API frequently and regularly to update the list of items the user has purchased.
• Remove refunded items from users’ accounts.
• Inform users when you remove items.
• Take action if a clawback fails and consider escalating if it happens multiple times, for example by restricting purchases.
• If the user already spent in-game currency, make their account negative.
• Consider limiting in-game features or abilities while an account is negative.

Security

Secure Android development is a big and important topic and I’ll only touch on it briefly here. Attackers can take things to a much more serious level for you if they uncover and exploit vulnerabilities in your game. This could put your players at risk, cause negative PR for you, and in some cases even result in fines from regulators. We recommend following security development best practices and evaluating the security checklist when building your game. Take special care when handling data, permissions, or network traffic.

Third-party libraries and SDKs

Given that third-party libraries and SDKs often make up the majority of a game’s code, they can represent your most significant security risk. Sometimes libraries are malicious but, in most cases, the risk comes from weaknesses in the library or SDK. Because you’re responsible for all of your games content, including third-party libraries and SDKs, security breaches through this vector are also your responsibility. Google Play has suspended games for issues created by SDKs that the game developer was unaware of. To that end, keep in mind these best practices:

• Analyze data and device information accessed by any SDKs and get appropriate user consent before any data is accessed.
• Ensure SDKs support the minimum targetSdkVersion.
• Ensure the SDKs do not collect non-resettable hardware identifiers.
• Remove any SDK-specific files from external storage when your game is uninstalled.
• Uses HTTPS-only for communication to any servers.

You can learn more best practices for using SDKs in the Play Academy.

Google Play security rewards program

Finally, popular games with large audiences may want to apply to join the Google Play security reward program. This is a bug bounty program where Google will pay security researchers to find and responsibly disclose vulnerabilities in your game, which you can then fix, protecting your users for the long term.

Final thoughts

Every economy attracts bad actors and mobile games are no different. Whether it be the relatively low risk, such as players simply wanting to get ahead, through to those wanting to manipulate games or players for financial gain, Google Play provides a growing range of tools and services to help you respond appropriately and minimize the risk to your players and your business as part of an overall anti-abuse strategy. As ever, please let us know your feedback on how these tools could be improved and on what’s missing.

What do you think?

Do you have questions or comments on integrity protection? Let the team know in the comments below or tweet using #AskPlayDev and someone will reply from @GooglePlayDev, where you can find regular news and tips on how to be successful on Google Play.