Getting Root on Philips Hue Bridge 2.0

This post will briefly show you how to get a root console on the new Philips Hue Bridges (the square ones). It’s rather easy, the only special tools you require are a USB-Serial cable & a torx screwdriver.

P1080978

There’s a video with full details, this post is just the specifics if you don’t want a very boring walk-through:

  1. For the serial cable (a standard 3.3V type one, DO NOT use a 5V cable), there is a 6-pin header along the bottom. Pin ‘1’ has a square footprint, and counting from pin 1 the connections are:
    Pin 1 = GND
    Pin 4 = RX In (connect to TX Out of your serial cable)
    Pin 5 = TX Out (connect to RX in of your serial cable).

    P1080980

  2. The bottom left-corner of the 2-row header is GND. You’ll have to short that with a wire to the following test point:

    P1080981
    This test-point is shorted to GND with a paper-clip or wire. Click image for full-sized to see in better detail.
  3. To get the system working, check you are getting boot messages. Now, restart the system and after you get a bit of output, short the pin. You might see some output like this:
    U-Boot 1.1.4 (Sep  8 2015 - 04:08:21)
    
    bsb002 - Honey Bee 2.0DRAM:  
    sri
    Honey Bee 2.0
    ath_ddr_initial_config(195): (16bit) ddr2 init
    tap = 0x00000003
    Tap (low, high) = (0x8, 0x22)
    Tap values = (0x15, 0x15, 0x15, 0x15)
    64 MB
    Top of RAM usable for U-Boot at: 84000000
    Reserving 214k for U-Boot at: 83fc8000
    Reserving 192k for malloc() at: 83f98000
    Reserving 44 Bytes for Board Info at: 83f97fd4
    Reserving 36 Bytes for Global Data at: 83f97fb0
    Reserving 128k for boot params() at: 83f77fb0
    Stack Pointer at: 83f77f98
    Now running in RAM - U-Boot at: 83fc8000
    Flash Manuf Id 0xc8, DeviceId0 0x40, DeviceId1 0x13
    flash size 0MB, sector count = 8
    Flash: 512 kB
    *** Warning *** : PCIe WLAN Module not found !!!
    In:    serial
    Out:   serial
    Err:   serial
    Net:   ath_gmac_enet_initialize...
    Fetching MAC Address from 0x83febe80
    Fetching MAC Address from 0x83febe80
    ath_gmac_enet_initialize: reset mask:c02200 
    Scorpion ---->S27 PHY*
    S27 reg init
    : cfg1 0x800c0000 cfg2 0x7114
    eth0: 00:03:7f:11:20:ce
    athrs27_phy_setup ATHR_PHY_CONTROL 4 :1000
    athrs27_phy_setup ATHR_PHY_SPEC_STAUS 4 :10

    Which will then fall back to a prompt:

    ath>

    Good news! We can now get everything working for you. You can print the existing variables if you wish:

    ath> printenv
  4. Set a boot delay such we can enter the menu without the boot hack:
    setenv bootdelay 3

    Check it works with

    printenv bootdelay

    and confirm you get a line like this:

    bootdelay=3

    Finally, save the setting with:

    saveenv

    You can now reset the system (use the ‘reset’ command), and confirm there is a count-down that gives you time to hit “enter” and get this prompt again.

  5. Now let’s fix the root password. Before doing this, I suggest you keep a copy of the old value:
    printenv security

    This would let you restore things back to default. Then the following will set the root password to ‘toor’:

    setenv security '$1$3vGNd7Q3$ISqFeo1VkmQV6nyriUV0V/'

    You may have to copy this into notepad first to ensure it all fits on one line! The quotes are critical here. Again check it works with printenv, then type saveenv to store things to disk.

    If you want your own password, simply use the ‘mkpasswd’ command in Linux to generate an appropriate string.

    NOTE: My original instructions (and the video) had a different ‘setenv’ command, which used SHA1 to hash the password. It turns out this stops ssh from working, so instead as suggested in the comments you can use the above MD5 hash which should work better. For posterity my original instructions were:

    setenv security '$5$wbgtEC1iF$ugIfQUoE7SNg4mplDI/7xdfLC7jXoMAkupeMsm10hY9'
  6. Once again reset the board – assuming you used saveenv, that root password will be used by the system now. You should be able to log in with root/toor!
  7. Once you are in, there’s a few changes you’ll want to make. We’ll edit the file /etc/rc.local:
    # vi /etc/rc.local

    And add the following:

    iptables -I INPUT -p tcp --dport 23 --syn -j ACCEPT
    telnetd

    This will open the telnet port & start the daemon on boot. Write the file and quit with :wq. You may also want to add the /etc/rc.local to the /etc/sysupgrade.conf file to avoid it being overwritten in the future.

    See the comments below – someone found a way to get ‘dropbear’ to allow root login too. It’s great as SSH is much nicer to work with than telnet! This requires a different password hash than my original instructions/video.

  8. Try using telnet to connect now. You can find the IP of the bridge using ifconfig, but you can also get it through the Hue app.You can also try using “Philips-hue.local”, which I’d first check via ping to see if it resolves:
    ping Philips-hue.local
  9. I’ve done the 25-July-2016 update without issue too (after first rooting the hub with an earlier version). I’ll continue to update this as updates happen.

BONUS – How did I figure this out?

The “bomb out to uboot prompt” is a known bug. Once in the prompt, I could edit the bootarg command with this:

setenv std_bootargs 'board=BSB002 console=ttyS0,115200 ubi.mtd=overlay rootfs=/dev/mtdblock:rootfs rootfstype=squashfs noinitrd init=/bin/sh';

This gives me a shell which doesn’t require a login. But many things are broken/disabled in this mode. It was however enough to find that there is another script that runs on startup which uses the uboot env variable, and copies it into the shadow file for the root password.

With this knowledge it’s easy to use mkpasswd to make an appropriate shadow file entry. Easy!

I also checked with two different Hue Bridge v2.0 devices. They contained different root passwords (at least different salts). I’ve been told the root passwords are indeed unique per device, which is a good step to stop someone from attacking your virgin Philips Hue 2.0 bridge.

As an interesting note – other people have also discovered this independently of me. Between writing this post & actually linking it from anywhere (i.e., so you could actually find it) pepe2k figured out the same thing on a forum post.

As well someone else did this same “overwrite root” attack already, but had used an external programmer to write the FLASH memory chip:

So it’s worth considering that many devices may be broken even if there isn’t some fancy Black Hat talk or otherwise. Most of the attacks (such as this one) are fairly well-known and pretty basic.

UPDATE: At DEFCON 24, I guess someone gave this type of attack a marketable name. You can see the idea called pin2pwn here.

13 thoughts on “Getting Root on Philips Hue Bridge 2.0”

  1. Dropper doesn’t work because the config file doesn’t contain the setting to allow root to login:

    vim /etc/config/dropbear
    option RootLogin ‘1’
    :wq

    Don’t forget to add that file into the /etc/sysupgrade.conf

    1. Excellent thanks! Will add a note to the article, for some reason I thought I tried the dropbear config but must have had wrong option.

  2. Is the method to root the Hue-Bridge still working? I have a new hardware version (2.1). There are some messages when I power up the device, but then it stops (and hang up?). The last message is “Stack Pointer at: 80xxxxx”.
    Any idea?

  3. It is still working. The problem was that the RX-line of my RS232 device was pulled up to 3.3V. I tried a diffrend device where the RX-line wasn´t pulled up and I was able to root the device. Thx!

    1. Maksimo, which PCB test point did you use for 2.1 hack? As I look on the PCB, there is no test point in the corner of of the chip. There is one bit further down towards smaller chip (the one with 8 legs). Is this the one to be used?

  4. I got dropbear to work when using md5 hashed passwords instead of sha-256. I read somewhere that uClibc, which is used by dropbear doesn’t include sha-256 and sha-512.

    To summarize:
    – I was able to get root on Bridge 2.1 with the above instructions
    – To get dropbear you need to add below line to /etc/rc.local
    iptables -I INPUT -p tcp –dport 23 –syn -j ACCEPT
    – and add below line to /etc/config/dropbear
    option RootLogin ‘1’
    – and generate md5 hashed password with mkpasswd rather than sha-256. Example password for ‘toor’ is:
    setenv security ‘$1$3vGNd7Q3$ISqFeo1VkmQV6nyriUV0V/’

    Thank you Colin for great video and images.

    1. Awesome – hadn’t seen all the additional work people have been doing, very cool to see fun usages of rooting 🙂

  5. Hi, thanks for this.
    Originally I stumbled across the article on “enabling Wifi in Hue” that lead me here. I searched on, because I had a v2.1 board, and the instructions/pics were only for v2.0.
    Unfortunately I didn’t take any pictures, but thought I’d share what I gathered none-the-less.
    The layout has changed a bit, and I’m sure they dropped a bunch of “extra” components in that update. But the SOC and flash are still the same, and in the same place. If you hold the board in the right angle, you can also see (faintly) the zig-zag-lined “connection” between them slightly of to the right of the smaller bottom IC (flash).
    And really faintly also that single connection to the TP/Flash. So the actual TP is slightly lower and off to the right compared to the 2.0 layout. I’m not sure why, but as I started, I had the impression that part of the serial was being fed through the GND/RX/TX line and therefore it kinda stuck. Power off device, pull serial, power on, replug serial and then short TP ended me in a shell with some nasty “checksum” error. So it worked, but can’t guarantee it was the “proper” way (i.e. foolproof as to impossible to do some damage if shorted longer or whatnot).
    I didn’t quite get all this business on what kind of password hash to use – “mkpasswd -m SHA-256” on Rasp with jessie worked fine for me.
    A bit more headache was the ssh (-key) business.
    “echo ‘[PUBKEY]’ | ssh-factory-key -r – ” seemed to work (it also opens FW, if not done so already). But putting it all back together and booting with eth-cable, ssh -i mykey root@hue came up with something like “remote agents admitted to fail to read/sign key” or something strange like that.
    Hmm – bummer. Back to open that box, hook up serial and start screen.
    Dropbear has a tool to create a key – dropbearkey – used it to create one on the box. Echo’d its public part to ssh-factory-key and it worked (it stored the key alright). Checked option in /etc/dropbear – all fine. Now cat private keyfile, to C&P on my desktop – ouch – that bugger’s binary!
    Hmmm… Being stuck in a serial terminal and a binary key is nasty, but it turns out, that they were actually quite generous with tools and such. I’ve been in a lot worse busy boxes – “vim” was a nice surprise, but really cool was “hexdump” 😀
    No – I didn’t dump it and re-assemble on the other end via hexdump, but it was useful in checking on both ends if the transfer worked.
    What I did was use “openssl enc -e -a ” – ascii armored “null” encryption if you like. Gives nice formatted block of C&P’ble Ascii and then on my desktop “openssl enc -d -a” reverts it back to binary.
    Haha – thought that was it, well it wasn’t. The ascii didn’t go into an ssh-key and neither would (open-)ssh read the binary form – kept asking me for a password ;). But there’s a tool that comes with dropbear “/usr/lib/dropbear/dropbearconvert ” (again I found this on my Rasp-3-Jessie) – it’s a bit clumsy, but converts the Hue-generated (did I mention it took forever to create it?) key into a standard openssh-ascii format.
    Now, piece it all back together, fire up on LAN and – voila – it worked. Logged out and wanted to go back in – dammit, that strange “remote agent admits…” error again. Hmm, retry – same error – retry – Bingo!
    So, seems like the original C&P may have worked – just that the hardware on the HUE (and probably software as well) isn’t fast enough to use good encryption (my original key was 2048 bit…). Just try it a few times, and you’ll get in (as long as it’s this “remote agent admits to ….” error at least).

  6. Great work !
    I noticed that the interaction with the bridge en online platform (my.meethue.com) seems to stop when using a different root password. I seems to be that the securitystring (hashed password) in the environment is used for online authentication.
    When i restored the original value it was working again.

    In the end, i created a new useraccount and gave it root permissions.

Leave a Reply

Your email address will not be published. Required fields are marked *