With the number of apps on the app store soon reaching the big 100.000 it is only logical that piracy continues to flourish. At the beginning of this year a tool named Crackulous promised to make it easy for everyone to become a pirate, claiming to be the solution to a flawed app store. At the time of this writing Crackulous version 0.9 is public and the next version 1.0 is being “in development” for more than half a year.

Piracy is a thorn in the side of all small time iPhone developers who can hope to make around $10 per app per day. Those hard working coders now face the likelyhood of  loosing half of their revenue to pirates making it continuously easier to get the apps for free. According to latest numbers of Pinch app to 60% of apps in use are in fact cracked copies.

There are several things that you can do being such a developer who sees a at least a portion of his potential income being stolen.

• cease to protect and consider pirated apps as additional advertisements
• pay hundreds of dollars to a professional protection service
• do some research and collect together methods to detect cracks and modify your app’s behavior if you find it is cracked
• join the AntiCrack community to gain access to our repository and put this into your apps, mix and match, use what you like
• or the fatalistic option is too cease making iPhone apps alltogether

I encourage everyone to do a bit of his own research to understand the techniques that are out there and maybe develop a couple of your own. But for everybody who still wants to try to do at least something we made AntiCrack.

To be able to claim successful cracking of an app these things need to occur:

1. The encryption that Apple applies to the binary during Review needs to be removed
2. The cracker needs to disassemble the binary and manually disable or circumvent all detection and countermeasures
3. The cracker needs to test the app to be certain that there are no time-delayed traps
4. The hacked binary needs to be repackaged and distributed

Crackulous 1.0 is rumored to be signing the app with a self-signed certificate. This will make most of the current generation checks which rely on looking for modifications of info.plist obsolete. The current version 0.9 of Crackulous is unable to auto-dump the decrypted binary, instead you get a message that the dump file does not exist.

This knowledge is the reason why we were claiming to “completely eliminate the risk” of being cracked. Admittedly this was marketing lingo, the truth would be found in the small print to say that AntiCrack 2.0 is able to prevent Crackulous 0.9 from decrypting apps. There was a blog post on freakbits.com flaming me for the original statement. The author of the post enigmax and a couple of other people with fancy nicknames (hiding their identity) found that I was making a overly bold statement that held no truth. Hm, truth in advertising …

Seasoned Russian cracker crash-x offered to demonstrate that he is able to manually disable all checks I put into an app of mine. Being a good sport I provided a promo code and let him play with it. He spent around one hour in total to dump and hack around on the app. But when it came to prove that he actually achieved what he claimed, he refused to write up what he did or how he did it. If this was out of generosity for the people who use the current generation AntiCrack or if this gives him some rise can only be speculated. For all I know he found only the obvious checks. We will never know.

Our Ruski pal proved something that we already knew: if you are well versed in ARM-Assembler you can probably disable most of the anti-piracy checks in less than an hour. It appears you still need to manually dump the binary from memory. And it also appears that if there are enough checks in the app even an experienced hacker will miss a couple.

Where does this leave the promise of AntiCrack? Mostly intact I should say.

I amended my overly precocious statement on the marketing page and until proven otherwise AntiCrack continues to provide an easy to add protection layer against auto-cracking by wanna-be hackers. AntiCrack 2.0 already contains a mild degree of polymorphism. We are waiting to see how Crackulous 1.0 will deal with it once it finally becomes public. Then we have a couple of additional tricks up our sleeve to make a binary into a true polymorphous mine-field for manual hackers.

The point of AntiCrack is not to make something difficult. It’s to make something so easy that you can put it into dozens of places in your app at the same time. Each additional place (in different form) doubles the time a hacker has to spend on the code to find it. The point of any such exercise is to give the cracker the feeling that he has succeeded in disabling all detections while still keeping the upper hand over copies that where distributed subsequently. I call this concept “Silent Lite”. Let the unsuspecting user of a cracked app test the app for some time and then suddenly do something drastic when the forced trial has expired.

For the time being we can see from our statistics that crackers fail to do the necessary long term testing and if you hide our traps in enough places they can never find them all. Also it’s up to you to vary the protection code for each update for your apps so that a hacker who has set his sights on your app has to start from the beginning every couple of weeks.

Apple seems to follow only two approaches regarding piracy:

1. They aim to make it incrementally harder to jailbreak iPhones hoping to finally reach a point where modern hardware is safe from being exploited. Unfortunately for us developer they constantly get proven to be incapable of doing that. I am astonished by the number of exploits that get discovered and made into jailbreaks.
2. By allowing free app to up-sell content via in-app-purchases they hope to take away one of the reasons for getting pirated copies. So far the reception has been lukewarm but from what I hear many developers are now scrambling to replace their Lite versions with such Free-To-Paid-Upsellers.

The second thing might have been prompted by piracy being so incredibly widespread. For the longed time apple refused to accept Demo versions as well as only permitted in-app-purchases in paid apps. Though it remains to be seen what kind of effect this will have. For one not every kind of app lends itself to such an upsell path. A simple utility app that would go for $1 (like Summertime) is not something that you upsell easily. What works for additional levels and content does not work for a small fixed function app.

Most of the money in apps is made in the long tail, unless you get hyped by one of the major review blogs or can paid your way there. And that’s also where piracy can really impact your funds in the long run. I am fearing that some day I or any iPhone developer I know will need to fold his activities due to no longer getting this long tail of a couple of dollars per day. If you are raking in boatloads of cash you don’t feel the pain as much as when you make like $10 – $30 per day.

Philosophically I cannot imagine a good reason why able and smart young people would rather spend their time on costing somebody else money as opposed to partnering together and creating apps that put those very apps in the shade that they would have cracked otherwise. Is it lack of creativity? Lack of a will to create? Is the fame of putting your monicker on a cracked app sweeter than the money that might buy your next Mac?

I tip my hat to those cracks who can read assembler like Neo can read the matrix. You can do something I cannot. I can only create it and I have a bit of an idea on how I could make a living off it. I continue to have an open ear for any smart guy looking to get his foot in the market. Stop whining about bad software (and cracking it). Help make good software (that is worth the cost).

I am extremely pleased to announce a major new release of AntiCrack. While the implementation details have changed very little our new lead developer Fabian Kreiser has rewritten AntiCrack from ground up to obfuscate it to the extreme. Also he researched and developed two additional technologies which should immediately make your mouth water:

• Denial of Debuggers. This makes it impossible for Crackulous to remove encryption.
• Checking of binary encryption. The encrypted envelope put on by Apple in the review process is now checked for integrity.

Previously existing AntiCrack 1.x users are getting the update for free, for everybody else the minimum donation has been increased to 30 Euros. I switched from Dollars to Euros because the increasing weakness of the Dollar started to get on my nerves.

1.x versions of AntiCrack did not really prevent cracking of apps but provided a comprehensive and easy to implement toolset allowing users to dynamically adapt their app’s featureset to “Lite” once a crack was detected. The groundbreaking 2.0 release also prevents cracking in the first place. This again makes it on par with the professional Kaliap copy protection service offered by Ripdev.

Personally I believe it’s now even superior because you get full source code for AntiCrack, don’t have to pay recurring charges and you don’t have to register all new apps and app versions with an online service. I’ve updated the AntiCrack product description page if you would like to read more.

In the pro versus contra copy protection debate there are some arguments against the other side’s viewpoint. Arguments that can be proven or disproven if you have some real life data available. Is there a need for piracy detection? Is this a cat and mouse game that single developers can never win?

Speaking for LuckyWheel installation base I have the following statistics available:

2052  (55%) purchased regular LuckyWheel

1661 (45%) pirated the game

3713 total (100%) LuckyWheel installations

66646 downloaded the Lite version

LuckyWheel Lite, limited to ten questions per language, is a great way to try out LuckyWheel for free. One argument I’ve heard a lot is that people will use a cracked copy to evaluate your app and if they like it very much will spend the dollar or two that it usually costs. But is this really the case?

Not according to my data. The conversion rates are dramatically different between Lite-to-Full versus Cracked-to-Full. Actually it’s a tenth.

• 1.3% (862 ) upgraded from Lite to Full
• 0.1% (69) degraded from Lite to Pirated
• 0.18% (3) upgraded from Pirated to Full

Most likely iPhone users who go through the motions of downloading and installing a cracked IPA are not a fair sampling of the general iPhone user base. Or do we really believe that 45% of iPhones are jailbroken? Jailbreaking and patching the mobile installer app are the prerequisites to install decrypted pirated apps on iPhones.

Another thing also tells us that the pirating users cannot be representative of the whole. They are either 10 times as cheap or 10 times as hard to please are are regular people.

To look on the bright side, of the more than 70359 total pairs of eyes that have tried out LuckyWheel in one form or another only 2.4% thought to be so smart to get the full version for free. Because really you have to see pirated copies as Lite versions. 2.4% pirates amongst iPhone users sounds like a realistic number.

The numbers prove that purveyors of piracy are even less inclined of eventually purchase the app than Lite tryers (factor 10). Some developers claim to have a loss in sales while I still have not seen any convincing evidence of that. Piracy is just a little bit of additional advertisement. Actually I’ve never seen sales drop after LuckyWheel became available in “decrypted form”. But that may be just me and my $1-Game.

Maybe the story is totally different for higher priced apps with coveted content. I invite any colleagues to share their numbers to that effect with me. Generally I consider real losses to be more present if the pricing level is above a certain threshold. I’ll quickly spend a couple of dollars on an app here and there, but if the app costs more than $10 I might pause and think if it really is worth as much to me.

Now you might say that this is a good case against products like my AntiCrack and I have to agree. But if there are additional resources you have to pay for to provide the app’s features then it might really hurt financially having to treat crackers the same as customers. Say you have set up a dedicated server to provide online multiplayer gaming you probably have to limit it’s usage to only legitimate customers. Or a different scenario might be one where you have to give person-to-person support and for ethical or technical reasons you have to refrain from cloning yourself.

AntiCrack does not prevent cracking per se which is the removal of Apple’s encryption wrapper around a distributed app. But what it can do for my fellow developers is to give a toolset to make an educated decision if you want or need to treat pirates different than paying customers. Without AntiCrack you don’t even know who is legitimate and who is not.

Actually it has been a trend even in PC games to mess with the user’s feelings if a crack is detected. Most modern PC games have only a simple medium based protection like SecuRom on the surface which can easily be removed by any second grade cracker. But then there lots of “bugs” throughout the app that might prevent using of the “Reload” button or make the app crash when displaying a star chart after the first long level. Also these pseudo-bugs would not behave the same, sometimes they would be present, the next time the game is run it suddenly works again. This way  the crackers can never be certain that the crackers have patched out all those kinks.

So, does AntiCrack have a place in developers hearts? Definitely yes. It gives you information to act on if you need to conserve your resources and gives you some vindication over freeloaders. Best of all, it’s cheap and easy to implement, so you can conserve the contents of your wallet and save lots of implementation time.

This enables you to concentrate on putting more quality into your apps and app updates which will increase your profits down the road the most.

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.