Solipsism Gradient

So, half a dozen softwares are now out there that unlock the iPhone in various ways. In the simpler case, they allow the installation of various third-party applications and/or twiddling details. In the more complex case, they mess around with the various phone/SIM settings to allow the iPhone to be used with other provider’s SIM cards.

As I wrote before, Apple has apparently allowed this to happen by not implementing strict security measures. Now that the various unlocking techniques have stabilized, Apple has announced that an upcoming software update might cause “modified” iPhones to become “permanently inoperable”. Just a few days later, the iPhone update to version 1.1.1 came out; it featured the same warning in bold on its installation screen; and it did, indeed, cause some modified iPhones to lock up – the new vernacular is “bricked”, which I think somewhat of an exaggeration. Furthermore, the new software seems as tamper-resistant as the iPod touch software, indicating that Apple has checked out current unlocking techniques and implemented harder locks.

So far, all that was to be expected. What was, to me, unexpected was the reaction of some sectors of the press and of some users – mostly the same people who opposed the iPhone price cut, it seems.

Legally, it seems Apple is in the clear. The warranty and license agreement clearly say that any such tampering is at the phone owner’s risk. Surprisingly, some people seem to feel “entitled” to get warranty support even if they completely disobeyed the license! (Just as they felt “entitled” to have the price kept constant for a long period after they bought it, I suppose.)

The core of the argument seems to be “I paid for the machine, therefore I have the right to do whatever I want with it…” (I completely agree so far) “…and Apple has the obligation to give me full support, warranty and updates no matter how I mess with it!” Now here is where we part company. Sure, I suppose current consumer protection legislation may sometimes be interpreted that way (note I’m not a lawyer and less familiar with US legislation than with the Brazilian one); but you surely can’t pretend that Apple is a public utility or a non-profit charity.

Even from the technical standpoint, these expectations are unreasonable; allow me to explain this in more detail. The problem is one of “state“, in this case defined as ” unique configuration of information in a program or machine”.

In the first computers, the state of the computer was completely predictable when it was turned on: if it had Core memory, it was in essentially the same state it had when it was last turned off, and if the computer had reasonable power supply sequencing, you could just press the start button and continue. For more complex machines this was too hard to do, and the manufacturers declared that the machine was in an undefined/unreliable state after power-on, and that therefore you had to reload the software. For newer machines with semiconductor memory, everything was of course lost during power-off, and software reloading became equally necessary. To do so, you had to enter a short program in machine language using the front-panel toggle switches; this program, in turn, would read the actual software you wanted to run from a peripheral. This was the direct consequence of the machine coming up in a “null state”.

It wasn’t long before people thought of several ingenious ways to make this process more convenient. On the IBM1130, for instance, the hardware was set to read a special card from the punched-card reader, interpret the 80 columns (12 holes each) as 80 16-bit instructions, and execute them. The most commonly used of these cards simply repeated the process with the built-in cartridge disk drive, reading the first sector on the cartridge and executing it. Later on, the falling cost of ROM led to the boot software simply being built into the machine – the Apple II had a complete BASIC interpreter built-in, for instance. The apex of this evolution was the original Mac 128, where most of the system software was in the boot ROM – the system disk simply contained additions and patches. (The QI900 microcomputer I helped design in the ’80s had all system software, with windowing, multitasking and debugging, built into its ROM.) Here we had a well-defined “state” when the machine came up – it would execute a well-known program, and do predictable things, until external software came into play.

In the ’90s the limitations of this became apparent. OSes grew to a size beyond what could be stored in ROM, and no single Boot ROM could do justice to all models and peripherals (*cough* BIOS). Flash memory came up, the built-in software was renamed to “firmware”, and updates to that became commonplace. It was easy to “brick” a system if power went out or if you otherwise interrupted a firmware update before it was complete. In that event, a motherboard swap was usually the only solution, because the interruption left the firmware in a partial, nonworking “state”.

Consider now the iPhone. Its entire system (OS X 1.x) is built into firmware, mostly in a compressed state. This is expanded and run by the main ARM processor, obeying a built-in boot ROM. Supposedly, there are at least two more processors, taking care of network communications and of the cellular radio; each of these has its own boot ROM, and the radio processor has separate flash memory to hold state information regarding the SIM card, cellular system activation and so forth. One of these processors no doubt controls the USB interface to allow the main processor’s flash memory to be reloaded externally. Furthermore, every SIM card also has flash memory on it, containing the IMSI number, network identity, encryption keys and so forth, bringing one more source of complexity to the process.

In other words, you have a complex system of at least 3 processors interacting, each one with a boot ROM, two with flash memory containing state information. Powering up such a beast is a complex dance of each one waking up, testing its peripherals, checking its own state, then trying to talk to each other, then communicating to bring the entire system into a working state. Furthermore, the necessities of the cellphone system and of testing out such a complex piece of hardware mean that the iPhone must decide, on each power-up, in which of several states it’s in: factory testing, just out of the box, activated, reloading the main firmware, working, “plane” mode, and so forth. This is usually done by writing special values to reserved sections of the various flash memories, and of making sure they are always consistent with each other by checksumming and other technical arcana. Should they be found inconsistent, the system will probably try to regress to a simpler state and start over there, in the extreme throwing up its metaphorical hands and plead to be returned to the factory. Ideally, firmware writers strive to make it impossible to “brick”, unless an actual hardware defect occurs, of course; in practice, it’s rarely possible to envision all possible combinations of what could happen, and too few designers do assume a malicious agency is trying to trip them up at all times.

So, what do these various hacks do to unlock the iPhone? They rely upon bugs in the communications software, firstly, to make the system fall back into a state where it pleads for an external agency to reload its main firmware; cleverly substituted instructions then make it do new things. After several, progressively more complex, phases of this, new applications can be installed. Up to this point, only the main flash memory has been affected and installing a new software update will just bring the system back to the standard state. Now, one of the new applications may try to mess with the radio firmware; it will clear or set regions of it to bring the radio processor’s state out of step with reality, or even write bogus activation data into it.

Now, of course, the system’s state has been moved completely out of the state space envisioned by its designers. When it powers up, the state is sufficiently consistent – the various checksums check out OK, for instance – for the various processors to confidently start working. However, a few actual values are different from the intended ones – enough to let a different SIM card work, say. Now, if the hackers had the actual source code and documentation available, all this could be done in a reliable way. But this not being the case, they had to work by testing changes in various places and observing what happened, clearly not an optimal process.

Consider, now, the software update process. It assumes that the iPhone’s various processors and firmware(s) are in one of the known states – indeed, this is required for the complex cooperation required for uploading new software. If this cooperation is disrupted, the update may not begin – leading to an error message – or, worse, it may begin but not conclude properly. At this point, one or more of the iPhones processors may try to enter a recovery routine, either wiping the flash memories or to reinitialize them to a known state. No doubt this will be successful in most cases, and the new update will then be installable on a second attempt. However, the recovery may fail – since the exact circumstances couldn’t be foreseen – or it may be assuming false preconditions (like, a valid AT&T SIM card being present). The system will probably try to recover at successively lower states until falling back to the “can’t think of anything more, take me back to the factory” mode; or it may even lock up and “brick”.

Should Apple’s firmware programmers have tried to prevent this from happening? Well, up to a point they certainly did, as many problems other than hackers can cause such errors – electrical noise, badly seated or marginally defective SIM card, low battery, for instance. The system has to fail gracefully. However, it’s certainly not reasonable to expect them to specifically recognize and work around (or even tolerate!) the various hacks; after all Apple’s contract with AT&T certainly requires them to evidence due diligence in preventing that.

Firmware for such a complex system evolves continuously. The new 1.1.1 iPhone software seems to do many things differently from the original version, even though much of the UI is the same; same goes for the iPod touch software. Neither has been hacked as I write this. Did they now put TrustZone into operation? No idea; time will tell. My hunch is that Apple will eventually come out with an SDK for third-party applications sometime; the question is when. Perhaps after Leopard, perhaps at the 2008 WWDC. Does Apple need AT&T, or any partner carrier, at all? Maybe for now they do, and the unlocking wrangle will continue. In the long run, Apple will be better off with a universal phone that will work anywhere; possibly we’ll have to wait for the current generation of carriers to die before this happens. Interesting times.

It’s been about 38 years since I first saw a somewhat simpler version of this:

Dark Roasted Blend for reminding me.

Update: many more details about the drawing. Its origins still appear to be obscure.

Some time ago I published Flipr source code:
Rainer Brockerhoff wrote:

…a category on NSWindow to flip from some window to another window.

I’m not sure how many people adopted it, but the nice Karelia folks are using it in the upcoming iMedia browser. A few days ago they asked me to look into a “hesitation” effect which could be seen in the first frames of the animation in certain circumstances, and it’s now fixed… so if you used it somewhere, download it again (and tell me).

Just noticed I was utterly remiss in not linking to Miss Cellania on Schrödinger’s Cat as soon as I found it. So there. Please empty your mouth of all fluids before clicking on that link.

Apple has announced a $100 credit to most (perhaps all) customers who paid the old prices for the iPhone and who are not entitled to a full $200 rebate. Previously there had been much whining and reports of uneven treatment for customers who bought iPhones more than 14 days before the announcements.

No wonder some customers and most analysts are confused. First the iPhone comes out at $599 (I’m talking always about the 8GB model, of course). Early adopters rush off to buy it while others say it’s way too expensive. 66 days later the price goes down over 33%. While most people reacted negatively to this, not all did.

Steve Jobs is right, in the technology business prices always go down fast and faster, and most people forget this is true on the component side too. With the first 700,000 iPhones sold, Apple did an excellent job of balancing costs, supply and demand. Now that the first rush is over, and with a second device coming out using many of the same components, their costs go down sharply and this has to be reflected in the pricing, especially in view of the holiday season. Had the iPod touch come out at $499 just to appease early adopters, it might have flopped in the season, and people would have complained as usual about Apple gouging customers with high margins.

PS: Of course, the geeky thing would have been to make the rebate proportional to days elapsed between purchase and announcement – $3 per day or so, but averaging this out to $100 for everybody is no doubt easier to do and is a good thing PR-wise…

Not that I’ve been overly interested in the new iPod announcements – my current G3 iPod (40GB), which I bought at the Paris Apple Expo exact 4 years ago, still works fine and still has some empty space. Battery life, even, is still a reasonable 6-7 hours. Can’t see myself buying a new iPod anytime soon; at least not for music.

Announcements like new colors and form factors are therefore not really relevant to me; Starbucks (huh?) and ringtones, meh. What’s interesting is the new iPod touch, despite the somewhat silly name. The base model is essentially an 8GB iPhone, but without the microphone, camera, BlueTooth and phone radio parts – it remains to be seen if they also took the speakers out. It’s also a little smaller in all dimensions, though the screen resolution is the same. At $299 this would cannibalize a significant part of iPhone sales, but this has been neatly counterbalanced by the 8GB iPhone price reduction from $599 to $399. And with the disappearance of the 4GB iPhone this should keep iPhone sales going well as before.

There’s also a $399 model with 16GB. Though Apple didn’t think it necessary to say so, the iPod touch of course is based on the same hardware/platform as the iPhone, running OS X and all. I suppose that all of the recent tricks to install extra applications will work on it. There’s certainly plenty of space for extra icons on the main screen, and the somewhat inexplicable omission of Google Maps will probably be the first thing to be corrected by users.

All this is certainly very positive to Apple stockholders, though the stock fell back to last week’s levels, as usual after announcements. In the long run, the new iPod will probably be seen as the first of the OS X tablets. The next generation should have a 640×480 or 1024×576 screen, and hopefully a built-in GPS device. Indeed, from all accounts, the only thing still holding such a device back is the unavailability of such a touchscreen at a reasonable price.

Finally, there’s no more excuse of “phone network security”; the new iPod should be the hardware part of the (hopefully) upcoming OS X development SDK. I expect that it will be announced at the end of October when Leopard and Xcode 3 come out.