iPhone headphone jack

As much as I love the iPhone, it certainly has a few quirks. My number one complaint is the ridiculous recessed headphone jack that won’t fit nearly any headphone plug, other than skinny iPhone and iPod headphones. And it’s not like this was some naïve accident that Apple didn’t know about… since the first day the iPhone went on sale Apple has stocked lame, overpriced adapters.

I didn’t want to spend $10, nor did I want to carry around a stupid little adapter, so I went with the free and obvious solution, trim the excess plastic off each of the audio plugs I wanted to use with my iPhone:


(left to right: Shure E3C in ear headphones, Monster FT transmitter, standard iPhone headphones)

Use a sharp knife like an Xacto to trim away just as much plastic as necessary to make the plug fit. Be careful you don’t cut too deep and slice the actual wires.

Security concerns in "web installer" and XBMC's web server

There have been some questions as to the security implications of the “web installer” available for installing the [XBMC iPhone Remote](http://tlrobinson.net/projects/xbmciphone/) and other XBMC applications. This page explains how it works and the problems with XBMC’s web server [HTTP-API](http://www.xboxmediacenter.com/wiki/index.php?title=web serverHTTP-API) which make this installer possible, as well as the solution to securing your XBMC web server.

Please note that simply installing XBMC iPhone Remote using EITHER the manual installation or web installation does NOT make your Xbox any less secure. It’s just HTML, CSS, and JavaScript, which are all harmless. There’s no server side ASP or Python code at all, other than in the web installer. Enabling XBMC’s web server in the first place (without password protection) is the problem.

Luckily there is an easy (although flawed) fix. See the “Solutions” section for instructions on how to enable password protection on the XBMC web server.

### Background ###

Any Xbox Media Center installation that has the web server enabled also has an HTTP interface that can be used to control various things on the Xbox, including pausing/playing, listing of files, etc, which are used extensively in the XBMC iPhone Remote and make it possible. It also allows you to control such things as downloading files, executing scripts, deleting files, etc, which are used in the “web installer”. Anyone who thinks about this for a moment will realize that this is rather unsafe, and could easily be used by malicious hackers to delete files, steal passwords, or gain complete control of your Xbox.

Normally this would not be a big problem because most users have their Xbox and computers on a LAN behind a home router (like Linksys, DLink, etc) so this interface isn’t available to the public Internet unless they specifically forward port 80 (HTTP) to their Xbox.

BUT, since for the web interface to be useful the user’s computer, iPhone, etc must have access to the Xbox’s web server. So the problem (or solution, in the case of the web installer) is that the user’s browser has unrestricted access to the web interface. When the user visits a webpage, that webpage could easily execute any command on the Xbox simply by loading an appropriate URL in a browser window or iframe.

Due to the [same origin policy](http://en.wikipedia.org/wiki/Same_origin_policy) in place on web browsers, the page that executes the command cannot access the results of the command, but that doesn’t matter since we can use the API to download and execute arbitrary PYthon scripts.

### How the web installer works ###

In fact this is exactly how the web installer works. It has to bootstrap itself by downloading a simple install script, then executes that script to do the actual installation. Credit goes to LiquidIce for the original web installer, I just modified it to be a little more automated and to suit the XBMC iPhone Remote.

The user enters their Xbox’s IP address into a text field on the project page, then presses the “Install” button:

– http://tlrobinson.net/projects/xbmciphone/index.php

The “Install” button executes a little JavaScript that creates a special URL with the user’s specified IP address, the “FileUpload” command, and the file to be uploaded which is a Python script that has been encoded into [Base64](http://en.wikipedia.org/wiki/Base64):

– http://tlrobinson.net/projects/xbmciphone/webinstaller.js (the JavaScript)
– http://tlrobinson.net/projects/xbmciphone/webinstaller-iphone.spy (the Python script before Base64 encoding)

The URL looks something like this (with replaced with the actual Xbox IP, and ABCDEFG replaced with the actual long string of Base64 encoded Python, webinstaller-iphone.spy):;ABCDEFG)

The following commands can be used on Mac OS X (and others?) to encode and decode Base64, respectively:
– openssl enc -base64 -in webinstaller-iphone.spy > webinstaller-iphone-base64.txt
– openssl enc -base64 -d -in webinstaller-iphone-base64.txt > webinstaller-iphone.spy

The URL is then loaded into the iframe, which uploads the script to Q:/web/webinstaller-iphone.spy on the Xbox. After a short delay to ensure it had time to upload, the JavaScript then executes the just uploaded Python file by loading a URL similar to the one below in same iframe:


That executes the Python code that downloads the actual XBMC iPhone Remote files to the correct directory, cleans up, and finally redirects the page to to display it.

– http://tlrobinson.net/projects/xbmciphone/iphone.rar (the rar file containing XBMC iPhone Remote)

So there it is. It’s nothing too sneaky. Feel free to look at all the files for yourself, decode the Base64 Python code, etc.

### The Problem ###

While this web installer is harmless, it would be trivial to write something more destructive to delete files, steal stored passwords for SMB, FTP, etc.

For the web installer, we simply ask the user for their Xbox’s IP address since we assume the user trusts us, but it wouldn’t be hard to brute force try all the common home LAN IP addresses (commonly 192.168.x.x). Also, while the web installer requires users interaction to initiate the installation, there’s no reason a malicious script couldn’t execute automatically.

Fortunately, XBMC provides password protection for the web server. Unfortunately, it’s not enable by default, and most people don’t bother to enable it.

### The (Partial) Solution ###

The solution is simple: enable password protection on the XBMC web server. In the Network settings menu, under Servers, there’s an option for a password.

There is one major problem with this: once you log into web server, the browser remembers that you have logged in for the remainder of the time it is open. This is convenient, as it would be very annoying to have to enter your username and password every time you issue a command to the, but could potentially be taken advantage of if you happen to log in prior to visiting a malicious page.

To test this (with the harmless web install example), enable password protection, then log into your Xbox’s web interface by visiting http://xbox/ where “xbox” is replaced with the actual Xbox IP address. Then use the [web installer](http://tlrobinson.net/projects/xbmc/) to perform the installation. It won’t ask for your password.

Additionally, you can change the web server port or use an obscure IP address for your Xbox. Although this only amounts to security through obscurity, it would likely be enough, bar some really determined hacker with something like [Jitko](http://ha.ckers.org/blog/20070402/jikto-leaked/).

### Conclusion ###

While it’s pretty unlikely that anyone cares enough about your Xbox to hack it, it’s a definite possibility, and would be nearly trivial with all the dangerous (yet useful) commands the HTTP-API gives us. In addition to being a neat and easy way to install a cool app on your Xbox, the web installer serves as a harmless proof of concept.

Thanks to LiquidIce for providing the original web installer code and idea.

iPhone headphones survive the ultimate test: washer and dryer

I was folding my laundry tonight, and found these at the bottom of the pile:


Yup, my nearly brand new iPhone headphones rolled up into a neat little ball. They got run through the washing machine and dryer… oops.

After several minutes of detangling, I was left with a thoroughly kinked and curled set of iPhone headphones:


I have a terrible record of destroying iPod headphones, so I thought for sure they were ruined. Nope! They work fine. Even the microphone and little clicky button thing. Amazing.

The iPhone, on the otherhand, doesn’t leave my sight. I’ll just let someone try it with theirs first…

The iPhone and Apple's 3rd party developer solution… web apps

Not many developers are happy with Apple’s solution for developing applications for the iPhone: web applications. Personally, I’m ok with it because I’ve seen what can be done with JavaScript.

Except for a few things:

– Lack of access to the hardware.
– Inability to run applications offline.
– Limited integration with the rest of the user interface.

There’s not much Apple can do to give developers access to the hardware short of providing a “real” environment to develop in, i.e. Cocoa. It would be great to be able to write applications for hardware like GPS receivers, or to write network utilities that require sockets, such as SSH clients.

The ability to run applications offline isn’t as important if we always have access to the EDGE network. It would be nice for on airplanes, etc though.

But to satisfy us until Apple gives us an Objective-C API (you ARE working on that…right Apple?), there’s a few things they could to do fix the third issue.

JavaScript is a very capable programming language, there’s not much you can’t do given the right APIs. The iPhone needs the following things to make these web apps seems more like native iPhone apps:

– Shortcut icons on the home screen. Give us one click access to our apps.
– Native looking UI widgets. At least give developers graphics for the standard buttons, menus, text boxes, lists, etc.
– Full screen. No reason to have a URL bar and browser controls for our own applications.
– More JavaScript events. We have click events… and that’s about it. Give us cool multitouch events like pinch and double tap. Let us redefine them to suit our own applications.

Given these things, iPhone web apps would be acceptable, at least for now.

Road Trip

A couple weeks ago I went on a little road trip. And by little I mean almost 2000 miles. I needed to drive my car from Seattle to Los Angeles, and since I was awarded a student scholarship to attend Apple’s [WWDC 2007](http://developer.apple.com/wwdc/) conference in San Francisco I figured why not save a trip and drive to San Francisco.

I recently bought an [iGo](http://www.igo.com/) wall/auto/airplane power adapter for my laptop and decided to actually use it by recording my entire trip on my PowerBook, timelapse style. Here’s the result:

Driving through most of Washington, Oregon, and California really made me realize how much I like the west coast, and within the west coast how much I like California, and within California how much I like the Bay Area.

Saturday, I departed from Seattle. It rained the entire day. I made it to Medford, at the southern end of Oregon, and stayed in a cheap motel (that had the only thing that matters: WiFi!)

Sunday, I continued through Oregon and California. Ironically (or not), nearly the moment I crossed the border into California the clouds disappeared (to be fair, the weather in Washington and Oregon was supposedly nicer on Sunday too).

After a nice drive through Northern California I arrived in the Bay Area, and the tourist in me kicked in (even though I lived there for 9 years). I drove over the Golden Gate bridge (via the Richmond-San Rafael and Carquinez Bridges) and down Lombard Street before stopping by the Moscone Center to pick up my WWDC badge. Eventually I made it to Ross and Francisco’s nice apartment in Cupertino.

After a few days in the Bay Area at WWDC I continued on to Los Angeles Thursday morning. The first few hours of the SF-to-LA drive were nice, until it started warming up. For entire trip until this point (except during the rainy parts) I had my windows down and sunroof open… no airconditioning. Unfortunately my airconditioning has been broken for a few years, but being in Seattle one rarely needs it, so I never bothered to fix it…

After a couple nights in LA I continued on to San Deigo to visit Anne and complete my west coast journey.

Warped Tour – Ventura (and my first iPhone camera photos)

I drove out to Ventura on Saturday to see my friend Jon who is on the Warped Tour doing some promotion for Capitol Records and [absolutepunk.net](http://www.absolutepunk.net). The drive there was ridiculous… about 3 hours from Los Angeles to Ventura (only about 60 miles), as was parking (I ended up parking a mile away and walking) but I got there just in time to see one of my favorite bands from my high school days, [The Matches](http://www.thematches.com/). Last time I saw them was two years ago on the same stage at Warped Tour, which was cool. I also saw New Found Glory and Bad Religion, which were both great.

I also got a chance to test out (and show off) my iPhone. It was great for getting directions, figuring out where the hell I was, checking out traffic (which as I mentioned, was awful), and taking photos…

Here are a few photos from the day:









As you can see, the iPhone camera is quite good for a cell phone. The resolution isn’t high (2 megapixels), but it’s perfectly fine for photos destined for the web.

At first I took mostly portrait oriented photos, even when landscape would have been better. Once I realized I could take landscape photos I switched, although it was a little awkward holding the camera in landscape orientation without covering the lens.

I assumed iTunes would somehow transfer photos I took on the iPhone back to my computer, but it does not. To do that, you must use an application like iPhoto, Graphic Converter, or the free Image Capture application included with Mac OS X.

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 empegbbs.com forum member have also posted crash logs, from [MobileMail](http://daringfireball.net/misc/2007/06/MobileMail-2007-06-29-204206.crash), [Preferences](http://www.martingordon.org/public/Preferences-2007-06-29-202724.crash), and [MobilePhone](http://empegbbs.com/ubbthreads/showflat.php?Cat=0&Board=offtopic&Number=301021) 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](http://iphone.fiveforty.net/wiki/index.php?title=SystemFileAndDirectoryList) 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.