Solipsism Gradient

Rainer Brockerhoff’s blog

Browsing Posts tagged iPhone

Posted by PhoneDifferent:
PhoneDifferent linked to this post

Apple: Pull iPhone Firmware 1.1.1?

There are some reports that some folks are finding that the 1.1.1 firmware update for the iPhone has been pulled from Apple, and that the most recent version of iTunes is now reporting 1.0.2 as the most recent version….

Rumors say Apple may switch the iPhone main processor to Intel’s upcoming Moorestown.

It’s too early to speculate until details come out, but it wouldn’t be a surprise to hear that Apple is considering this. And it would explain the closedness of the iPhone/iPod touch architecture… after all, once Apple allows third-party apps in, and publishes a toolchain/SDK, they’re pretty much locked into the current architecture, and switching to a new one is a major/slow/costly undertaking.

Consider the previous iPods as a counterexample. Apple has switched architectures there – we can’t even say for sure how often – without any users noticing. With only the UI visible on OS X, and no toolchain/SDK or even documentation of the innards, Apple is free to change things radically between software updates. By all accounts, the 1.0.x software is pretty much a work in progress, and 1.1.1 has probably changed a lot.

So, keeping things closed for now means the software hasn’t stabilized, and very probably the hardware hasn’t stabilized either.


– the current generation of iPhone/iPod touch will remain closed forever, just like the first generations of iPods;

– an SDK is likely to come out only after everything (especially the hardware) has stabilized;

– Apple is unlikely to invest efforts into implementing TrustZone in the current generation, unless Moorestown (or whatever else they might adopt in the future) has a similar security feature – and maybe not even then;

– the fabled OS X tablet will come out when the new hardware is ready; by that time screens will be ready in the proper sizes; Sony showed an 11″ OLED TV recently, remember…

Posted by halostatue:
halostatue linked to this post

Rainier Brockerhoff on the State of the iPhone

Rainier Brockerhoff’s State of the iPhone is an excellent read. Even though, as a Canadian, I can’t get an iPhone here (damn you, Ted Rogers, knuckle under already you greedy bastard), I really want an iPhone SDK. I might even pay for one,…

Grubered! (thanks, John… that explains the sudden traffic peak.)

Small addendum. The complexity of the whole updating process also explains two things; first, that some non-modified iPhones are also affected, and second, that Apple, busy with debugging Leopard which should come out this month, didn’t want to invest additional resources into reverse-engineering and QAing every hack that’s out there.

Regarding non-modified iPhones being affected – I hear from some quarters that the quantity of those are comparable to “bricked” hacked phones. If true, one more indication that a modern version of that famous saying should be “never ascribe to malice or incompetence that which can be explained by complexity”… icon_wink.gif

Update: forgot to thank Michael Tsai who linked here first.

Update#2: another interesting take on the subject of software complexity is Scott Rosenberg’s Dreaming in Code, which I’ve just ordered.

State of the iPhone

No comments

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.

Re: New iPods

No comments

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, icon_smile.gif but averaging this out to $100 for everybody is no doubt easier to do and is a good thing PR-wise…

New iPods

No comments

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.

Nearly a month ago I wrote:
Rainer Brockerhoff wrote:

So, I’m a 100% percent sure nobody will be able to unlock the iPhone or run third-party applications on it unless Apple opens it up. Here’s why: ARM’s TrustZone

It’s hard to believe Apple didn’t want to take advantage of TrustZone at all, unless the intention was to publish a complete SDK later. Or perhaps only parts of the hardware are protected; the radio and the camera are possibilities.

A SIM hardware unlock hack was published a few days ago, and today Engadget wrote about two software unlocks. There’s no real confirmation on these yet but I no longer doubt it’s possible. I gather that people managed to write software to clear certain parts of the firmware flash RAM.

To me, this shows conclusively that Apple elected not to use TrustZone at all – just as they, in the past, elected not to use the TPM chips on the first Intel Mac motherboards to lock down Mac OS X to Apple machines. About the latter question, of course we’ll have to wait until the Leopard GM release comes out to be absolutely sure, but I haven’t heard anything about Leopard breaking new grounds regarding such protection. On the other hand, while there are groups of people still busily adapting every new Mac OS X release to run on “generic” PCs, they still seem to be very much in the minority – and for a reason. Normal users want support and Apple hardware quality without having to do complicated hacking and installing.

Coming back to the iPhone, on reflection it makes some sense for Apple to not do an unbreakable protection. Under the current situation, every iPhone software update is a single package; I understand that all apps are updated at the same time and everything except the user’s data is wiped and reset. This allows Apple to ensure that all versions of official software mesh with each other and also gives them the freedom to radically change the system, if necessary, without anybody noticing. Also, this means that the first item in any support procedure will be a reinstall, meaning Apple doesn’t need to worry about what the user may have installed; they’ll have to re-hack again later.

I’ve also heard from people who know people close to the iPhone team that all these efforts are closely watched. No doubt Apple saves some time and money, even if indirectly, by the current situation; it would make securing some future version easier should they deem it necessary.

I also think that not having an iPhone SDK available immediately will have been good in the long term. It’s helping Safari gain browser- and mindshares, and it’s allowing the iPhone’s OS X and built-in applications to become more fully debugged without Apple having to worry about keeping legacy APIs around for prematurely released 3rd-party applications. Yes, those apps will be released with a larger delay than people expected, but they’ll rest on a better foundation. With the hacker’s development toolchain becoming more polished there are now some 3rd-party GUI apps being released, and of course Apple will be adopting some ideas for its own apps and SDK (even in the negative sense of making sure they’ll be doing something differently).

From what I’m seeing, AT&T will be the loser in this situation. Apple will sell some more iPhones – probably not in statistically significant numbers at first – but AT&T will lose some contracts. Apple can demonstrate that they did a reasonable effort to prevent that, and it may not even be illegal for someone to unlock their own phone (it’s probably illegal to set up a business unlocking other people’s phones though). So, AT&T will lose some business to other carriers, as they do with other phones.

I usually don’t believe in sinister Apple agendas, but this may qualify… icon_smile.gif

Photos licensed by Creative Commons license. Unless otherwise noted, content © 2002-2022 by Rainer Brockerhoff. Iravan child theme by Rainer Brockerhoff, based on Arjuna-X, a WordPress Theme by SRS Solutions. jQuery UI based on Aristo.