Six Strategies for Protecting Your Mobile Games Against Hackers, Crackers & Copycatters
(Originally published at Gamasutra on June 10, 2015)
Last month I explained why Western mobile game developers need to worry about app piracy and copycatting, even outside of Asia, and promised to offer some protection tips. This post will review six strategies worth considering, based on best practices that I’ve learned developing games over two decades, adapted for the mobile environment. Game developers deal with hacking and piracy no matter what our platform of choice (the recent PS4 jailbreak, illegal MMORPG servers, server hacking, etc.), but as it fast becomes the industry’s largest market, bad actors are focusing more and more of their energies on mobile.
Before I get into the specifics, a couple disclaimers:
- Security strategies are reliable only if they’re implemented before launching your game to the public. This is very important to keep in mind, so I’ll explain in more detail down the way.
- No solution is ever bulletproof, esepcially on a platform which evolves so quickly, and so many people motivated to hack your game for profit.
As you’ll see, these solutions are less about creating impregnanable barriers, as slowing down and discouraging would-be hackers. The vast majority of mobile game hacking and piracy is motivated by profit, so the more time-consuming an app’s security systems are to penetrate, the less attractive a target it is.
I. Memory Hacking Prevention
Free-to-play mobile games monetize on items through in-app payments, which help players bypass obstacles faster, perform better, etc. Memory hacking can isolate where these item values are stored and change them, or give the hacker access to unlimited gold/cash using the same method. Here’s how that works:
In most games, when a player performs an action, the record of that action and the results are recorded in local memory (on the mobile device in this case) then batched up before being sent to the server. They’re transmitted as batches because uploading each and every action one at a time would result in massive network lag, and hurt game play experience. However, this enables memory hacking tools to target the batch upload point, and attach an external memory modification tool to the app’s memory, so the hacker can modify the game actions — including access to in-app payment items. (Some of these memory hacking tools can work regardless of whether a game has been decompiled or not, so it’s important to create or use a third party solution that is comprehensive in the protection that it offers.)
Detecting and preventing any external memory modification attempt can help prevent this kind of hack from occurring. This can be self-developed, if the developer is confident in his or her ability to create memory hacking detection/prevention measures; otherwise, commercially available solutions can be integrated into the game. My personal recommendation is to do your research and choose a commercial solution; memory hacking programs continue to evolve and improve, and commercial services are able to devote more resources to this than an average game developer.
Estimated time to implement: Depends on whether the solution is delivered via binary injection (which can take minutes), an SDK integration (this can take from a few days to a few weeks), or developed in-house (a few weeks to a few months).
II. Source Code and String Obfuscation
Source code in plain text English is easy to read, but when that text is replaced by symbols and numbers, not so much. Obfuscated code slows down a hacker’s ability to understand the code, let alone find exploits within it.
Estimated time to implement: A few minutes to over an hour, depending on the complexity of your code. At Second Wave Games, for instance, we opted to use the free obfuscator/packer provided by Google for our Android game. It took us about an hour to read through the documentation and related Stack Overflow posts, then another hour to implement.
III. Binary Level Obfuscation and Encryption
If source code obfuscation is the equivalent of locking the safe in your bedroom, binary level obfuscation is the equivalent of locking your front door and erecting a gate around your house. This method obfuscates code at the app file level, making it much more difficult to decipher. And because the contents of the app itself are left intact, this method doesn’t impede app performance.
This strategy offers good protection against reverse engineering, which requires decompiling of the binary file. Which unfortunately, is a fairly common hacker technique.
In my first article, I discussed how Lilith Games had its binary reverse engineered so the source code could be copied to create a new game. Oniix Games, a studio based in Boston and Shanghai, just had to contend with this very thing:
“In a recent game we published,” Oniix’s Everett Wallace tells me, “we came across a game that had actually reverse-engineered our partner’s game, managing to go live into the stores just one month after the official game was launched worldwide.” (See screen capture above.) Obfuscating and encrypting the binary file can prevent this from happening.
Estimated time to implement: Depending on the solution, integration can take months (for solutions requiring deep integration from the app’s initial development), to two or more weeks with an SDK. New solutions are available to cut this time down to minutes. One that I recently helped test requires a simple file upload/download (full disclosure, a solution created by my own company) and the entire process only took me 10 minutes to complete.
IV. Encrypt Keys, and Make Them Dynamic, Not Static
The number of times we find static, hard-coded keys in a game’s source code in plain text is astounding. It’s not just smaller developers. We see games and apps by major publishers as well as prominent corporations using one token across all their installs.
For instance, this was one of Snapchat’s security vulnerabilities as reported by Gibson Security:
Thanks to the symmetric encryption used by Snapchat for every snap ever sent, if malicious users gained access to Snapchat’s servers, they could potentially:
- View all currently unread snaps (without anyone knowing).
- Modify or replace currently unread snaps (without anyone knowing).
- See old snaps already sent. Snapchat claim to remove snaps once seen but the only people who can be sure of that are Snapchat themselves; as users, we’re just taking their word for it.
Whether it’s a key you are using to encrypt data that is communicated or stored on the device, hard-coding them in plain text means that the encryption is going to be easily compromised.
Think of it this way: You would never use one key for all your cars, and you shouldn’t be using one password across all websites. Perhaps even more important, you would never make that key or password readily available for others to use or copy.
Encryption keys are one of the cornerstones of secure Internet services, but they must be used correctly. Whenever possible, use dynamic keys, and if you must use a static key, make sure you encrypt it.
Estimated time to implement: A few hours to a few weeks, depending on how far along you are in the game development cycle, and how much work is involved in identifying all the keys that need to be addressed.
V. Real Time Payment Verification
App stores issue a payment verification code whenever an IAP purchase is made. Until that purchase is redeemed by the game server and sent back to the app store payment servers for confirmation, it’s possible for the payment verification code to be reused multiple times, sometimes across different applications.
Due to banking regulations and the way credit cards are processed through clearinghouses, sometimes a credit card charge will go through instantly. Other times, it will take a day or two for a charge to show up or go from “pending” to “posted.” (Verifications are sometimes batched up and processed once every few hours, or once a day.) For example, Uber processes credit card payments in real time; a Lyft ride, however, will take up to 24 hours for the charge to show up in my purchase alerts. This creates a scenario where fake credit card numbers, as well as stolen credit cards, can be used to make in app purchases.
This time of hack is fairly widespread. Mobile analytics company Appsalar reported tracking “fraud rates in excess of 50 percent on jailbroken devices.” Game platform developer SOOMLA recently described how IAP fraud occurs, noting that one of its customers, a game developer, supposedly earned over $1,000 after the first day, then noticed that Apple’s revenue report revealed that he’d only actually earned $1–2.
By performing real time payment verifications on the server-side, you can prevent multi-use abuse cases of payment codes, and reduce fraud cases of invalid credit card information.
Estimated time to implement: This should only take a few hours to days to implement at most, and is not difficult to do once you understand how IAP systems work. When integrating the IAP system, make sure your servers are doing the server-side check immediately upon purchase.
VI. App Security Monitoring in Real Time
A locked door is safe. A gated building is safer. Far more effective is a motion detection system installed around the outer perimeter, alerting the owner to monitor potential threats long before the building is even breached. An emerging field of analytics makes something like this possible, enabling developers to track their apps in the wild, monitoring attempted hacks, and tracking their frequency and point of origin. While there’s only a few services currently on the market, they’re worth researching and considering.
As the saying goes, a system is only as secure as its weakest link. It goes without saying that server-side protection should be implemented with firewalls and server side security software; communications should be over SSL and other “more safe” methods. Now we should be applying that same logic to the client side of the app. While sensitive data is stored on the server-side, access to that data is through the client. Going back to the locked house analogy, a key entry system is safe — but a retina-scan system with fingerprint recognition, heat detection, and digital door lock with a surveillance camera is even safer.
Estimated time to implement: There are a couple solutions available in the market, with implementation times ranging from a few minutes to a few weeks — my own company offers one, while our colleagues at ARXAN offer another. The real time committment here though, is the constant monitoring that is required. For that reason, I believe it should be integrated into the Customer Service/Game Ops side, since a similar tracking function is conducted by the game operations side in other platforms, including MMORPGs.
Security First: Why Post-Launch Solutions Are Even Costiler
As I said at the start, security strategies like these are only reliable when they’re implemented before the app appears on the market. This is so important, let me reiterate: If you try protecting your app after it’s already in app stores, it’s too late. After a game’s already been released, it can sometimes require weeks of development time to retroactively change the code to be more secure.
And by then, as we see too often, hackers may have already done their worst. As I mentioned in my previous Gamasutra post, pirated versions of a game may show up in one region before the original developer has launched the official version there. In China, where Google Play is blocked and there are literally hundreds of Android app stores, the developer can sometimes finds themselves competing with dozens of pirated versions of their own game. For those reasons and more, it’s far better to implement security practices from the beginning, before the app even appears in the wild.
I understand this runs counter to the way mobile games, especially free-to-play games, are typically developed. They’re a living product with continuous updates and improvements. As such, most games initially launch with an MVP (minimum viable product) version, and evolve with more content over time. Product deadlines come up fast, and as developers race against the clock, they sometimes face the choice between incorporating all planned features or launching on a set schedule. In this process, security usually takes a back seat, relegated to “nice to have but we have no time” status.
Unfortunately, the era in which security is simply “nice to have” is long gone. The mobile games industry is a space worth many billions of dollars, where a single title can gross close to a billion in just one year. And it’s still growing. With so much at stake, spending a few hours or even a few days implementing security precautions is a must, and part of the cost of doing business.
You can find our own SlideShare with more technical details on how those attacks are possible and prevented.
