Hacking is an incredibly misunderstood term. The media has portrayed the practice at one of two extremes — either a hacker is a hooded, mysterious “anti-hero” fighting the big bad evil of corporatocracy, or a stereotypically capricious counter-culture hero shouting “hack the planet”.

The fact is that hacking is generally done for a single purpose — self reward, typically driven by sighting obvious vulnerabilities. Whether this means a system is broken to steal credit card numbers or to simply develop a tool that a developer has yet to develop internally, hacking is generally focused on self-reward.

Today, we’re going to dissect one of the most commonly hacked industries in the world — mobile monetized gaming. We’ll discuss the common vulnerabilities inherent in these systems, how they are generally hacked, and how to prevent this from occurring and disrupting a developer’s revenue stream.

Defining Hacking

First thing’s first — we need to define hacking. The earliest hackers were termed so for their skills in “hacking apart” a machine or device. One of the pre-eminent hackers of the early community focusing on telephones, the “phreakers”, was John Draper, better known by his moniker “Captain Crunch”. The moniker was apt — he had the ability to use a whistle obtained from a Captain Crunch cereal box to whistle tones that would break the AT&T network. In one case, he [claimed to connect through phone switch boards in countries such as Japan, Russia, and England. After routing, he would call a payphone next to him, and when it rang, he would speak into the phone, waiting a few seconds before hear himself faintly in the first headset.

Though hacking took a decidedly darker turn as credit cards and banking took to technology, most modern hackers aren’t malicious. Keep in mind that throughout this piece, when we reference a hacker, that’s who we’re referencing — the sixteen or seventeen year old that does not like the “freemium” model of mobile gaming, who just wants a few hundred of the game’s fake currency or to fool a timer restricting their progression.

With that in mind, however, we must make one thing clear — Nordic APIs does not condone hacking, and this piece is not to be considered a guide to hacking or an inspiration therein. By exposing these methods, we hope to give API developers a look into the mindset of an API hacker in the gaming space, and the vulnerabilities that they typically look for.

Vulnerabilities of Gaming – Static vs Mobile Gaming

What makes mobile gaming so hackable? What makes it so attractive to break, and so easy to circumvent? To understand that, we must first understand the difference between static and mobile gaming.

When we say static gaming, what we really mean is “home” gaming. This might include a console, a PC, or even an arcade cabinet in a bar or pizza joint. These devices are generally hard to hack, and are thus not very attractive to the average hacker. Consoles are designed to not allow circumvention of anti-cheat systems or for homebrew software to run natively, and arcade games are typically in big, bulky cases, locked from the general public.

PCs are a little bit of a different story, as these devices allow for quite easy hacking for knowledgeable users, but require a very high level of knowledge and ability to get around obfuscation, proprietary code, and so forth. For this reason, piracy is very popular on the PC, though the pirated releases are often quite delayed.

All of these static gaming situations have one thing in common, however — they all handle processing internally. Think of Metal Gear Solid, Kerbal Space Program, or even older games like Tetris. With very few exceptions (typically in multiplayer games) games in static environments will carry out the data processing, video delivery, mechanics, etc. natively on the system on which it is installed. This means that the hacks, again with very limited exceptions, generally stay within the system with which it originated.

Mobile gaming is an entirely different story. Mobile gaming, by its very nature, is designed to work on lightweight platforms. Even though mobile devices have gotten much more powerful than ever before, the fact remains that processing, score ladders, and even in-game mechanics are often sent from the device to an external server, where the data is then processed, repackaged, and delivered for on-device handling.

This exposes a massive security flaw that is not inherent in the static gaming world. Barring multiplayer functionality, all of the mechanics, progression systems, and so forth in static gaming can typically be handled off-line. While mobile games can still be played offline (as in the case of a game like Fallout Shelter), many games (including Clash of Clans and Candy Crush) depend on online functionality for the bulk of their gameplay.

In short, data must leave the device via an API, enter a server, leave that server again, and return to the device. This exchange creates three unique vulnerabilities that can lead to effective hacking and breaking of API monetization schemes.

Mobile Vulnerability #1 – Devices and Calls

The first of these steps is when data first leaves the phone. This represents possibly the largest area of hacking in the mobile gaming industry, and by far the easiest of approaches — hacking through code modification or code injection.

Let’s look at a scenario. A new game, called API Quest, has just been released. In this game, you build strongholds to defend against security threats, and dress your knights in special mithril armor designed to resist any attack.

The rub? Creating these defenses and arming your knights takes in-app currency which can only be collected by automated generators, which grant funds every five minutes. Conversely, this currency can be purchased, establishing an active opt-in currency stream.

An insightful gamer looks at the game code, and realizes something interesting — the player is defined, and the funds received are generated by a URI call sending a request to a server for a timer notice. This might be structured as such:

player class.id { role:player}

This information is held on device, and is then sent to a remote receiver via a URI to request the timer status:

GET https://apiquest.com/statuscounter/{role}

This request utilizes a proprietary API which utilizes the system data on-device to generate the role substitution. When the role is substituted for “player”, the request is sent to a server, which uses a load-balancer to distribute traffic, and then checks an on-server timer.

Unfortunately, this information is based on-device. The gamer realizes this, and edits the game code to reflect his role as “devuser”, and figures out that the API also uses a similar check to verify user status:

GET https://apiquest.com/userstatus/verify

They then edit the device to reject a call to the verification service, which fails over without a backup. By editing the game code, the user has set themselves up as a devuser, with access to a one second timer by which all of their equipment and generators are based on.

Here, we have two vulnerabilities — code obfuscation and call integrity. Because the code was un-obfuscated, and thus unhidden, the user was able to see exactly how the URI utilized the game code to generate verification information for the remote timer, and was able to change it to break the system. Additionally, because the device had no call integrity checking, a call was sent from a signed, trusted device, which the server implicitly trusted.

The answer is simple — obfuscate your code, and check all calls leaving a device. The developer implements a call checker in the game, which will check all data leaving the application to make sure nothing is being injected or modified. They further obfuscate the code.

Mobile Vulnerability #2 – Server Integrity

A new patch has come out, breaking the gamer’s cheat. Angrily, the hacker examines the device and notice the code is now obfuscated, and the old methods changed.

Knowing that a poorly formed URI call was to blame, the hacker decides to test the server. URI calls are now checked by the game before being sent by the device, negating their original attack. They notice, however, that the server they attacked had a front-facing IP address and name scheme — https://apiquest.com/.

Testing the system from a PC, they send a URI request to the server, and find it is accepted, but they are rejected as being a “non-registered device”. The gamer then uses their device, finding the device’s IP address on their private subnet, and appends it to the original call by routing it through the device.

Now, they are able to send a request under the device’s address without first going through the game, bypassing the on-device restrictions entirely.

Here, a third vulnerability — though the game itself verified URI calls and the server was now designed to resist poorly formed calls, newly discovered calls could be sent independent of the application. Poor server security resulted in effective hacking of the URI, breaching the server. Though the phone was reinforced, the server was not.

The answer here is simple as well — implement URI constraints at the server level and reject incoming traffic that does not match the protocol managed by your device checking system.

Mobile Vulnerability #3 – Server Response

The gamer notices that their hack is no longer working. The server now has additional constraints, and requires the following for an effective request:

GET https://apiquest.com/statuscounter/{role}
User-Agent: AndroidMobile
Accept-Language: en-us

This now establishes a connection from a known agent, limited to mobile devices.

They’ve tested all outgoing traffic, but nothing is effective. They notice that the calls that come back are in plaintext, and completely unobfuscated. When the server responds, it responds with a set of codes:

reward-user:10g
timer-reset:120s

This rewards 10 gold, and resets the local timer to 120 seconds, which is the time between URI calls. Knowing this, the gamer intervenes as traffic comes through their router, capturing the packet and terminating it. They then adjust this packet, changing the data to instead read:

reward-user:99999999999g
timer-reset:9999999999s

This call gives them near infinite gold, and forces the URI calls to effectively stop functioning (due to the timer check value being changed from 120 second to 9999999999 seconds), meaning that any anti-cheat or status checking system, as shown above, would cease working correctly.

The solution here is the easiest of all — do not use simple responses. Instead of rewarding an amount generated off-device, set the amount on-device, and instead tie the timer to the internal clock and the server clock, which both must agree before releasing gold. This has the added benefit of disallowing zero-day exploits that can use this issue in security to launch massively coordinated attacks — pitting your own application against its own servers.

Functionally, all of these issues can be properly fixed with two simple steps — obfuscate code and calls, and encrypt the connection between the device and the server.

Conclusion

In the API world, whatever architecture style you choose, and whatever language you design in, security will always have to be a large and specific focus. Android, iOS, and Windows phones must be treated as what they are — powerful devices that can rival even the best security designs.

With intelligent obfuscation and preparedness against common pitfalls, however, these threats can largely be avoided. To capture a hacker, you must think like a hacker. Consider your application the same way you would a bank account or a home — and ask yourself, “is this as secure as it could be?” Better to find out now than to let someone tell you later through their devious actions.