State of the Art in App Cracking

ARTeam, a group of hackers who – according to their homepage – specialize in reverse engineering released a 29 page report titled “Patching Applications from Apple AppStore with additional protection” that shows the state of the art on iPhone app cracking.

This report was released in partial secrecy on May 16th on the ARTeam download page. No blog article. No announcement. It was only stumbled upon by a German blogger who on condition on anonymity provided it to me after I asked nicely. The report even has a section about “licensing”.

All code included with this tutorial is free to use and modify; we only ask that you mention where you found it.

Ok, I told you where I got it. Now let’s see what goodies it unearths.

The report details exactly what measures developers can take and are taking to try and protect their apps from being cracked. And then it goes much further and gives detailed instructions on how the authors cracked several well-known apps:

• Full Screen Web Browser 1.1
• Robo 1.1.2
• Faces Visual Dialer 1.2.1
• mBox Mail 2.01
• Exzeus 1.3
• Convertbot 1.1
• Zen Bound 1.2.1

The examples are ordered in level of difficulty and show which week spots the crackers where able to exploit to crack the apps. You see several levels of complexity on checks on info.plist and the most “advanced” was named the one used in Zen Bound where a calculated hash on info.plist was hidden in a text file.

The report shows that given enough time a resourceful cracker can circumvent most of the checks that developers can think of. So these are the learnings that we can draw from it:

1. give the crackers much much more work to do. Cracking can be as easy as changing one byte with a hex editor or as difficult as having to patch in a hundred places at once.
2. don’t show that the app knows it’s cracked for as long as possible. If the cracker does not think it’s protected he will not bother to fire up the debugger and hex editor
3. if you show an alert asking the user to purchase the app, do that nowhere near your crack detection code. This leads the cracker directly to the piece of code that does the detection
4. Don’t use obvious methods of doing the “standard checks”. Like using literal strings or building these strings together from single characters.
5. Crack Protection only pays if you are smart about it. Done wrong it’s like not properly used antibiotics: it makes the Germs stronger!

So far tools like Crackulous only remove the encryption and user-specific data like for example the purchase receipt. But it’s only a matter of time that you will see some too obvious cecks being automatically patched.

The authors conclude in the final chapter of their work in a way that might give us small-time developers a glimmer of hope:
 

Apple has restricted the Developers so much that they don’t have many possibilities to check if an app is legally used or not. However even those simple checks may need some time to bypass if the developer invests some time in making them harder to find and to analyze. Without understanding completely how a check is performed it is often not possible to break the protection. 

So the golden equilibrium is reached if you make your apps just complicated enough to crack that the next version is out before the previous one got compromised. Unfortunately there is no sign that our big benefactor Apple will come to the rescue. They still seem to believe that jailbreak prevention is the only necessary method of hindering piracy. And making the third generation iPhone as hack-proof as possible. The jailbreaking battles over original iPhone and iPhone 3G have been all but conceded.

My personal conclusion is that I am glad I automated my protection scheme to an extent that it takes very little time to implement it. It takes just as little time to add more checks and mutate the code to make it more difficult on script kiddies. This saves me and all people who implemented AntiCrack a lot of valuable time that can go into improvements and more updates.

And that’s where our efforts really should be focussed.

Categories: Copy Protection