Mystery solved: iTeaHAL

I’ve been getting strange messages in my system and console logs, or when executing certain applications from the command line. Notably iMovie and Skype:

iTeaHAL: Entering...
iTeaHAL: Not iTunes, exiting.

And when executing iTunes, I get this:

iTeaHAL: Entering...
iTeaHAL: Early startup...
itea_hijack_init: result: 0
iTeaHAL: Early startup done.
link added
iTeaHAL: Late startup...
{length = 6, capacity = 6, bytes = 0x000a95c4a60e}
itea_fx_init: result: 0
itea_menu_init: result: 0
iTeaHAL: Late startup done.

If you have no idea what “iTeaHAL” is, this sounds rather ominous… something’s hijacking my iTunes?! It also didn’t help that I noticed this soon after using my laptop (if only for about 30 seconds) on [“the worlds most hostile network”]( at DEFCON 15. I thought perhaps this was some kind of trojan backdoor that was piggybacking off of iTunes Music Sharing or something.

It turns out it’s nothing quite so evil.

Google turned up nothing except other people also wondering what the hell iTeaHAL was. Then I tried finding files named iteahal: “find / -iname iteahal*” also turned up nothing. I knew those strings must be stored somewhere, so next up was a grepping of the entire drive: “grep -arsi iteahal /”.

Success! Other than the system and console logs, the following files were found to contain “iteahal”:


It’s the [SRS iWOW]( iTunes plugin from SRS Labs that’s supposed to make crappy laptop and computer speakers sound better (it actually does a decent job)

Apparently when an application loads audio plugins (like iTunes, iMovie, Skype, and other audio applications), it tries to load the iWow plugin, which detects whether or not it is iTunes, and spews all this debug information to the console.


The “which” Unix command lists the location of the first matching executable in your PATH. The GNU version of “which” has several extra features including the ability to display all matching executables in your PATH, not just the first. This is useful for finding duplicates, etc. Unfortunately, whatever version of “which” is included in Mac OS X (and MacPorts) doesn’t have these extra features.

A quick Google search didn’t turn up anything, and I was in a shell scripting mood when I needed it, so rather than downloading and compiling GNU which I whipped up my own, “multiwhich”:


for PATHDIR in `echo $PATH | tr ":" " "`
    sh -c "ls -1 $PATHDIR/$1" 2> /dev/null

Simply put this somewhere in your PATH with execute permissions, and type “which command“.

One other accidental “feature” of this script is the ability to list every executable in your PATH. This is great for finding duplicates:

multiwhich | sort | uniq -c | sort -n

It’s probably not the most elegant way to do it, but it serves it’s purpose. Perhaps someone will find it useful…

Update: I modified the multiwhich script slightly to support wildcards like “*” and “?”. You can now do things like “multiwhich x*” to get all binaries beginning with “x”, etc.

iPhone crash report gives insight into iPhone software

So, I’ve already managed to “crash” the iPhone, but of course since it runs “OS X” with protected memory and all that fun stuff (and this wasn’t a kernel panic), the crash consisted of Safari closing and returning to the home screen, not completely freezing like my RAZR always did whenever I would try to enter text without putting a space between each letter. I would have to s e n d t e x t m e s s a g e s l i k e t h i s).

The next time I synced, iTunes prompted me for permission to submit a crash report to Apple, and also provided me with the location of the crash report:

/Library/Logs/CrashReporter/MobileDevice/iPhone name/

It looks pretty much like any standard Mac OS X crash report, with some basic OS info along with stack traces for each thread, which thread crashed, CPU register values, and binary image information.

Here’s what I’ve gotten out of it:

1. Apple is calling iPhone’s operating system “OS X 1.0″… no big surprise
2. iPhone’s Safari is called “MobileSafari”
3. The home screen is called “SpringBoard”
4. MobileSafari was process 98 (pretty much meaningless), while SpringBoard was process 15 (compared to Mac OS X’s equivalent, WindowServer, which is process 73 on my Mac).. this gives us an idea of how many processes are running
5. There a bunch of new frameworks we’ve never heard of (including Celestial, MobileBluetooth, IOMobileFramebuffer, CoreSurface, CoreTelephony, numerous others, and liblockdown which sounds rather ominous and intriguing…)
6. …as well as a bunch that we know and love (including Foundation, CoreAudio, CoreVideo, CoreGraphics, IOKit, WeKit, WebCore, JavaScriptCore, CFNetwork, and actually LayerKit which is now known as our friend CoreAnimation)
7. Noticeably absent is AppKit (no big surprise, since very few UI elements look like Cocoa’s), but in it’s place appears to be UIKit.
8. The filesystem structure looks similar to Mac OS X (/Applications, /System/Library/Frameworks, etc)
9. iPhone most definitely runs on an ARM processor, but we already knew that
10. It crashed in WebCore

Some of this makes me think that Apple simply isn’t ready to release an external Cocoa API to the public. Things like LayerKit would need to be changed to CoreAnimation, and UIKit would probably be given a different name, among others. And of course Apple would have to decide on a stable set of APIs before releasing it to 3rd party developers, wheras right now if they need to change something, they have complete control and can do whatever they like.

Update: John Gruber, Martin Gordon, and an forum member have also posted crash logs, from [MobileMail](, [Preferences](, and [MobilePhone]( respectively. They appear to be similar to my crash log, but below I have aggregated and sorted all the referenced Frameworks:


* Preferences
* MobileMail
* MobilePhone
* MobileSafari

Libraries (existing):

* AddressBook
* AppSupport
* AudioToolbox
* CFNetwork
* CoreAudio
* CoreFoundation
* CoreGraphics
* CoreVideo
* Foundation
* IOKit
* JavaScriptCore
* LayerKit – now known as CoreAnimation
* SystemConfiguration
* WebCore
* WebKit
* dyld – dynamic link editor
* libSystem.B.dylib
* libcrypto.0.9.7.dylib
* libgcc_s_v6.1.dylib
* libiconv.2.dylib
* libicucore.A.dylib
* libobjc.A.dylib
* libsqlite3.0.dylib
* libssl.0.9.7.dylib
* libstdc++.6.dylib
* libxml2.2.dylib
* libz.1.dylib

Libraries (new):

* AddressBookUI
* AirPortSettings (Preferences only)
* BluetoothManager (only when Bluetooth is enabled?)
* Calendar (Preferences only)
* Celestial
* CoreSurface
* CoreTelephony
* GraphicsServices
* IAP (Preferences only)
* IOMobileFramebuffer
* ITSync
* MBXConnect
* Message
* MessageUI
* MobileBluetooth
* MobileMailSettings (Preferences only)
* MobileMusicPlayer (Preferences only)
* MusicLibrary (Preferences only)
* OpenGLES (Preferences only)
* Security
* TelephonyUI (MobilePhone and Preferences only)
* UIKit
* URLify
* libIOAudio2User.dylib
* liblockdown.dylib

And finally, what we know about the filesystem:


Anyone care to guess what some of these do?

Update #2: Well, [this pretty blows away]( everything mentioned in this post. It’s a complete listing of all the files on the iPhone’s filesystem. These guys have already figured out how to activate (and deactivate) the iPhone, and appear to be getting pretty close to completely hacking the iPhone to run arbitrary code and possibly unlock it. Exciting stuff.

Where is Drunken Batman?

I was doing a little spring cleaning of my RSS feeds today, and realized we haven’t heard from everyone’s favorite Mac blogger, [Drunken Batman](, in one full year.

Where is he!?

EDIT: Well, he appears to be back, with an [odd rant]( about some guy named Vinay Venkatesh…