Off-by-One Mobile

Hey, I'm Adam, artist for AutoTrafego.

Background

I'm a professional artist in Vancouver that's been doing video game art since 1999. My (somewhat dated) website is here. It's a long story that I may outline in a later post but after the game industry apocalypse last winter I ended up doing iPhone contracting and eventually hooked up with Dominique to do AT.

How it's Done

AT was originally supposed to be an isometric tile-based game (I've worked on several before on mobile platforms). The tile engine requirement was later dropped but things ended up so predictably aligned and easier to code that the iso 'look' was maintained. A huge selling point was to be as polished and professional as possible so a high level of quality was called for. Last year I had been working on some 3d city-building processes so I booted up Max and got to work adapting them to the environment.

Here's the initial result:

Automating the geometry creation is actually the easy part of the problem - the big issue that kills most city generators is the massive amount of texturing needed to look convincing close up. From a few thousand feet away you can get a pretty nice city (flight games take advantage of this, and with modern hardware can be pretty dense and stunning at a distance). But at close range it starts looking computery and there's no really effective way to deal with it yet. In fact city-based games like Grand Theft Auto are hand-built by art teams or cloned wholesale from real cities. My techniques are kind of a hybrid and worked quite well at AT's scale. I also had to enforce a certain block size to fit the isometric environment.

The next challenge was the streets and cars. Possibly someday we can move to a city design with curvy roads and the resulting traffic complications, but for now AT is straight lines and intersections. AT's vehicles are all 3d rendered, right down to the brake lights. Ridiculous overkill for the size the cars appear at in-game but is in keeping with the focus on quality (see a super pixely blowup of an SUV below).

Halfway through the project I wanted to move to rural areas for some variety so we moved away from city generation (only 3 of the 7 levels ended up as urban areas.) But overall we've been quite pleased with the results and we get a lot of compliments.

The announcement of the availability of In App Purchase for free applications has caused a lot of discussions. While this is a welcome move for many reasons, in its announcement email Apple claims that

“Using In App Purchase in your app can also help combat some of the problems of software piracy by allowing you to verify In App Purchases”.

While this is partly true, it’s a bit more complicated than that, as is often the case with security. At least, Apple recognizes the widespread piracy problem on the iPhone. Since I have already read several clueless blog articles on the present subject, I will try to give an overview of iPhone piracy and what In App Purchases mean in this context.

My qualifications on this subject matter

Before I started developing iPhone applications, I worked for 8 years for Nagravision, where I led the pay-TV anti-piracy monitoring team. My job was to protect pay-TV operators like the Dish Network, Bell TV or Digital+ against piracy. That meant, in a few words, following the pirate scene, reverse engineer exploits and use this knowledge to design new security smartcards.

A brief description of the iPhone app cracking process

I will not go into details here. All the information can be easily found online, and I don’t want to get in the sights of DMCA zealots.

iPhone applications are encrypted and signed. However, on jailbroken phones, crackers can easily dump the unencrypted data from memory while the application is running. A small modification of the Info.plist file of the bundle will then allow unencrypted applications to run on a jailbroken iPhone.

Several automated scripts that do the whole cracking process have been released in the past.

Custom anti-piracy protections

Apple offers no official methods for developers to detect pirated applications. However, several ways to detect the artifacts of the cracking process have been documented (link, link ). The simplest one is to detect if the Info.plist has been modified as indicated in the previous section. Applications can act on the detection of piracy by reverting to a lite version or stop working altogether. Our game AutoTrafego reverts to a lite version for example. Crackers call those applications “self-aware”. They usually have no other choice than disassembling the application (with the professional reverse engineering tool like IDA Pro) and patch out the anti-piracy checks. Famous cracker teams like ARTEam have published (pretty lame in my opinion) guides and tutorials to that effect. More advanced protections are usually taken care of by hard core pirate scene groups like COREPDA.

Two Worlds

When talking about anti-piracy protection, many people forget to separate applications in two categories: online applications, and offline applications. For the purpose of this article, online applications are those that can’t work without an Internet connection, like news readers, social apps or MMORPGs. Offline apps are most games or applications that can be played when no network is available, for example during a plane trip. Applications that use the network for the sole purpose of DRM checks are considered as being in the offline category.

In the PC world (or Mac if you prefer), offline applications have been routinely cracked and pirate versions distributed widely. Advanced copy protections can slow down the process, but in the end, most offline applications get cracked. Therefore, many publishers turned to online applications because pirating those is virtually impossible. Indeed, all the security checks are on the server side, and users either need a unique serial code only given at purchase time or must pay a monthly subscription to access the content. World of Warcraft is a good example of an online application.

The situation for offline iPhone applications is basically the same as for the PC. Crackers remove protections from applications and freeloaders get the cracked versions from specialized websites to install on their phones.

The situation for online applications on the iPhone is very different though. Publishers don’t have a sure fire way to ensure that only paying customers use their applications, and they end-up bearing the server costs generated by pirates. When you think that, according to some estimates, the piracy rate can be as high as 90%, this is a very bad proposition. So while online services helped PC applications maximize revenue and minimize piracy, the opposite is unfortunately true in the iPhone world.

Introducing In App Purchase

I will not discuss the commercial benefits or problems with In App Purchase here, many others have done it already. I will only discuss the technical aspects and how they relate to piracy issues.

One point I would stress it that it is probably not very workable to replace paid apps with free apps featuring In App Purchase for devices that are never connected to a network and only get all their downloads through a cable connection to a PC via iTunes.

In App Purchase and offline apps

I disagree with people who claim that In App Purchase will make offline applications more secure. As the Apple documentation states:

Functionality : products unlock or expand features you’ve already delivered in your application. For example, you could ship a game with multiple smaller games that could be purchased by the user.

That’s basically In App Purchase for offline applications. In that scenario, crackers can still just patch applications to remove the purchase checks. I fail to see how In App Purchase gives more protection than self-aware apps. As I will show below, I even believe In App Purchase can make offline applications less secure in some cases. This might however change in the future.

In App Purchase and online apps

In this case at least, In App Purchase should drastically limit piracy since publishers can now verify purchases directly with the App store. Of course, this is only true as long as long as publishers implement the server side store receipt verification checks correctly.

As I will explain later, I still see some outstanding potential issues with the In App Purchase system though.

Complexity is the enemy of security

Any good security engineer knows that “complexity is the enemy of security”. And from what I have seen in the API, setting up In App Purchase is pretty complex. Therefore, it is hard for me to expect that most developer will make implementations that are secure. Keep in mind that many iPhone developers can barely put an app together with the help of the community; at least it is what I have seen while participating in several developers forums.

The simple fact that even a basic setup of In App Purchase, without even considering security aspects, is complex makes me believe that it will not mean the end of lite versions at all. Indeed, developers must setup a shop in their application, process transactions, keep track of purchases, etc. (link)

Now, taking into account security aspects like securely verifying store receipts or making sure that successful transactions are indeed legit can be pretty complicated to get right. In IT security, any small mistake will usually result in vulnerabilities.

Are In App Purchases really secure?

In order to explain the problems I currently see with the In App Purchase system, I will briefly detail some parts of the API.

When a transaction is executed, the application receives a SKPaymentTransaction with a transactionState property that indicates if the transaction was successful:

SKPaymentTransactionStatePurchased
The Apple App Store successfully processed payment. Your application should unlock the content the user purchased.

As one can see, there are absolutely no cryptographic challenge or verification steps. Apple doesn’t even mandate any further check on the transaction:

A successful transaction includes a transactionIdentifier property and a transactionReceipt property that record the details of the processed payment. Your application is not required to do anything with this information. You may wish to record this information to establish an audit trail for the transaction. If your application uses a server to deliver content, the receipt can be sent to your server and validated by the App Store.

I didn’t test it because I don’t want to get into trouble with the DMCA, but I believe that crackers could write a Mobile Substrate extension that would hook the In App Purchase API and always return fake successful transactions. This would probably fool most applications that don’t implement any countermeasure to verify that transactions haven’t been tampered with. This would make it even easier than before to steal offline applications. Pirates would just have to install the extension on their jailbroken phone and then download “free” apps from the app store and finally simulate purchases.

For those who are not familiar with the jailbreaking community, Mobile Substrate is a framework that allows easy modifications of the behavior of iPhone applications by intercepting and subverting API calls.

At the moment, Apple doesn’t offer any way to securely verify transactions directly in the application. However that will hopefully change in the future:

Note: The format of a receipt and the interface used to verify its contents will be documented in a future seed.

Further risks

I have already outlined some of the problems with the In App Purchase API, but I still wonder how it deals with some of the usual security risks.

For example, I wonder what would happen if pirates were to buy content with gift certificates, log the transactions and then redistribute the legit transaction logs with cracked applications. The cracked applications could be modified to always return those dumped logs for server verification. This could also be the start of Trojan Horse applications meant to steal transaction logs on jailbroken devices.

I also don’t see any way in the API to verify if a transaction is valid for the current device. Developers could try to limit how many different devices can use the same transaction, but I think this will only be the beginning of major headaches since Apple customers can change their authorized devices in iTunes.

Another problem is that developers must store somewhere that a product, like a level for example, has been bought. Unless much care is taken, purchase data couldbe trivial to modify for a pirate. In many applications, that kind of information is simply stored in the apps’ “defaults” or in sqlite databases.

I even wonder if such a method could be used to illegally activate In App Purchase features in non-jailbroken devices through the modification of iPhone backups. According to this site, it is theoretically possible.

DRM Hell – There is an app for that

Some readers will tell me that developers can alleviate the risks by verifying receipts online. Indeed they can, but as I already mentioned it’s hard even for security experts to do that kind of stuff right.

This will also cause more problems than it solves in the case of offline applications. At some point, if hooks that defeat the In App Purchase API start to appear, developers will undoubtedly want to verify receipts online. They might chose to do it in an opportunistic way, only when a network connection is available, but crackers could easily block those verifications, like they block ads and analytics solutions with software like PrivaCy.

On the other hand, developers might chose to force online verification of receipts on each run, even for offline apps. If some do that, they will open the same Pandora’s Box that caused such hate of DRM on other platforms. What happens when someone wants to use such an application without a network connection while on a plane? What if the developer, like many unfortunately, is not making money with his app and decides to cut his loses and shuts down his verification sever?

Finally, a vocal minority of users already resent the use of analytics solutions as spyware, what will they think of the online verification of purchases.

Why only for In App Purchase?

One last thing I don’t understand is why transaction verification is only available for In App Purchases. The addition of In App Purchase does nothing to address the current widespread piracy problem of paid apps.

Why can’t Apple offer an API that allows developers to easily verify if their paid application were legitimately purchased? Why force developers to go free with In App Purchase in order to secure their online applications?

I mean, it’s already possible on the BlackBerry store. On a side note, a similar system could also make it difficult to pirate applications on open systems like Android, for which there is a fear of easy piracy.

A final note on jailbreaking and security

It has been largely reported that Apple took recent steps to prevent jailbreaking on the latest iPhone 3GS. Some people have claimed that the reason was mainly to curb the problem of widespread application piracy.

As my experience in smartcard security has taught me, trying to prevent piracy simply by expecting that tamper resistant hardware will stay secure is definitely shortsighted. Sound cryptographic procedures and countermeasures will usually be far more future proof (i.e. like providing APIs to verify all purchases). As I have shown, the current version of the In App Purchase API is far from secure and can’t be used to verify app store paid apps.

Moreover, jailbreaking has a lot of valid uses. The main reason why my phone is jailbroken is to have a lock-screen calendar like Intelliscreen. If someone at Apple reads this, why do most phones but not the iPhone have a lock screen or main screen calendar? If I can’t jailbreak my iPhone in the future and this is not implemented, I will switch to a competitor.

Conclusion

I couldn’t test all my theories, so hopefully I am wrong, but I strongly believe that In App Purchases are not the holy grail of anti-piracy that Apple and others claim it is. If some people have information to confirm or infirm my claims, I would be glad to hear it.