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 also 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 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.

P.S.3: I find it funny that the usual idiots at MSJ, including my “dear” one byte fag (sorry, can’t think of any other thing than idiots!), are bitching about possible spyware from the App Store identification (because of the scanning of Bundle ids to identify which apps are already installed or not). It’s funny because there are the same guys who love to use cracked software and couldn’t distinguish if they have any kind of rootkit/trojan installed on their systems due to that same cracked releases, even if that rootkit flashed a big sign telling them such thing. Excuse me the rant, but I cannot stand mental diahrrea like this. Act more, talk less! If Apple really wants to spy on your computer (in very stealthy ways), they can do it whenever they want – they control the kernel, do you remember? They wouldn’t need to reach Snow Leopard 10.6.6 to start doing it…
Anyway, it seems clear to me that all the burden of App Store protection is on the developers. Apple doesn’t care that much and developers are going the same way. From an economics point of view, this might be a good decision. People that pirated the apps will most probably continue to do it, those who buy/bought have an easier (and cheaper) way to continue to do it, and there is a great opportunity to increase sales as in iPhone/iPad cases. An investment in complicated protection/DRM schemes doesn’t seem justifiable for the kind of Apps to be distributed at Mac Apple Store.

12 thoughts on “The Mac App Store… Security broken by design?

  1. Question off-topic, sorry))
    Load in gdb our target, then make disassembly “main”

    0x00002710 : push %ebp
    0x00002711 : mov %esp,%ebp
    0x00002713 : sub $0x18,%esp
    0x00002716 : mov 0xc(%ebp),%eax
    0x00002719 : mov 0x8(%ebp),%ecx
    0x0000271c : movl $0x0,-0x4(%ebp)
    0x00002723 : mov %ecx,-0x8(%ebp)
    0x00002726 : mov %eax,-0xc(%ebp)
    0x00002729 : mov -0x8(%ebp),%eax
    0x0000272c : mov -0xc(%ebp),%ecx
    bla-bla-bla

    put the breakpoint at 0x00002710, everything good, breakpoint works, but then i need to find out where in binary file this is point 0x00002710. How in hex editor do it this (to patch).

    1. You need to find the correct offset – either use IDA, some other tool (there is a post with some tool I created for that) or manually calculate it. If it’s a i386 only binary you can (usually) get away by adding 0x1000 to each address.

  2. What document do you need from the paid developers program? I can help.
    Is it “Validating App Store Receipts”? I can email it to you.

  3. the prohibited warning sign on it comes from info.plist, im not sure exactly what the key was called but it was the minimum version, if you change it to 10.6.3 (what i tested it on) it still won’t work but its possible that its just because of validation elsewhere

  4. Flight Control HD does implement the receipt checking properly, I just removed the receipt in the cracked version for funsies. Other apps that do it correctly are Warranty Hero 2, Chopper 2 and the new version of Angry Birds. There are actually some PAID apps that don’t even check to see if the receipt exists, like MiStat and Apptivate. Cheers.

    1. Yeah, there isn’t much to be seen here. Already saw some apps that copied that sample code, with an exit() just after the DRM check…
      It’s a broken/poor design, without anything special.
      Thanks for the tip on those Apps 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *