Detection

If you've been following my thread of postings you'll remember that a cracked application needs the following to occur:

1. Someone buys your application
2. They decrypt your application binary
3. They redistribute it

Once the application is decrypted and cracked, the purchaser cannot ask Apple for a refund. This would eliminate the purchaser from receiving free upgrades that you painstakingly put together on a weekly basis.

In other words: once your application is compromised you can expect, right as rain, that any future release will also be compromised.

Enough With Yo Jibba Jabba.. Gimme the Code

Okay, as I mentioned before there are a few approaches to detecting a compromise at runtime. If you downloaded your cracked IPA from somewhere like RapidShare then you'll notice that the timestamps of Info.plist and your application binary are different.

Today, we'll look at Info.plist modifications. There are a few easy checks that you can perform at runtime to see if your Info.plist has been modified after you've built a distribution release:

1. Check the size of Info.plist. You know the size of the file after it's been built so hardcode a check into your application, rebuild for distribution, and push to the App Store.
2. Check if Info.plist is plaintext XML. The distribution copy is converted to a binary .plist and most IPA cracks convert this file back to either UTF-8 or ASCII. Again, do this check in your application before pushing it to the App Store.
   
3. Why the hell are they modifying Info.plist anyway? Well... the cracker added the key-pair {SignerIdentity, Apple iPhone OS Application Signing} to this file. Check for this modification at runtime -- it shouldn't be there!

The first two points are simple and are left as an exercise for you intrepid and enterprising App Store developers.

The third and last point is what I'll expand on below.

{SignerIdentity, Apple iPhone OS Application Signing}

Well what the hell is that doing in your Info.plist? It's not part of the XCode template and it's definitely not something that you put in there.

This key-value pair basically tells the application loader that the application is decrypted and can be trusted. Consider it to be a skeleton key that lets you run any application on the iPhone.

I'm not sure of the implementation details of the application loader so don't bother asking me.

The one thing for certain is that THIS KEY-VALUE PAIR SHOULD NOT BE IN ANY APP STORE APPLICATION. If you do find it during runtime then you know your application has been compromised.

Below is some rudimentary code that checks if this key-value pair is present in your application bundle's Info.plist.

NSBundle *bundle = [NSBundle mainBundle];
NSDictionary *info = [bundle infoDictionary];
if ([info objectForKey: @"SignerIdentity"] != nil)
{
/* do something */
}

Now you're going to say, how come you're not checking for the value of the key-value pair? Well, I say, you don't need to. If you didn't put that key-value pair into your Info.plist then you definitely didn't put that key in.

Well, you say, what do I do now?

So, I say, wait for my next posting on strategies that App Store developers can employ if they've detected that their application bundle has been compromised.