Rainer Brockerhoff

[Rainer Brockerhoff]

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. Ehrm, make that 90%. I mean, it's still quite unlikely. Well, OK, they can hack the serial interface in the connector but that can't write to the screen. Well, let's say 50-50. Of course, they can run stuff but not touch the network interface - OK, it seems they can. But never run a GUI app! Oh, they can now? But aren't the binaries signed? No. Heh...

That's about how I felt while writing an article for MAC+ (the upcoming print issue, which went to the printer a few days ago, around the "but never run a GUI app" phase. Well, today I see they ("they" don't want people to link to their Wiki, but it's easy to find on Google) succeeded in building a standard GUI app and display a screen on the iPhone. Must be Clarke's Law in action - even though I'm not that elderly, hmpfh. Writing about moving targets is hard.

So what's left? Of course I don't have an iPhone myself here and I don't have any privileged info on its architecture. I did hear over the grapevine that the Apple iPhone is following these issues with great interest and is working on updates - whether they'll make a point of plugging these hacks is anybody's guess. At the time I'm typing this, accessing the cellphone radio and unlocking the SIM card mechanism is still not possible.

Does that mean Apple didn't bother to implement the TrustZone technology? I still maintain it's impossible to crack from outside using present technology. The firmware is contained on the CPU chip itself, the implementor can restrict access to certain peripherals, decryption can happen entirely within the trusted zone, and the firmware can elect to run only signed binaries. There are some 1024-bit RSA keys in the iPhone which supposedly are still a few years away from being cracked, and in any event could be switched to 2048 or 4096. The barrier is even stronger than it was on the first Intel Macs, which had a TPM chip onboard (the last versions don't and it seems Apple never used them) but separate from the CPU.

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. For sure they didn't implement the usual Unix protection, where the root account can do everything; all processes on the iPhone run as root anyway. Looking at the current iPhone libraries there's a "lockdown" library which most applications link against. It seems to check the aforementioned keys and confer privileges to access some likely-sounding sectors of the system. Having a non-standard security system is obviously an attempt to throw off people who expect 99% of the cracking to involve getting root privileges. I don't have the tools to ascertain whether the lockdown library does in fact invoke TrustZone at a lower level, and much of this may change anyway for the next software update.

Speaking of which, from what we can see of the iPhone software the update process will involve a complete replacement - no partial updates here. My guess is that updating will also be mandatory, with iTunes updates being published simultaneously. Replacing all software at once of course makes sure that everything works together, but it would also allow Apple to change everything at once. We'll know in a few months, I'd say.

[Rainer Brockerhoff]

If you're an XRay user - even if not registered - please go to this poll and respond. I need to know ASAP if I can, as I want to, make XRay II a Leopard-only application. Also please post suggestions there; although I'll keep on commenting about progress and programming issues here, I'd like to keep actual feature discussions over there at the poll topic.

The decision on Leopard needs to be made in the next 2 weeks, so if a majority of users agrees - or if I get too few responses - I'll decide in favor of Leopard.

[Rainer Brockerhoff]

Wow, over 20 days without a post, and I didn't notice. Yes, I'm still here... though not that much "here", but offline. Here's some of what happened.

About 5 months ago I posted about my temperature problems with the hard drive inside the iMac G5. I'd solved them somewhat preliminarly by buying a new (and supposedly less-hot) drive and putting some heatsink paste under the thermal sensor. Here's the sensor picture again:


Well, about 3 weeks ago I left the iMac overnight, downloading some large file. I came back to it in the morning and it had frozen, and I heard some faint beeping which appeared to come from the UPS I keep just behind the machine. I turned everything off, waited half an hour or so, and restarted - everything worked fine but in two hours it froze again when the faint beeping started. This time, I could ascertain that
1) the beeping was actually a buzzing coming from the hard drive
2) the hard drive sensor said a reasonable 53.5C
3) the hard drive SMART sensor said the drive was actually at 61C!

Whoa. Something clearly had changed since February, when I said the average difference between the two sensors had shrunk to 4C. I did some cautious testing over the next week. Indeed, the external sensor never went over 53.5C - and the fan begins to rev up only at 54C, but it never got there. The sensor actually tracked the SMART value reasonably well - to 1C below 50C, to 3-4C until 53C, but then the internal temperature just soared. As soon as that went to anywhere over 59C, the drive froze and started buzzing. After cooling off everything started working again.

Up until last weekend, I tried changing the heatsink paste - no change. I tried out several fan control programs, none worked with the iMac. I tried finding out some software way to kick the fans up, but didn't have too much time to really study the problem. A friend gave me a small flat fan from a laptop which I tried to mount inside, but there's no space available anywhere near the drive.

About the only thing that helped a little was mounting a couple of other small fans blowing into the air intakes below the iMac - I glued them in place with some gaffer tape and ran them off a spare 12V supply. But it clearly wasn't a definite solution; it sort of worked for a few hours as long as I kept the CPU speed on "reduced" and didn't open too many programs at a time. I suppose someone should make a supplementary fan unit sucking air out of the iMac, like we had for the MacPlus... I wonder if the current Intel iMacs also overheat?

Anyway, last weekend I gave up and performed minor surgery on the sensor cable, making it about 10cm (4") longer. The main trick was to convince it to part company with its original mounting place - people who'd performed this procedure before recommended using a "thin blade", but none I had were thin enough. The optimum solution is a length of dental floss. If you try this, work it under the double-sided white tape that glues the sensor board to the metal bracket, so the tape stays stuck to the board. I got it off cleanly with its adhesive properties still intact.

I experimented with a few locations, but the only easy one was a small flat space between the drive spindle and the PC board. In that location, so far as I can see, the two temperatures track each other to 2C - usually even to 0.5C. One shouldn't check the SMART temperature too frequently or the drive never sleeps; 20 minutes seems OK. The temperature hovers between 52C and 57C under normal workload... still not ideal. But the fans kick in and the iMac now sounds louder, much like it did when it was new. I suppose I'm the only iMac G5 owner who's glad to hear loud fan noises...

However, today, just when I was finally ready to start working on my usual stuff again, the @#$%^& thing froze again - and while both temperatures were at 52C, where it should work. So either I need to reformat, or install air conditioning, or get a new drive while the current one is under warranty. Or all of these. There goes another weekend...

[Rainer Brockerhoff]

Just found time to read John Gruber's first impressions of the iPhone. Worth a read, but the most interesting part is where he says that iTunes showed him a crash report, which he posted.

Several interesting items are evident in the crash report, the most interesting is the following line:

[Rainer Brockerhoff]

Googling (oops, pardon, searching Google I mean) for iPhone just now yields "about 76,100,000" hits. Wow. Just goes to show how Steve Jobs has perfected the art of letting the press do Apple's marketing at very little cost.

As a stockholder, I'm all for it. By all accounts, the iPhone, which goes on sale the day after tomorrow, will sell very well, and AAPL stock has already gone up 50% this year. As a cellphone non-user I don't care; it'll take a long time to be sold here in Brazil, and even if it were on sale tomorrow, I wouldn't buy one for my daily use. As I said before, a "OS X"-based tablet would be more interesting.

But speaking of OS X, I wonder what version will be installed on the iPhone. The TV seems to run a special build of version 10.4.7, by all accounts. Originally I'd expected the iPhone to run a stripped-down version of 10.5 (Leopard), but now that Leopard has been delayed, that's no longer plausible. How Apple will manage the whole Mac OS X - OS X dichotomy still remains a mistery... no doubt we'll have detailed dissections of the iPhone contents next Saturday.

[Rainer Brockerhoff]

OK, here's what I wrote a few days ago, regarding the Mac OS X transition to Intel:

[Stefan Tilkov's Random St]

Stefan Tilkov's Random Stuff linked to this post

[Rainer Brockerhoff]

One of the salient points repeated at the WWDC keynote was Leopard's support for "64 bits top to bottom". However, a close peek at the slide shown this year showed a subtle difference to last year's - the word "Carbon" was missing. Of course a storm of confusion soon ensued, with the usual wailing and gnashing of teeth from some quarters and polite shrugging from others. Apple stock fell and rose again, some developers professed bliss while others threatened to leave the platform, non-developers wrote learned analyses about obscure technical points, not to speak of reports of raining frogs or even an unconfirmed Elvis sighting in a Moscone restroom. Allow me to try to explain all (well, Elvis excepted).

First of all, there are a few implications in moving an operating system to 64 bits. I hear that Windows Vista comes in distinct 32-bit and 64-bit versions and that the latter is able to run 32-bit applications (with some restrictions) inside a compatibility box. In contrast, Leopard uses Apple's experience with architectural migrations to support 32 and 64 bit applications natively on both PowerPC and x86 architectures - not so easy in the second case, but necessary since nearly all currently shipping Macs use Intel's Core 2 Duo, which is 64-bit capable.

For this, Apple took advantage of Mach-O's support for "fat binaries" - in this instance called "obese". Obese binaries contain four different executables: PowerPC 32, PowerPC 64, x86 32 and x86 64. When running one of these applications, the system selects the best supported architecture and links the application to the corresponding (and equally obese) system libraries.

Enter the Carbon vs. Cocoa question. Cocoa APIs are derived from NeXT's software and are called, usually, from Objective-C. Carbon APIs, to be called indistinctly from C, ++ or Objective-C, were first introduced in Mac OS 8.5 or thereabouts and were, themselves, a much-needed simplification of the "Classic" Mac APIs. Carbon was thereafter positioned as the way to port existing applications to Mac OS X, while Cocoa was supposed to be the right way to write new applications for the new system. No doubt the old NeXTies inside Apple pressed for Carbon being excluded from the start, but Microsoft, Adobe and Macromedia (to quote just the big companies) didn't want to recode everything on short notice.

A necessary sidenote: the exact definition of "Carbon" is surprisingly hard to pin down, even among experienced developers. Here's my own (although I've never written a Carbon app myself). There are Carbon APIs and Carbon applications. A Carbon application, for me, uses the Carbon Event Model - calling Carbon APIs to get events from the system. Until recently, a Carbon application would also, necessarily, use Carbon windows and the GUI widgets for those, mostly contained in the HIToolbox framework. Starting with Tiger it's possible for Carbon applications to use Cocoa windows containing Cocoa GUI widgets, with some contortions of course. Other Carbon APIs - like the File Manager, or QuickTime - can be called indistinctly from Carbon or Cocoa applications.

Here's where things started going awry, from the standpoint of established or multiplatform developers. Apple has always been of several minds about Carbon policy - it was often dismissed as a temporary "transition" technology, while people who interfaced with those developers had to reassure them that Carbon was not going away anytime soon and was not a second-class citizen. Porting software from the Classic Mac OS to Carbon wasn't always easy; some larger applications took over a year. At the same time, it was seen as being much easier than tossing the whole codebase and recoding in Objective-C/Cocoa.

Now, a few years after Mac OS X was introduced Microsoft, Adobe and so forth had a substantial investment in maintaining parallel codebases for their Carbon applications and, understandably, began dragging their feet about converting to Cocoa at any time soon, or even at all. Due to pressure from these developers the Carbon GUI APIs began to incorporate new elements present only in Cocoa until then, and to all appearances Carbon and Cocoa were now positioned as equal and parallel APIs. In secret, of course, Apple hoped that "those people" would sooner or later see the light and begin doing their next x.0 version in Cocoa. In turn, "those people" harbored serious doubts about Objective-C (seeing it as a dead language with an unreadable syntax) and secretly hoped Apple would "recode Cocoa in C++". Here's a significant e-mail from an Apple engineer to the carbon-dev list:

[Rainer Brockerhoff]

There's one new thing on Safari 3 (for the Mac) that I found quite by accident.

Right-click on anything in a browser page and at the end of the normal contextual menu you'll see a "Inspect Element" item. Selecting that opens a semitransparent "Web Inspector" HUD which shows tons of information about the document's DOM structure, including CSS styles, element metrics, properties, and so forth.

The whole light-text-on-transparent-black look of these HUDs seems to be a matter of taste - I like them well enough in iPhoto, but on a white background, not so much - and there are some bugs; the top outline view doesn't respond to the scroll wheel, for instance. Still, this seems to be a very useful tool for debugging your web pages; it's making me want to (finally) redesign my site, even!

Ah, and this seems to work only if you have Safari's debugging menu enabled. To enable it, quit Safari, open the Terminal and type:

[Rainer Brockerhoff]

One significant announcement (some say the only one) at WWDC is the Safari 3 Beta, which includes Safari for Windows; at least it's the one I've seen the most varied interpretations of, so far.

Considered as a beta release, Safari 3 is so-so. The Mac version needs a reboot because it also substitutes the Dock (which runs Dashboard widgets) and the system-wide webkit. It also substitutes the standard Safari installations. I had to reinstall Flash afterwards to get some sites to work. For my usual sites, it performed quite well although I had one crash. I don't have a XP machine to test the Windows version on, but I hear it's unusable on non-English versions, and very flaky on most English systems as well.

Steve Jobs stated the primary intention was to widen Safari's marketshare, and the demo concentrated on a supposed serious speed advantage on Windows - "more than twice as fast as Internet Explorer". And then, in the "one last thing" section, he refers to a "very sweet solution" for developing apps for the iPhone : the full Safari engine, no SDK needed allows Web 2.0/AJAX applications. (The entire section was received with silence by the crowd.) Steve's statement that this is "a very modern way to build applications" somewhat contradicts what he said at D5: