skip to main bit
a man slumped on his desk, from 'The Sleep of Reason Produces



the T-Mobile G1 — nice phone, but not totally open

So I caved and got a T-Mobile G1 phone today. I have to say, despite the reviews claiming it is not quite 1.0, I’ve been having an awful lot of fun with it. At the very least, getting it to sync with the music on my Linux machine, and then being able to set my ringtones to one of those tracks without paying through the nose was a lovely relief. For me, it’s already proven much more flexible than an iPhone could.

My hopes of managing to finally being able to own a truly open phone, as controllable and configurable as a PC, and able to run whatever code I could throw at it, have been rather dashed however. It’s absolutely true that you can run any code you’ve written to Android’s Java-like virtual machine, which is sandboxed away from the real hardware. But exploring and executing code at a lower level on the G1 isn’t currently so free and easy.

I got a chance to peer around the phone using the Android SDK’s android debugger bridge (adb) utility. It quickly became clear that even Android developers can only access a relatively restricted part of their own phone: more than given to normal Android apps, but far less than you’d expect to have as “root” on a Linux system. You can only explore or create files as the “shell” user. Much of the filesystem is owned by root, which means there’s a lot of the filing system that’s closed off from user access. There’s no official documentation on the bootloader for running your own root-level code, or flashing your own kernel.

So, as is so often the case, those who want to use their own code on their own phone will have to wait until somebody comes up with some privilege escalation flaw or undocumented flash utility to take control.

Of course, bright minds are at work on doing just that. Overheard in the excellent #android @ IRC channel:

<RyeBrye> I hacked my camera’s firmware manually by using an exploit to cause it to execute arbitrary code – and then blinking out the entire firmware in 0’s and 1’s on the autofocus LED – read in by a photo transistor attached to a sound cable plugged into my microphone port – and then put back into 0’s and 1’s…
<– jbq_ has quit (Read error: 110 (Connection timed out))
<RyeBrye> Then disassembled the ARM9 code in it and worked on porting CHDK to it…
* waldo_ is away: auto-away
<RyeBrye> I’m pretty sure having a whole OS at my disposal should make this a lot easier

I sense that the people behind Android at Google would like its flagship device to more open than it is. It’s certainly sad that for now the iPhone pwnage exploits really do give you root on your device, while Android’s official SDK offer no such thing — making the Apple’s theoretically closed phone more practically open than Google’s theoretically open game-changer.

20 Responses to “the T-Mobile G1 — nice phone, but not totally open”

  1. Andrew Brown Says:

    You never write; you never call; you leave me off your blogroll — and then you come up with something as grotesquely NTK-worthy as this. Thanks.

  2. Kragen Javier Sitaker Says:

    How frustrating. Do you think the LGPL permits the use of LGPL code in this context? I recall users have to be allowed to upgrade their LGPL libraries.

  3. James Says:

    So as an OpenMoko user I laugh at you. Of course, the OpenMoko software is just barely functional, but that’s ok because the FreeRunner is my first phone.

  4. Al Says:

    Let me get this straight. This guy hacks the phone to blink out the camera firmware in 1’s and 0’s which he hooked up to a photo transistor which interprets the ‘blinks’. This was then disassembled back into something more readable. Does the ARM9 not have variable instruction lengths? How can you interpret the stream of 1’s and 0’s in a consistent manner with variable instruction lengths? This sounds like complete bullshit to me.

  5. Jeff Says:

    Al; I seem to recall someone did something similar with the iPod firmware years ago when there was a fairly serious attempt to put linux on it.

    Ah-hah, couple minutes of googling:

  6. jaggedaloc Says:

    @ Al:
    I don’t know that it sounds like complete bullshit. It’s kinda’ like how I understand the iPod firmware was first broken by the iPodLinux crew, ‘cept they used to click-click sound iPods make.

  7. Mark Murphy Says:

    There are two tiers of Android development.

    You can download the whole OS, down to the Linux kernel, from You can change it to your heart’s content and, AFAIK, repackage it as firmware to load in an emulator or device. The catch is you have to distribute it *as firmware*, so this is mostly for modders, device makers, and open source developers looking to advance the platform.

    Or you can work within the SDK. This allows you to create apps that run on the G1 and on future Android devices. You can even download such applications from Web sites for installation — no iPhone-esque command-and-control structure required. However, the SDK is an environment for *apps*, not wholesale changes to the device, and so there are limits as to what you can do.

  8. John Says:

    I sense that the people behind Android at Google would like its flagship device to more open than it is. It’s certainly sad that for now the iPhone pwnage exploits really do give you root on your device, while Android’s official SDK offer no such thing — making the Apple’s theoretically closed phone more practically open than Google’s theoretically open game-changer.

    You might want to note the pwnage software IS an exploit, which is what you are talking about. However, Apples iPhone SDK is very much way more restrictive than the Android SDK. So the last statement is really bad logic.


  9. Danny O'Brien Says:

    John –

    Well, that’s the point. Right now we’re in the situation where if you want to write your own system level code through “official channels” on either the iPhone or the G1, you’re out of luck. If you are willing to crack the phone, you’re better off right now buying an iPhone, because their exploits are further along. That strikes me as a little ironic.

  10. Danny O'Brien Says:

    Mark –

    That’s true. Unfortunately, there’s no route to install your firmware on your own device if you bought a G1. You can create a G1 build (as I said in the article) — you just can’t use it on a new G1.

  11. Guy Says:

    @Al (and other skeptics):

    “blinking the firmware” is not complete bullshit.
    I think its very cool hack, and its how the firmware is
    dumped from a lot of canon compact cameras to allow CHDK porting.

    Here is a page on the CHDK wiki describing the process

  12. balrog-kun Says:

    Al: as Guy noted, this irc quote is talking about the Canon cameras, not the phone. And it’s not complete bullshit – you basically can transfer a program in 0’a and 1’s through blinking same way you transfer any file. ARM instructions happen to be constant length (as opposed to x86) but that doesn’t matter at all because they are transferred just as a stream of data, say, like an mp3. They only become instructions once they run on a cpu or are being disassembled.

  13. Kragen Javier Sitaker Says:

    I think ARM Thumb-2 instructions can be either 16 or 32 bits, and of course recent ARMs in general can execute code in either ARM mode (where the instructions are 32 bits) or Thumb mode (where the instructions are 16 bits). So yeah, there’s some ambiguity.

    But ambiguity doesn’t make disassembly into rocket science. People manage to disassemble x86 code, and in x86 code the instructions can be 1, 2, 3, 4, 5, or 6 bytes. (Maybe they can be longer? I don’t know.) You use heuristics (hey, I have a whole bunch of and %ah, (%eax) instructions in a row; maybe I’m accidentally disassembling text? I have a whole bunch of add %al, (%eax) instructions; maybe I’m accidentally disassembling a block of zeroes? Are there really port-input and output instructions in the middle of this user program that runs under an operating system, did I accidentally stumble into a device driver, or am I misinterpreting this block? Why is there a jump into the middle of another instruction? Maybe this immediate constant here is actually a bunch of instructions? Maybe this block of instructions that contains an invalid opcode is actually not a block of instructions?) and you correct the disassembler if it gets it wrong.

    There are programs floating around that *deliberately* jump into the middle of an instruction, getting two interpretations out of a single block of instructions; but they’re relatively uncommon, and I’ve never heard of a compiler emitting one.

  14. Veg Says:

    Isn’t this just the same problem that the manufacturers of “MP3” players and DVD players have had in the past ? Technically they can do whatever they want, but the pressure from the MPAA/RIAA/BPI/AT&T/T-Mobile/etc/etc forces them to restrict what is “playable”. In reality, for anyone who gives a toss about such things, all of these restrictions are trivial to work around, and why should the the manufacturers care ? I give it less than a month before VoIP calls, a root shell, and native ARM code is running on my G1, and there’s no way that Google aren’t aware of that. They just had to do enough to satisfy their paymasters. If you’re waiting for a “truly free” platform, then go openmoko, and cry into your beer. Otherwise, jailbreak your iPhone, hack your G1 and put RockBox on your MP3 player.

  15. Kragen Javier Sitaker Says:

    …in short, it’s not bullshit. ☺

  16. Macky Says:

    Voip was available in the Android Market on the day of the release. The app is a skype compatible app.

  17. Miles Nordin Says:

    I’m prepared to be skeptical of Android’s openness because free software advocates have been tricked too many times in the past, but not based on this post.

    It is proper and desireable for the phone’s owner to have more control over it than application developers. If this is really and thoroughly true of G1, it’s a big selling point. I currently suggest most people stay the hell away from smart” phones or anything that supports installing” stuff because of:

    To me, openness does not mean application developers get to take over the entire phone, user be damned, like EnTee systems where legitimate programs and viruses install themselves in approximately the same way and there’s no such thing as a perfect uninstaller. I wouldn’t want the phone to act like ActiveX controls run as Administrator. Giving YOU total control of MY phone is not part of my idea of freedom.

    The development cycle for firmware upgrades should be documented, though. That’s a fair gripe.

    Do you think it is more open or less open than an N810?

  18. Miles Nordin Says:

    oh, maybe I misunderstood. The platform is TiVo-ized, so GPLv3 is needed to free it? or is what’s needed merely to RTFS of the boot loader and write documentation from it?

  19. Danny O'Brien Says:

    So, as I understand it currently, the problem is that everything is open source and fairly well documented, except the path for installing a compiled kernel onto the G1 itself (I wasn’t talking about the Dalvik application environment, which as you say is sandboxed in a way that’s pretty sensible).

    Is the G1 actually Tivo-ized, so you need a signed kernel to upgrade? Or is it just that the firmware upgrade path isn’t documented yet? The impression I got from IRC conversations with Google folk was that the bootloader was HTC’s work, and that it’s outside of the Android system, and if you want to install your own kernel, you should wait until somebody does a “developer” phone. That implies that it’s not going to be documented, at the very least.

    There is code to see and install procedures to mull over though — see;a=tree;hb=HEAD and;a=tree;h=refs/heads/master;hb=master .

    Mainly, though, at this point I’m just annoyed I can’t get root on my own phone in a simple way.

  20. Kragen Javier Sitaker Says: says:

    Let’s you run commands and view the result.

    Try things like:

    top -n 1



petit disclaimer:
My employer has enough opinions of its own, without having to have mine too.