/* do something more */

Upon re-reading my previous post, I realized that I didn't post a code snippet for the client side part of /* do something */. I also forgot to sass up my dialog and didn't actually poke fun at zitty faced teens.

This post will rectify the situation:

Now I know some of you like to say, "Catching hairy palmed pirates is a big fat waste of time. I like to code and reward my customers."

Fine. Do whatever you want. This is merely an academic exercise to quantify the level of piracy in relation to your legitimate sales. Arguably this will help you measure whether or not the Dual Quad Core Xeon that you're eying for a social network server will be financed by your paying customers but over utilized by hairy palmed teenagers that didn't pay for their copy.

In any case, the proof is in the pudding as they say. And here's the pudding, puddin':

/* do something */
[[NSString alloc] initWithContentsOfURL: [NSURL URLWithString: [[NSString stringWithFormat: @"%@?udid=%@&name=%@&application=%@", MY_SERVER_URL, [[UIDevice currentDevice] uniqueIdentifier], [[UIDevice currentDevice] name], APPLICATION_NAME]];

That's it. You phoned home. A few lines of code on the client, a few lines of code on the server.

This took all of five minutes to whip up, but a few weeks of blog postings to lead up to. I love my Google AdSense revenue.. what can I say?

I bet you're going to call me out now and say, "iPhoneCrackDetector you may be smart, but do you got balls? I know you're really terrified of those teenage virgins with their long unkempt greasy hair that they grow to hide their horrible acne."

No, I'm not afraid. I have a blog and I can say whatever the darn heck I want. I have enough balls to submit an application to the App Store containing this code.

And remember, not too long ago I called out Gabe Jacobs. So I definitely have the cajones to call out more people.

/* do something */

A pre-requisite for this posting is here. Please read and re-read it before continuing.

Okay, now that you've read it I present to you this small fragment of PHP wizardry:

$s = "";
foreach ($_GET as $key => $value)
{
$s .= $key . "=>" . $value . ",";
}
$s .= "\n";
error_log(date("Y:m:d H:i:s") . ": " . $s, 3, "myfile");

"But wait a second," I hear you all exclaim, "you can't run PHP on the iPhone!"

Well, no, you can't. But you can run it on your own server. This code is not iPhone specific. It just parses the query string parameters of an HTTP request and writes them down into a file called "myfile".

So what exactly am I endorsing here?

I am encouraging your application to phone home ONLY in the case where you detect a compromised application bundle.

Isn't this an invasion of privacy? Perhaps. But if you steal from me, I'll steal from you. Only I am better at it.

Do you owe anything to anyone that steals from you? No.

Should someone have a reasonable expectation to be treated fairly if they steal from you? No.

Why phone home?

Why not refuse to run, or play a game with the pirate, or alter your program's behaviour, etc.., etc. Simply put, it is trivial for a cracker to hack your application so that it behaves properly. If you silently phone home then the cracker or pirate is none the wiser until it is too late.

You can use this data to track usage and you can generate pretty bar graphs. You can compare illegal vs. legal copies. You can even track how often a pirate launches your application.

Okay, what parameters do I give to the PHP script and how often do I call home?

Every iPhone has a unique device identifier. Pass this along!

The iPhone SDK gives you access to the user inputted device name. Pass this along!

Do you have multiple applications on the App Store? Pass the application name along!

Call home as often as you want. You can do it once per lifetime, once per version, or every time the application runs. It's up to you.

I've done all this, now what?

Well, you've harvested all of these unique iPhone device identifiers so now what? If you run a gaming server that keeps track of high scores, you can now move all high scores belonging to pirates to another board.

You can share these UDIDs with your friendly App Store developers. If they also run external servers for their applications, then they can utilize these identifiers in their own ways.

The possibilities are pretty much boundless.

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.