Solipsism Gradient

As you may have seen elsewhere, Apple has just approved publication of RB App Checker Lite 1.1.3 (build 320) on the Mac App Store, and I’ve simultaneously published the Developer ID version (build 321) and updated the product page.

While the main focus of this version is to do some additional checks, fix bugs and display some information that users have requested, the XcodeGhost story broke just after I uploaded the first binary for review, and I had to remove it in order to see what RB App Checker Lite could do to detect this breach of security.

Assuming you’ve read the excellent summaries linked to in the previous paragraph, you may be interested in what I found inside the “ghosted” version of Xcode. Briefly, the hack alters the script Xcode uses to link an app’s binary; it also inserts look-alike versions of the CoreServices framework into the iOS, iPhone Simulator and OS X SDKs inside Xcode.

All this of course breaks Xcode’s code signature and, under normal circumstances, running such a hacked version would — after the customary delay for checking, 2 to 5 minutes — be detected by GateKeeper and it would advise the developer that “‘Xcode.app’ will damage your computer. You should move it to the Trash.” And the previous version of RB App Checker Lite would advise that “…requirements and resources didn’t pass static validation” and point at the changed file.

You’d think that that would take care of the matter, but it turns out that the affected developers turned GateKeeper off entirely, no doubt to get rid of the several minutes delay. After that, versions of their apps uploaded to the App Store would have been linked with a static library containing categories on Cocoa classes such as UIApplication, UIWindow and so forth; this static library having been hidden inside the added frameworks.

Needless to say, the new version of RB App Checker Lite also detects the added frameworks and warns: “3 frameworks are suspect: they use system names but are NOT signed by Apple!”.

This is both good and bad news. The good news is that this specific version of XcodeGhost — or any similar hack that hides code inside bogus frameworks looking like Apple’s frameworks — can be detected. The bad news is that this specific tactic depends on passing a casual visual inspection of the SDKs inside Xcode; in other words, the names and file paths used look reasonable and mostly duplicate Apple’s names and conventions.

This works because Xcode is a huge application; it contains nearly 5 thousand auxiliary executables. The latest Xcode beta has several SDKs for each of the 7 platforms it supports, and each SDK has an included instance of all system frameworks, both public and private, for that particular combination. Unfortunately, not all these frameworks are currently signed by Apple — only 2/3 of them are, and not in a consistent manner. (In all fairness, the percentage has been creeping up a little with each release.)

Therefore, unless you check the entire app contents with GateKeeper, RB App Checker Lite (or even the codesign command-line utility), it will be humanly impossible to pick out visually — by inspection in the Finder — if anything has been changed inside Xcode. So keep GateKeeper turned on! One suggestion Apple should implement is running GateKeeper tests for Apple-signed software even if GateKeeper has been deliberately disabled.

So, what to do about “infected” apps? Unfortunately the news is not good there. (By the way, I’m surprised that no infected apps were — as yet — found on the Mac App Store.) As I said, infected apps contain linked-in categories on Cocoa classes, using plausible English method names. Writing such categories is perfectly legal and even plausible — I’ve done so myself. Having code inside these categories do things that are allowed by the app’s entitlements, such as sending/receiving data over the net, is also perfectly legal and plausible. There seem to be some utilities out already that purport detecting such code, but I suppose they’d turn up a lot of false positives unless they check for these specific combinations of symbols — not very future-proof.

By the same token, Apple can’t really do these tests comprehensively when an app is uploaded to the store. They can and do check for private or “suspect” APIs being called, but as far as I can see the present XcodeGhost doesn’t use anything like that.

Coming back to RB App Checker Lite: it currently does NOT look inside executable code at all. Should it do so? I’m reluctant to implement that; it’s not clear what exactly to look for, regarding hacks like XcodeGhost, and it would mean that checking Xcode and similar huge apps would take tens of minutes or even more. I’m open to suggestions, however… comment here or email me!

If you’re a Quay user, there’s good and bad news.

The good news is, I finally had time to test it on OS X 10.11 (El Capitan) — not the final version, but the GM developer release — and it still works!

The bad news is, it works by coincidence and not fully. While I still use it myself on 10.10 (Yosemite), I don’t use all of its functions and it turns out that dragging a Finder saved search icon into the Dock stopped working some time in the past; they probably updated the format either in 10.10 or 10.9.

In 10.11 there are new security restrictions on 3rd-party applications getting information like memory and CPU usage of other processes; therefore, Quay’s popup for running applications will show only the application version.

Unfortunately, Quay is a 32-bit application that depends on now-obsolete Carbon APIs to do its magic, and these things are all going away. I can no longer compile it on current versions of Xcode, and OS X will Real Soon Now™ be 64-bit only.

My products page has been revised to show Quay as “legacy” software and I can no longer support it on newer systems or even promise that it will work at all on these. If you are a registered user, my apologies.

In other news, we were away for an extended trip to Eastern Europe and Asia. Here’s our updated world map:

I also found time to work on RB App Checker Lite and a new version (1.1.3) is currently waiting for review on the App Store. Hopefully it will be out early in the week. More about this soon.

Tomorrow (we suppose) the Apple Watch will be out. For months, there’s been lots of interesting documentation on Apple’s site — but it’s all about WatchKit, the framework used on the iPhone side to run “Watch” apps. Almost nothing about the Watch itself. I think most of my previous speculations were confirmed: specifically, the part about the Watch mostly being a remote display for the iPhone:

Perhaps… just a sequence of drawing orders? The important part is that there’ll be a single process on the Watch for doing the UI, and all the application-specific parts can be offloaded to the iPhone.

So, for now, the application logic will all be on the iPhone side — where the actual WatchKit part runs — and “assets”, meaning storyboards, xib files, and PNGs with pre-rendered icons, buttons and so forth, are downloaded to the Watch and displayed as needed. My back-of-the-napkins calculations about battery life (around 15 hours) still seem valid: Tim Cook said that you’d have to charge the Watch every night. I also said:

Watch OS … will not be a stripped-down iOS; maybe even not a Darwin derivative. It will be a highly optimized embedded system that runs as few processes as possible. It will be very robust because it will be able to do only a fixed set of functions.

Of course, this clashes with everybody else’s assumption that of course the Watch will be running iOS. Apple continues to be very careful about this: the OS that actually runs on the Watch is named nowhere that I could find. Likewise no hardware specs beyond the two screen’s pixel sizes were revealed. Details about the OS may not be revealed until next year, when developer apps supposedly may run on the device itself. It might make make sense for Apple to repurpose, say, the OS running on the smaller no-app iPods.

Beyond speculations about functionality, rumors have concentrated on price and updatability. I’m not competent to speculate about prices, but John Gruber’s final thoughts on the issue seem very reasonable.

Opinions are split on updatability, since few of Apple’s products can be upgraded, and none can have their hardware updated to a next generation. Then again, here’s a completely new type of product, smaller and (in some versions) more expensive than any other; it’s also, perhaps, the most personal Apple product ever. If you get an expensive Watch, say, as a graduation present — with an engraving, perhaps — you’ll be very reluctant to dispose of it and get a new one in a few years, even if the new version does much more.

At absolute minimum, the battery will have to be replaceable, and in my opinion, the entire Watch module (probably including the battery, probably excluding the display) will be upgradeable for a fee once a better version comes out — maybe not forever, but for at least 2 or 3 generations. We’ll see.

Good news: we’re back. Here’s my updated world map:

Bad news: my plans to work underway were largely derailed, and I had to wait an additional couple of weeks for my new iMac to arrive. Still, everything is finally installed and working now, and an update to RB App Checker Lite should be out in a day or two.

I fixed a crash that happened on some (apparently very few) systems and the new version is 1.1.1 — build 288 for the Mac App Store version, and build 289 for the direct download version. As a bonus, the app should also start up a little faster.

In fact, the MAS version has been out since the day before yesterday, but we’re on the road (currently in Germany) and Internet connections have been a little irregular.

On the downside, in the next 4 weeks my connections will be even more uncertain — we’ll be in Sikkim, Bhutan, Nepal, Italy and in the Eastern Aegean, so further updates or postings will probably have to wait until I’m back home. On the upside, I’m taking my laptop and will try to work in my copious free time while underway… 🙂

Apple’s (pre-)announcement of the Apple Watch left the tech world in the usual disarray. Is it an expensive knock-off of Android watches (people tell me there is such a thing!)? Is it an attack on the high-end Swiss watch market? Is it an attack on the low-end Japanese watch market? Is it an even more transparent lock-in attempt on soi-disant “Apple fanbois”? I’d answer “no” to all those questions, but right now I’m more interested in the hardware and software technology of the watch.

Notice that the above link doesn’t mention iOS anywhere, but this other link has the magic word: WatchKit. Quote: “WatchKit Apps. Soon your favorite apps will feature controls and interactions unique to Apple Watch, enabling you to enjoy them in dynamic new ways.”

Speculations about WatchKit since then usually have mentioned one or two assumptions:

1. WatchKit will be written in/accessible only from Swift;
2. WatchKit apps will run under iOS on the Apple Watch.

The first is, of course, wishful thinking from developers investing in the new Swift language. The second is, in my opinion, completely unwarranted and I’ll try to explain why.

This post is the most plausible so far: “WatchKit apps will ship as embedded binaries in iPhone apps, using the same basic principals [sic] as iOS 8 extensions. There will be some mechanism for the watch paired to an iPhone to detect and automatically install these ‘apps’ based on what is available on the paired iPhone. Delete the container app from the iPhone, it disappears from the watch. Xcode will have a template to add a WatchKit app to an iPhone app project.”

Let’s back off WatchKit for a second and look at what we’ve seen of the hardware. The entire main board is shrunk down to a single unit: the S1. If you stop the middle introduction film at 4:46, you’ll see that it’s really a collection of chips and SMT components on an encapsulated multilayer board — not really a “single chip” as the narration says, but many large CPU “chips” nowadays are like that, too. Other than the S1, there’s of course the “Taptic Engine” assembly which does the wrist tapping, the crown sensor assembly, antennas and display, and the most important part: the battery.

Battery life is the make-or-break feature of the Apple Watch. iFixit’s disassembly of the Moto 360 watch shows why: there’s a square peg battery inside a round casing, rated at 320 mAh. Even though Motorola apparently build their own batteries, they don’t have enough volume to do a round one. Apple doesn’t have a volume problem and their casing is square, so they’re free to use all remaining volume for a longer-lasting battery.

The 320 mAh rating and the typical battery life of 12 hours of the Moto 360 means that the watch consumes, on the average, just under 27 mA. But they run Android on the watch, using an off-the-shelf TI ARM processor with attached RAM, flash memory, and so forth, so that figure is not surprising. In other words, it’s a stripped-down cellphone/MP3 player.

Suppose that Apple did its usual optimization of battery size, usage, etc., in a stripped-down iPod nano. It’s half the size of the nano, which has a 30-hour life, so we can assume half the battery, meaning 15 hours. OK, that would be marginally acceptable, perhaps.

But remember, the Apple Watch needs an iPhone nearby. In fact, many of the published functions, such as Siri, cellphone call response, GPS and so forth certainly use the iPhone’s hardware and software for that. Remember that one of the culprits of excessive battery usage is generic apps and processes running on the device. Remember that Apple, since the first iPod in 2001, has been very aggressive in optimizing their embedded systems. Remember that the first iPods and iPhones didn’t have any generic apps running on them, either. Remember that Apple already has technologies like Clang, OpenCL and Metal…

All that said, why run iOS and generic applications on the Watch at all? So here’s what I think likely about the real implementation.

• Watch OS (or whatever it’s called — did they explicitly call it anything?) will not be a stripped-down iOS; maybe even not a Darwin derivative. It will be a highly optimized embedded system that has a few apps running in as few processes as possible. It will be very robust because it will be able to do only a fixed set of functions.
• In other words, it will run only those things that may run while the paired iPhone is not available; we don’t know yet, but that might be just the timekeeping and pulse measuring apps. If the iPhone is there, the Watch will also work as a specialized I/O and display device for the apps installed there.
• WatchKit will run on the paired iPhone inside a special server process; a matching iOS app will show installed Watch apps — probably those apps will be from the normal App Store, since they usually will have an iOS counterpart.
• So, an installed Watch app will have at least some sort of preference app or pane on the iPhone; no use typing in passwords and such on the Watch, right? The part written in/for WatchKit will contain a server plugin that does the heavy lifting, data collating and communicating with the outside world, but it will also contain the application logic itself, commanding the Watch to do or display certain things.
• I don’t mean to imply that the Watch will run a full WebKit client and the iPhone a web server, that might be overkill. Perhaps a useful subset of that, perhaps some variation of Display Postscript, some interpreted command language, or just a sequence of drawing orders? The important part is that there’ll be a single process on the Watch for doing the UI, and all the application-specific parts can be offloaded to the iPhone.

One consequence is that you can forget the idea of “jailbreaking” the Watch to connect to a non-iPhone, of course. Another one is that battery life might be at least a day, maybe even two or more. Nothing on Apple’s site so far contradicts any of my reasoning.

So, will WatchKit be accessible from Swift apps? Certainly. Will it itself be written in Swift? I doubt it for now. Maybe in iOS 9 some of the frameworks in iOS (and OS X) will have been rewritten, assuming that by then the Swift optimizer will be good enough. But that won’t be the case in a few months.

Possible but unlikely: WatchKit may have an API to download actual application code to the S1, which may (or may not) have an ARM-like architecture. Only in such a case — and since there will be no Cocoa/iOS frameworks on the Watch — I would expect the downloaded code to be in Swift (without optionals!), for extra safety; can’t have the Watch crashing and rebooting, right?

Update: Marcel Weiher kindly reminded me of CarPlay, which apparently works like that; nobody would say that cars are running iOS. On the other hand, in that case, the device is connected over USB (that is, reasonable bandwidth) and the car doesn’t have any battery life problems.

Comments welcome.

The recent update to WordPress 4.0 seemed to have gone smoothly — perhaps too smoothly.

Turns out it has some fancy new redirection facilities that interfered with some of the pages outside this blog — specifically, some of the product pages, but only if the final /index.html was missing — it then would search the blog for the oldest post mentioning the product. Go figure.

Anyway, I managed to mostly fix it; the sole remaining exception seems to be the Klicko page. Please use this link to get there, in the unlikely case you’re still using that.

Another recent addition is the Crayon plugin to properly format source code on these pages. I’ve checked it out and it seems to have a bazillion options. I’ll have to play around with it and find the one that breaks the fewest older pages — this may take a week or so.

Speaking of a week or so, we’re currently on the road for yet another long trip; this time to Germany, Northern India and Sikkim, Bhutan, Nepal, Italy, Greece and Montenegro. I’ll probably have Internet for another 8 or 9 days, but by then whatever’s not fixed will have to wait for our return around the end of October.

Meanwhile, a small update(1.1.1) to RB App Checker Lite is waiting for review in the Mac App Store. I’ll post the direct download version ASAP; the only change is a fix for a crash that a couple of users complained about. Meanwhile, RB App Quarantine is about to be updated with helpful suggestions from users; I’ll try to do that while underway.

The direct download version of RB App Checker Lite 1.1 (281) is out, and RB App Quarantine also has been updated to build# 281 (its version is still 1.1 since nothing has changed for the user). Check out the release notes!

Most important: this version of RB App Checker Lite considers the new signing rules in TN2206 for OS X 10.9.5 and 10.10. In particular, for applications, code signatures are now checked recursively, both version 1 and version 2 resource rules are shown if present, and the spctl utility is called to check the Gatekeeper assessment.

However, this signals a new development: direct download and Mac App Store versions of RB Utilities will now, unfortunately, have different functionality. In particular, the MAS version of RB App Checker Lite (which is currently in review) will not be allowed to call  spctl, as this utility requires special entitlements to work; and the MAS version of RB App Quarantine (also in review), for the same reason, will not clear the quarantine flag. So for now you may want to download directly from the product pages.

Apple’s rules for calling attention to such differences are a little tricky to navigate but hopefully the MAS versions will be approved and in a future release I’ll develop a way to bring this functionality back through an optional download. Research is underway!