Solipsism Gradient

Back, Busy

Time flies. Our 4-week trip to the US Southwest’s parks has been over for almost 2 weeks already. The trip itself was marvelous; one of the best in recent years, even though we had to skip a few parks – it was just too tiring. At least we now have a shorter list of places to revisit in the future. We then rested for a week in Denver and nearby Boulder, which are wonderful places, too. All in all we drove about 5000km (3000 miles). Here’s my updated map of visited US states:

RB App Checker Lite 1.0.2

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.

Please stand by…

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

Checking receipts on OS X

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.

Quay 1.1.4 for Mountain Lion

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!

One month later

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!

1. Page 1 of 47
2. 1
3. 2
4. 3
5. ...
6. 47
7. Next Page