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.
There’s a video with full details, this post is just the specifics if you don’t want a very boring walk-through:
- 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).
- 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:
This test-point is shorted to GND with a paper-clip or wire. Click image for full-sized to see in better detail. - 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
- 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.
- 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'
- 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!
- 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.
- 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
- 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:
@colinoflynn Nice! I broke into mine by modifying the u-boot env in flash (before first turning it on). I’m guessing your way in was cooler?
— Kyle Temkin (@ktemkin) July 15, 2016
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.
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
oh and you have to allow it in iptables
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.
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?
Huh – haven’t seen the newer HW version. Perhaps they added a check to try and avoid this attack?
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!
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?
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.
Thanks! I used it to finally push the link button from software 🙂 https://github.com/Tristan79/HUEHack
Awesome – hadn’t seen all the additional work people have been doing, very cool to see fun usages of rooting 🙂
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).
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.
Hi Mr. Flynn!
i’m in the process of rooting my bridge, bootdelay and new security set but as soon as i reach the login prompt and enter “root/toor” as username/password, it randomly garbles a few characters causing the login to fail. I already power cycled a few times, tried typing *very* slowly – still garbled. The output before isn’t at all garbled and also in the u-boot prompt all characters get transmitted and received nicely. I now suspect the settings of serial connection, will try that next.
Did you set any special settings in Putty regarding characters and/or serial connections?
Hi Max,
I am having the exact same issue. Have you managed to sort it our somehow?
Thanks,
Pete
Hi Max,
I am having the exact same issue.. Have you managed to find a solution?
Thanks,
Pete
I tried this with the 2.1 bridge and your guide is correct except for the UART pins being switched and the bridge not booting with the UART pins connected. I was able to get boot output to time the corruption by doing a factory reset which resets the bridge and works with UART connected. This gives me the “ath>” but when I press enter I get no response and no further “ath>”. It doesn’t seem to respond to anything. Any ideas?
Okay, by timing my corruption better I can get a functioning uboot shell, but it won’t accept any multi-letter commands. The only one I could get to work was ?. Not even help would work.
Sounds like maybe hardware issues? Hard to say… is there a bad connection on the GND or UART pins?
Great post! I was actually hoping to gain root access to the Hue in order to flash it with a custom build of OpenWRT. I’m completely new to working with OpenWRT, however, so I’m having issues finding the right kind of build and the right way to flash the firmware. Do you have any recommendations?
if you edit /usr/sbin/ipbridge in hexa and you modify the string eth1 to wlan0 and you use hue esentials app and look for the bridge on the IP, you can control the damn lights.
Also, completly disable eth0 from the configuration.
For V2.1 use short the NAND’s DO signal to GND instead of the test point that was mentioned.
http://www.winbond.com.tw/resource-files/w25n01gv%20revg%20032116.pdf – page 7
Eli,
On my 2.1 board, the SU9 chip has the following markings:
FP1649
5F 1GQ UCY1G (not 100% sure I read the 1 or I correctly)
HA6824
and I’m having proble identifying the pins. How did you come to the conclusion that the chip is W25N01GV?
Thanks,
Andrei
And a nice video of Hue Bridge running on WiFi controled by Siri.
https://www.youtube.com/watch?v=b2mxu-G_3zk
In the latest firmware opkg isnt included anymore. Does someone know how to install it again?
Thanks!
You need to download the opkg ipk that goes with the openwrt release of your bridge and extract it manually to the device
Hi,
I try to root my hue bridge that i buy specially for trying to understand how remote api works as i create a hue emulator script and all futures based on remote api are not working. When i connect the serial adapter with indicated pins i get just some characters on power on, but then no debug logs are displayed. I reverse TX/RX pins but no luck. Baud rate was set to 115200 like in the video. I tried to create that shortcut after 5-6 seconds on boot, thinking that they only disable the debug messages, but i did not manage to enter in uboot menu. Any idea if they fixed this root method and currently is not possible to perform the hack?
Hello Marius am kind facing the same issue although for me. it worked and got root shell. however now when i try to connect it back i only get those giblish letters too. how did you go over it?
This sounds like you might have the wrong kind of USB-Serial adapter. I had similar issues using what turned out to be a non-genuine Prolific USB adapter. I switched to using a FT232RL and all worked fine for me!
Hej,
It’s been fun learning from this tutorial.
Everything was working, I thought, tried with the new instructions to enable ssh and manged to ssh locally root@127.0.0.1 while the serial console cable was still connected and it worked.
Well I put it all back together and can’t telnet or ssh into my hue over the network. FING (nmap) for android does not show ssh or telnet as running, when I scan ports only http & https services are shown.
Guess I should get it off the wall opened again and plug in the serial console cable again 🙂
Thanks again
Graham
Hi, tried to root my bridge and after reading out the default pass I give the bridge a reset and now:
47.070000] SQUASHFS error: Unable to read fragment cache entry [54781a]
[ 47.080000] SQUASHFS error: Unable to read page, block 54781a, size 13298
[ 47.470000] SQUASHFS error: xz decompression failed, data probably corrupt
[ 47.480000] SQUASHFS error: squashfs_read_data failed to read block 0x3f613a
[ 47.570000] SQUASHFS error: xz decompression failed, data probably corrupt
[ 47.570000] SQUASHFS error: squashfs_read_data failed to read block 0x3f613a
[ 48.980000] SQUASHFS error: xz decompression failed, data probably corrupt
[ 48.980000] SQUASHFS error: squashfs_read_data failed to read block 0x571a3e
Any Idea??
I was given a v2.1 bridge that failed to connect with hue app. It kept resetting itself.
So i connected RX/TX and reached saw same error as you experianced:
Zigbee SoC up to date: 6.73.0.37983
[ 31.597785] SQUASHFS error: xz decompression failed, data probably corrupt
[ 31.604932] SQUASHFS error: squashfs_read_data failed to read block 0x7e39ce
I was able to get SSH access and can probe around in the files for about 5 min then it resets again
[ 289.065971] SQUASHFS error: squashfs_read_data failed to read block 0x7e39ce
[ 291.142991] eth1: link down
Jul 30 21:41:19 mDNSResponder: mDNS_FinalExit failed to send goodbye for: 00B21924 01 38 _hue._tcp.local. PTR Philips\032Hue\032-\03283613A._hue._tcp.local.
Jul 30 21:41:19 mDNSResponder: mDNS_FinalExit failed to send goodbye for: 00B23414 01 38 _hap._tcp.local. PTR Philips\032hue\032-\03283613A._hap._tcp.local.
[ 294.972527] reboot: Restarting system
Just a guess that its a botched firmware upgrade. Any ideas what I could check?
Hi,
By any chance… did anyone got the JTAG working?
I thought to add 0ohm resistors/jumpers where needed near the 14-pins header… but can’t find the right TMS/TCK/TDI/TDO… :/
Huge THANK YOU for your research!!
I used it assign new functions to my dimmer switch (i.e. using it as a squeezebox remote) w/o having to poll the hue API 🙂
Hi,
fantastic intructions.. I used an ethernet/ttl adapter but same results.. thankyou very much.
I am trying to make the timezone auto update as I am on a ship.. however the uClibc TZ file doesnt seem to have any effect on the hues timezone.. do you happen to know where that is to be found? I have searched the dirs and found no clues as yet.
thanks again JP
i did enable telnet like you said but it seems the device resets itself on boot to default settings i edited /etc/rc.local and /etc/sysupgrade.conf
after i rebooted the system they were back to normal i did save the files but it seems the hue resets the filesystem so every file i change won’t save anyway
Great article, congrats!.
Is HUE rooted hub able to act as zigbee coordinator for other devices?, I’m looking for coordinator by hacking HUE hub, rather than buy another one. I have aqara door sensor, which is not compatible with Philips.
Do you kow if it is possible?
Thank you.
I received a defective hue bridge v2.1 (app not connecting)
Connected the RX/TX and saw below:
Zigbee SoC up to date: 6.73.0.37983
[ 31.597785] SQUASHFS error: xz decompression failed, data probably corrupt
[ 31.604932] SQUASHFS error: squashfs_read_data failed to read block 0x7e39ce
I was able to get SSH access and can probe around in the files for about 5 min then it resets again
[ 289.065971] SQUASHFS error: squashfs_read_data failed to read block 0x7e39ce
[ 291.142991] eth1: link down
Jul 30 21:41:19 mDNSResponder: mDNS_FinalExit failed to send goodbye for: 00B21924 01 38 _hue._tcp.local. PTR Philips\032Hue\032-\03283613A._hue._tcp.local.
Jul 30 21:41:19 mDNSResponder: mDNS_FinalExit failed to send goodbye for: 00B23414 01 38 _hap._tcp.local. PTR Philips\032hue\032-\03283613A._hap._tcp.local.
[ 294.972527] reboot: Restarting system
Im guessing all this is caused by botched FW upgrade? Any ideas what I could check or do to bring it back to life?
Just leaving this here for anyone facing a similar problem:
I powered up my device after having had it disconnected for a year and everything worked. Power cycled and then nothing… I just got the first LED to light up but could not connect. Weird thing was that I could ping the device. If this happens to you too then follow the guide to get the ath> prompt and run:
setenv bootslot 1
saveenv
reset
This should work, but I got the error “Bad Magic Number” and a boot hang. A simple power cycle and my Hue was back again!
I then updated my Hue app in the playstore, fired the Hue app up and it connected to the Hue again 🙂 I ran a firmware update from the app (I don’t care to much about loosing WiFi-possibilities) and I can now see that I am back at bootslot 0.
Thanks for the guide!
Hi,
Great video! At the moment i am conducting research if it is possible to extract the Hue bridge firmware to reverse engineer it for a study assignment. Is this possible after rooting the bridge?
Thanks in advance!
Kind regards
“setenv std_bootargs ‘board=BSB002 console=ttyS0,115200 ubi.mtd=overlay rootfs=/dev/mtdblock:rootfs rootfstype=squashfs noinitrd init=/bin/sh’;” Philips Hue did not work after throwing this code how can I fix it
Hi,
“setenv std_bootargs ‘board=BSB002 console=ttyS0,115200 ubi.mtd=overlay rootfs=/dev/mtdblock:rootfs rootfstype=squashfs noinitrd init=/bin/sh’;”
hue is not working after i write this code. How can I fix?
and_bootargs should be like this:
setenv std_bootargs “board=BSB002 console=ttyS0,115200 ubi.mtd=overlay rootfs=/dev/mtdblock:rootfs rootfstype=squashfs noinitrd init=/sbin/init”
can i change the timezone on the hue from ssh?
thanks
J
My Bridge won’t let me to login after fool boot. It shows “Please press Enter to activate this console.” only. If I interrupt the boot on very beginning (4..3..2..) and continue to boot via “boot” command – still can’t login after. Also there is no “ls”, “cat”, “vi” commands available anyway. What is that? Latest updates from Philips or something wrong with my Bridge? It reboots (flashing all leds and Hue App reconnecting every 3-5 minutes). No any errors in serial console.
Any advice? I’ve tried factory reset (button method) – no result. Can’t find the script mentioned somewhere about software factory reset – please let me known if any available.
I had this recently. The solution for me was to “setenv bootslot 0” and then “saveenv”