The Mac App Store... Security broken by design?

The Mac App Store opened yesterday and a few hours after the web is already full of news about the hacking/cracking/defeat/whatever of the store. When I heard about the Mac App Store, I became curious about how it would handle the serial and other protections of normal applications. I had read an article/news that talked about no more serials since the App Store would handle that – this is logical since you pay first to download the application, so the payment problem is solved. The big question was, how will Apple avoid people copying the applications from one computer to the other? And what extra-protections could developers implement since Apple has some restrictive rules in their App Store, as an example, it bans non-api and other tricks in iOS applications.

I just bought an iPad and had no much time yet to play with it (although it’s already jailbroken but not untethered since I arrived too late to the party and have no SHSH for 4.2b3 eheh). What I could see is that there’s no lack of cracked copies of App Store apps/games/etc. I had read some tutorials about cracking iOS apps, and from what I remember, the method was a memory dump (they are encrypted) and then apps required a little extra work. I think there is an application for iOS that does this work automatically or in a few easy steps – that could explain the large availability of apps. Is the same model to be applied to Mac App Store? Doesn’t seem so…

The first cracking method to appear was to replace the so called receipt file; you just needed to download one free app and then use its receipt in other paid applications that someone just copied from their computer (someone must buy the app first!). The first reports attributed this to a compliance failure with Apple guidelines regarding how to handle the receipts. Developers didn’t followed those guidelines and their implementation was short and weak (many dongle implementations in applications were broken due to this lazyness).

Anyway, this got me thinking about the whole “protection”. Some guys (here and here) were telling that developers should hardcode the receipt ID and so on, like that is going to solve something…
If the protection is only based on some checksumming against a certificate with no encryption whatsoever in the application (this wouldn’t matter most as iOS cracked apps show, but it would raise another barrier), then it’s just a matter of replacing that information and patch where appropriate. Luckily today, there were two different releases of Angry Birds, one of the apps that didn’t fully implemented Apple’s guidelines. One was an “independent” release and the other by Lz0 warez group. The independent release has the _MASReceipt folder while the Lz0 stripped it, and that’s why it’s interesting to diff the two releases. Diffing them, we have the following major differences:

  1. There are two bytes changed at the header. Need to research what is the impact of this.
  2. A byte patched: jz to jump.
  3. The receipt/signature/whatever inside the binary is patched/replaced, with a new certificate generated by Lz0.
  4. The Lz0 binary is a few bytes shorter, probably due to certificate changes.

Number 2 is interesting because it is patching the signature check.

0013DE4E E8 5B CA 00 00             call    __Z10verify_sigPKc ; verify_sig(char  const*)
0013DE53 85 C0                      test    eax, eax
0013DE55 74 0C                      jz      short loc_13DE63
0013DE57 C7 04 24 AD 00 00 00       mov     dword ptr [esp], 0ADh ; int
0013DE5E E8 35 B2 03 00             call    _exit

I’m not sure if this is standard (per API/guidelines) or developers implementation (not enough samples to judge it). Either way, it’s very weak since it can be easily tracked and without much effort – you would run the app from the command line, observe the exit and quickly try to breakpoint on exit().

Update: This isn’t standard but something from Angry Birds developers. It’s good to understand the verification process. Flight Control HD implements this in a different way but also linked against libcrypto (the “crack” crashes before reaching the verification process). I still have to do some more tests and see if the application can run by only patching this or if we really need to replace the certificate (Lz0 could be trying to mask the original download; the independent release has the Apple ID used splashed on it – some Russian email address heheh).

Now what I really want is to reverse and verify an app that fully complies with Apple’s guidelines. Can someone point me to such app and send a copy to me, or at least give me the name so I can buy it myself and do some tests? Flight Control HD was also released but I can see the receipt folder and no certificate embedded in the program.

I’m very curious about this one and my bet is that the whole security model is broken by design. This could also be on purpose and a bet that the App Store would reduce piracy levels – it’s easy to purchase and install apps, and the prices, generally, are lower. iOS developers appear to be happy with their revenue levels. I must admit that the iTunes store experience is very good and now I understand why the iPad and iPhone are such a success both for Apple and developers.

Another interesting thing is to see if the apps can run on 10.6.5 or lower. If you put them on 10.6.5, there’s a nice prohibited signed over the app icon and when you run a warning message appears. Hummmmmmmmmmmmm!!!

Time to research a little deeper on this! Feel free to add some more insight into this.
Oh, and also eager to see what that KickBack cracking applicaton is all about…

fG!

P.S.: Does anyone has access to official Apple security guidelines for Mac App Store? Requires access to the paid developers program.

P.S.2: Sample code for receipt validation available here.