How Apple “Bricked” the iPhone

Much has been written about why Apple (AAPL) issued software update 1.1.1, which wreaked havoc with untold numbers of iPhones, but not much about how they did it.

It’s not an easy riddle to untangle. The update seems to have affected different iPhones in different ways. Although there are plenty of stories about unlocked phones being “bricked” by the update, there are anecdotal reports of unlocked phones that worked just fine under 1.1.1 — albeit only with AT&T’s (T) service, not T-Mobile’s or any other carrier’s. Some phones modified by third-party software were also broken by the update; others lost their unapproved applications but were otherwise unaffected. Even some virgin, unmodified phones were rendered inoperable, for reasons that remain mysterious.

As Erica Sadun of The Unofficial Apple Weblog (tuaw.com) puts it: “the transition from working iPhone to brick seems to be a completely random process.”

Part of the problem is that the firmware that launches the iPhone is as complicated as a tropical ecosystem, subject to innumerable variables. Rainer Brockerhoff, a Brazilian programmer who hosts a site called Solipsism Gradient, has written a description of the device’s start-up routine that gives you a feel for the intricacies involved. In the iPhone, he writes …

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

Consider, now, the software update process. It assumes that the iPhone’s various processors and firmware(s) are in one of the known states … 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 … 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”. (link)

Meanwhile, programmers trying to work with the iPhones that survived software update 1.1.1 find themselves in a whole new world of coding difficulties. Erica Sadun, who in addition to a passel of books has written several (now obsolete) iPhone apps, including Snap (for iPhone screenshots), and VoiceNotes (a voice recorder), puts the changes Apple made in layman’s terms:

“In the good old days,” she explains, “iTunes would send commands to the iPhone and the iPhone would do whatever it said. iTunes might tell the iPhone to mount a disk, copy a file, start an application — all the things you expect a computer to do.”

Now, she says, it’s a one-way street. “iTunes’ dialog has been reduced to ‘hello,’ ‘goodbye’ and ‘please start a restore.’” Requests for data today come only from the iPhone, and those requests are carefully encrypted. “They require a certificate that has to be signed just so with Apple’s encryption key.

“The iPhone has gone from being a very open device to a very locked down one. Its requests are encrypted. Its screen is encrypted. Its brain is encrypted.”

Even programs like Ambrosia’s popular iToner ringtone maker — which played by Apple’s rules and asked nothing more of the device than to put a file in user memory — no longer works under 1.1.1.

In an interview with tuaw’s Mat Lu, Ambrosia president Andrew Welch was gracious about Apple’s legitimate business needs and his company’s bad luck (this is the second time an Apple software update has broken his $15 program), but admits to being frustrated.

With iToner, we worked very, very hard to make sure we did things the right way. We didn’t hack into the phone at all, we didn’t “jailbreak” it - we used the same APIs that iTunes uses to put files on the iPhone, and we put those ringtones in the user area of the phone. … Apple is intentionally making sure that products like ours don’t work. That I think is a mistake — it’s as if in an iPhone OS update, Apple decided that MP3s you got from ripping a CD should no longer play on your iPhone, and you should instead buy them from their store. (link)

Apple’s defenders are quick to point out that there’s a limit to how far the company can be expected to go in support of outside developers — especially those who used hacks like Jailbreak to alter iPhone’s firmware. On the Mac Observers’ Apple Finance Board, a systems developer who posts under the handle dmiller wrote earlier this week:

If Apple were to take responsibility for not breaking existing 3rd party functionality, they would be just as “stuck” as Microsoft has been, for years, with Windows having to support a legacy base of code and drivers. All dependent on the past. Where did legacy support get them? Years and billions down the drain, to arrive at: Vista. What else needs to be said?

Apple has to “own” the phone, and the internals, and the state of the phone, and they need to be able to move it quickly, to improve it. (link)

Third-party programmers like Sadun don’t necessarily disagree. But that doesn’t make them any less saddened by the developments of the past week.

“It’s disappointing, because the iPhone was a very good platform,” she says. “It was delight to use and a delight to write for. It’s a shame.”

See also Estimate: As Many as 100,000 iPhones Sold for Unlock

[Apple Store photo courtesy of E. Sadun/tuaw.]