Copy Protection – Cocoanetics https://www.cocoanetics.com Our DNA is written in Swift Fri, 31 Aug 2012 06:16:07 +0000 en-US hourly 1 https://wordpress.org/?v=6.4.3 39982308 Telling a Tale … Where Download-Code Sucks https://www.cocoanetics.com/2012/08/telling-a-tale-where-download-code-sucks/ https://www.cocoanetics.com/2012/08/telling-a-tale-where-download-code-sucks/#comments Thu, 30 Aug 2012 21:58:58 +0000 http://www.cocoanetics.com/?p=6948 I’ll be the first to admit that I love what Telltale Games have done to the long ago diseased adventure game genre. I played the Monkey Island Games via Steam, got Wallace & Grommit even though I don’t even possess a PC (unfortunately not available for Mac) and I loved the first episode of “The Walking Dead” on my iPad.

A mere 14 hours ago Telltale released the second episode for iOS but it turns out that their episode downloading code is utter crap. Much to my frustration because I am trying to get this episode for playing for around 10 hours now. It is quarter to 11 pm and I have reached a point where I need to vent my chagrin in a blog post.

If only to tell a tale how NOT to construct code that downloads many hundreds of megabytes.

The big annoying problem with episode download can be summed up in this message:

This message is a symptom of so many bad ideas.

Of course I understand that graphically rich games like The Walking Dead require hundreds of MB of data. It is the job of the developers to make sure that the download experience is the least possible annoyance to the user. The current version of the download code does a bad job at this.

On entering the episodes screen iTunes is pinged for a list of available In-App purchases. The ones that are configured are then displayed as visible for download. Of course I had bought the “season pass” because episode one had done a great job hooking me on the new series. Sadly the first letdown of the game was that I only learned that a new episode was available by googling it. Haven’t they heard about push notifications?!

They had to get a unique app id provisioning profile anyway for enabling the IAPs, why not also enable push? Everybody who springs for the whole season has a right to learn at the earliest possible moment that new content is available for download.

The game itself is a whopping 329 MB, one would assume that this is about the size of an episode. Though even this is not certain because I remember having to wait exceptionally long when I launched the game the first time. It could also have been the case that they downloaded even more content during this time. Or maybe they uncompressed it, we’ll never know. So “hundreds of MB” is the best guess we have.

I peeked into the network traffic and found to my surprise that there were only two HTTP GET requests to the Telltale home page, but no trace of any other communication. Google does the same with their Ad network. You don’t see anything with Charles Debugging Proxy, but packets galore on other network snooping apps.

One can only assume that this is because they are afraid of somebody stealing the content. Certainly if you could simply get the content at a normal HTTP URL with a regular GET command it would take no time at all for crackers to download and re-package these coveted episodes and put then online illegally.

But what disturbs me that Telltale saw it necessary to add this level of copy protection instead of going for a good user experience first. The downloading doesn’t even do background completion for crying out loud! If you leave the app (e.g. home button) and return there was no progress made at all. A better mechanism would let me do something else with my iPad and then inform me via local push notification that the download has completed.

Oh, but I keep forgetting, background task completion only works if the process can finish in under 10 minutes. There might have been a workaround to ask the user to return before this time is up to get another 10 minutes of background downloading. Oh well, that might not really be a simple option after all.

BUT – BIG BUT – why in God’s name didn’t they implement download resuming? That is so easy to do, just look at my DTDownload class in my open source DTFoundation project. Oh, here the custom downloading functions again prevent this: you need to be using HTTP or HTTPS to benefit from range downloads via NSURLConnection.

They couldn’t have used NSURLConnection for the simple reason that if you use that then your traffic will have to pass through the system HTTP proxy if set. And then I would see it in Charles. So they are using something at a lower level that is not forced to go through the proxy. That brings with it another potential problem: HTTP (using TCP, as opposed to UDP) guarantees completeness of data. Missing packets are automatically and transparently re-transmitted. By not using HTTP and TCP they would have had to implement their own scheme to deal with lost data packets.

By this time I am beginning to feel sorry for the guys at Telltale who where tasked with this download mechanism. This all reeks as being dictated from above. No sane iOS developer would program the network stack like this, totally avoiding all the good and reliable things that Apple provides.

The process for download resuming is relatively simple: you download as much as you can and append the downloaded bytes to a file on disk. For resuming you then tell your server to continue with the next byte until the end of the file. Ideally you’d transfer it in a single ZIP file – to avoid unnecessary gaps and handshakes – and then you’ll unpack file on the client.

The next faux pas stems from the developers obviously never having tested their download code in “connectivity-challenged circumstances”. There are occasions where the download was so slow so that the iPad went into standby half way through. Of course you would then get the above mentioned error screen on relaunching the app. Back to square 1. $%§&§%!!

The final straw was one situation where the app insisted that my internet connection was offline even though I was able to surf with Safari. There is a known bug in Reachability where coming back from standby would still have the app believe it was offline. The workaround in this case is to stop the notifier when going into the background and to resume the notifier as soon as the app comes to the foreground again.

I cannot readily prove it, but I get the feeling that Telltale is not hosting their content on a CDN like Apple does (Akamai). But instead those hundreds of megabytes are coming across the big pond to Europe where I am located. This exacerbates the problem because I found that bandwidth suffers after around 8 pm when everybody is downloading stuff from America. One example is that until 7 pm or thereabouts I can rent a movie from iTunes USA and watch it while its downloading. That usually becomes impossible after 8pm.

I would bet they instead went for Amazon’s servers. Amazon is great for the US, but sucks for everywhere else because they lack local mirrors.

Conclusion

So let us summarize all their faux-pas:

  • no background task completion
  • no download resuming after an interruption
  • allowing the iPad to go into standby while the download is not complete
  • not testing for bandwidth-constrained scenarios
  • not testing for abort conditions that would leave the app stuck unable to proceed without being killed (aka Reachability bug)
  • not hosting on a Content Delivery Network (like Akamai)
  • their fear of piracy dictated what they could technically do
  • not using NSURLConnection and tried and true HTTP

Let this be a lesson for everybody who also faces the necessity of large DLC packages.

If it is at all feasible I would continue downloading in the background and inform the user when necessary about completed or interrupted download. Allowing downloads to resume is even more important as to not frustrate users, especially if low bandwidth caused them to wait excessively long already.

Imagine downloading like 95% of an episode and then getting the dreaded error. Just one example:

 

C’mon Telltale, you CAN do better. Please implement download resuming before shipping episode 3. Strangely enough while I was writing these lines the app finally finished the download, it must have been about the 10th or so attempt. So I’m now off playing this otherwise awesome game!

]]>
https://www.cocoanetics.com/2012/08/telling-a-tale-where-download-code-sucks/feed/ 3 6948
State of the Art in Cracking Apps https://www.cocoanetics.com/2009/11/state-of-the-art-in-cracking-apps/ https://www.cocoanetics.com/2009/11/state-of-the-art-in-cracking-apps/#comments Sun, 01 Nov 2009 18:59:11 +0000 http://www.drobnik.com/touch/?p=1423 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).

]]>
https://www.cocoanetics.com/2009/11/state-of-the-art-in-cracking-apps/feed/ 1 1423
AntiCrack 2.0 https://www.cocoanetics.com/2009/08/anticrack-2-0/ https://www.cocoanetics.com/2009/08/anticrack-2-0/#respond Sat, 22 Aug 2009 16:18:41 +0000 http://www.drobnik.com/touch/?p=1245 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.

]]>
https://www.cocoanetics.com/2009/08/anticrack-2-0/feed/ 0 1245
Piracy Data Update https://www.cocoanetics.com/2009/06/piracy-data-update/ https://www.cocoanetics.com/2009/06/piracy-data-update/#respond Sun, 28 Jun 2009 07:36:21 +0000 http://www.drobnik.com/touch/?p=1069 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?

Pirated versus PurchasedSpeaking 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.

]]>
https://www.cocoanetics.com/2009/06/piracy-data-update/feed/ 0 1069
State of the Art in App Cracking https://www.cocoanetics.com/2009/05/state-of-the-art-in-app-cracking/ https://www.cocoanetics.com/2009/05/state-of-the-art-in-app-cracking/#respond Tue, 26 May 2009 20:35:55 +0000 http://www.drobnik.com/touch/?p=922 ARTeam ReportARTeam, 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.

]]>
https://www.cocoanetics.com/2009/05/state-of-the-art-in-app-cracking/feed/ 0 922