Home > iPhone > Cracking In-App Purchases

Cracking In-App Purchases

The other day I ran across poedcrack, a utility for iPhone/iPod which will decrypt AppStore apps automatically. This is definitely a step up from earlier. After testing it out I got to wondering how easy it would be to crack in-app purchases.

One obvious method would be to patch the decrypted binary so that the application thinks a purchase went through. I’m going to outline an even easier process.

Many in-app purchases simply unlock functionality of the software. The functionality is already there, just locked. I expect many apps to use plist files to save information on unlocked functionality. Therefore, if we can figure out exactly what key/value pairs are necessary in the plist to unlock functionality, we can simply edit the plist and upload the modified version to the iPhone.

According to the In App Purchase Programming Guide, an app must implement provideContent: SKPaymentTransaction* method to provide the purchased content. This method is a wonderful starting point. A probably common approach is to pull information out of the transaction within that function to know what was purchased and add a key/value pair to a plist file to unlock the feature. In the future, the app simply looks at the key/value pair to know if the feature was purchased.

Within the provideContent function, we look for calls to functions like setInteger: forKey:, or setBool: forKey:. That will give us the value and the key to add to the plist. Determining which plist will require futher reverse engineering, or simple brute force (most apps I’ve seen don’t have many plists).

Now, to edit plist files. On the iPhone, the are usually in binary format, so using a simple text editor won’t do. That is where plutil.pl comes into play. It allows you to convert binary plist files to text, edit them, and then convert back to binary.

I point out this information not to promote pirating software or to crack in-app purchases. This raises a very valid computer/network security issue. Typically, when defending a system we have a threat model. The original threat model for the iPhone was probably “it is locked, no body can mess with the files, binaries, etc.” That, however, has been broken. So, now we must either reevaluate the threat model, or fix the system so it meets the original threat model.

Categories: iPhone Tags:
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: