Solipsism Gradient

RB App Checker Lite 1.0.2 is out. Sorry for the delay; to compensate, there are some neat new features and a lot of infrastructure work has been done to prepare for the upcoming non-lite version.

…while Apple catches up with sent-in FAXes. Yes, you read that right.

In the meantime, RB App Checker Lite is momentarily off the Mac App Store. (It’s still normally available from the product page, of course.)

With very few interruptions, I’ve been a registered Apple Developer since mid-1984, when I bought the original loose-leaf edition of “Inside Macintosh”. From a reasonably early date onwards, I always paid by credit card. At some point – I think it was the late 1990’s – most developers were switched to paying over the iTunes store – quite practical in the US and Europe, since that was already tied to the Apple ID.

However, Brazil was very late in getting the iTunes store and from then on developers here had to send in an annual FAX stating their identification, credit card number, and so forth. A few years ago, the the iOS app store, the iTunes store, and the Mac app store (in that order, I think) became available and every time we heaved a collective sigh of relief, thinking that easy payment would be again possible.

Unfortunately, it’s now late 2012. All the stores are available but we still have to send in a FAX to Cupertino to renew our developer programs! No shipping Mac even has a built-in FAX-Modem anymore, which was what I used in the early years. Twice, I’ve asked developer relations at WWDC to send in the FAX for me – which they did, to their credit; and for the last few years I’ve asked their counterparts at Apple Brazil to do so, as they’re the only place I know of which still has a FAX machine stashed away somewhere. Still, the renewal was effected in a few days.

When I renewed my iOS membership a few months ago it took an unprecedented 7 days to be effected after sending the FAX, so when my Mac membership renewal came up, I thought it prudent to send in the FAX 20 days (!) before to ensure a timely response.

Unfortunately, the 20 days have come and gone, my renewal application still hasn’t been processed, and I’ve been cut off from the developer sites. Moreover, my app is no longer visible in the Mac App Store. I’ve already complained twice to Developer Relations and re-sent the FAX (both by machine and by email) 3 times; at first they admitted that it should have taken at least two weeks (!) to process, but haven’t replied since.

In the meantime, the new version of RB App Checker Lite had been in the review queue for 15 days and was finally rejected this week; first because of the pending renewal, second because of a temporary entitlement that had been accepted in the first version. I’m working on that. More soon (hopefully).

Update: just got email from Apple, stating that they put in a temporary extension while my renewal is being processed. The app isn’t back on the store yet, but at least it gives me breathing time to submit a new version; perhaps as soon as tomorrow.

Update #2: the app is back on the store. Stay tuned…

Update #3: my renewal has been processed, and we’re back to normal. Now working on the app again.

Recently someone figured out an attack against in-app purchasing on iOS. Only a few days later Apple, with commendable speed, put up a page detailing how to counter this crack by implementing better receipt checking.

Now there’s news that a similar attack also works on OS X. For this, users have to install two bogus certificates, point their DNS at the cracker’s server, and run an auxiliary application while making the in-app purchase; this builds an apparently valid receipt inside the application bundle. (Of course this means that the user is trusting those certificates, that server and that application to be otherwise innocuous – not a good policy! And it asks you for your admin password while you’re connected to that server, too…)

So how to implement better receipt checking on the Mac? The details are different, in that OS X in-app receipts are stored inside the application bundle, inside the application’s original receipt from the Mac App Store. Furthermore this receipt has a known format and is signed by 3 certificates:

• “Mac App Store Receipt Signing” (SHA1: 4A 7B 3A 17 00 A4 DA 4A D4 EA 43 3A 83 61 43 2E CF 1C A1 AF)
• “Apple Worldwide Developer Relations Certificate” (SHA1: 09 50 B6 CD 3D 2F 37 EA 24 6A 1A AA 20 DF AA DB D6 FE 1F 75)
• and the “Apple Root CA” (SHA1: 61 1E 5B 66 2C 59 3A 08 FF 58 D1 4A E2 24 52 D1 98 DF 6C 60)

the latter can be found, of course, inside every Mac user’s System Keychain. All this was easily obtained with my RB App Checker Lite utility (ahem). 🙂

Apple’s currently recommended receipt verification code, however, does not contain any recommendation to check the certificates used to sign the receipt; it does check if the receipt is for that particular application (otherwise people would just copy a receipt from another app) and if the receipt was generated on that particular computer (otherwise one could just copy the app from a friend’s computer).

No doubt Apple will now recommend to all OS X developers that their receipt verification codes also check the certificates – and in fact, that’s what my apps are already doing. The certificates are, after all, available from the same parsing process recommended in the above link. At the very least, I recommend obtaining the SHA1 fingerprints of all 3 certificates (openssl has a SHA1() function for that) and checking them against the list above. And once that’s done, obtaining the app’s own signing certificates, and checking them, is also advisable, even if the app is signed with a Developer ID.

I’m not giving specific code examples here, to avoid people copy&pasting it into their apps and offering a clear path to hacking the binary. The usual precautions to make binary hacking more difficult (though it’ll never be impossible) apply, of course.

If you’re using Quay, please check out the release notes and install this new version as soon as possible.

Note that older versions of Quay will break on Mountain Lion, giving you a persistent error message. Sorry about that, but the installation should be painless. Quay is now signed with my Developer ID for Gatekeeper compliance. And with RB App Checker Lite this is easy to verify. 😉

That said, I’m hard at work to get new stuff out in time for Mountain Lion (rumors say that will be sometime between July 19 and 31). Details are still fluid but I’ll post them here as soon as I get the basic functions working reliably.

My main concern is keeping my promise of upgrading paid users of Quay and XRay to the new stuff. This is unfortunately impossible with the Mac App Store, but not all utilities will be there, so i still think it’s going to work out.

Update: while this runs fine on 10.8 in my tests here, it may not behave well on the new Retina display (remember this was originally coded for 10.5!). I’ll try to do some tests tomorrow.

Update 2: OK, tests show it’s not Retina-compatible, so I’ve uploaded a new build with the “Open in Low Resolution” option checked. My apologies for the oversight. It’s not at all clear – looking at the source – how I could make it compatible both with high-resolution and 10.6.8 on short notice. And it’s still a 32-bit application, too.

Summing up: Quay is getting elderly and this update is, really, only for current users who like it. Don’t expect it to be updated again. But, as I said above, cool new stuff will soon be out. Suggestions welcome!

RB App Checker Lite 1.0.1 (187) has just gone live on the Mac App Store, and the corresponding Developer ID-signed build (186) is now available for direct download.

In the last month, almost exactly 1000 copies have been downloaded from the Mac App Store, and about 300 copies have been downloaded directly from my site. Not bad; the download curve shows the usual decaying exponential shape, but it is decaying much more slowly than I thought it would. And this with no marketing except for Twitter and a single press release.

Since both versions are free, I suppose that the main reason for users preferring the MAS version is the ease of updating; the direct-download version doesn’t have automatic updating, nor is it cost-effective to have it now. The popular Sparkle framework is over double the size of the entire application, and does much more than I need. When a non-MAS RB Utility comes out, it will have automatic updating, and that will automatically appear in all direct-download RB Utilities; a benefit of using a common app framework.

Update: here’s a common use scenario for RB App Checker Lite: an automatic updater starts and requests your administrator password. Is this safe? Easy to check:

• Command-click on the updater’s icon in the Dock; this will show the updater’s icon in the Finder;
• Right-click on this icon and select the “RB App Checker Lite ” service;
• RB App Checker Lite’s results should tell you if the updater can be trusted or not. Be especially wary of unsigned or self-signed updaters that ask for your admin password, unless you’re really sure!

…and you probably hadn’t realized I was away. Well, we spent 10 days away in Chile (more precisely, the Atacama Desert) and Bolivia (Salar de Uyuni). Here’s our updated world map (61 countries):

Briefly, it was tiring and cold but the landscapes were worth it.

Now back to the old drawing board; a bug-fix update to RB App Checker Lite should be out tomorrow, I hope. Stay tuned.

Yesterday evening RB App Checker Lite was approved for sale in the Mac App Store. Whew; it’s been a difficult couple of weeks, but it’s done. Now to relearn my php-fu and do a better product page, and of course restart work on other apps in the RB Utilities suite. Next in queue are “RB File Counter”, “RB File Alias” and the non-lite version of RB App Checker.

 

 

News on the RB App Checker Lite front. Version 1.0 (179) is out; check the product page for release notes.

The previously published version was 1.0 (171) – note I’m just incrementing the build number for now, this is mostly for keeping this version in sync with the one submitted to the Mac App Store.

Speaking of the MAS, my first submission was finally rejected for a bug with Services registration (after 7 days “Waiting for Review”, which is not too bad). So I’ll be resubmitting tonight, with that bug hopefully solved, and several new others fixed and new features added.

The most interesting new feature is checking for embedded provisioning profiles.  iOS apps will always have one, but you normally won’t see such a thing in a Mac application. However, both .xcarchives and apps “built for archiving” will have an embedded profile (unless you’re signing with your Developer ID).

Feedback welcome!

Update I: ehrm, make that version 1.0 (181). Only the icon has changed; Apple objected to my using the “generic application” icon as part of my own.

Update II: yes, the new icon is just a stopgap, will be redoing the details in the next build.