Introduction
I was always fascinated by the pwn2own competition - an elite hacking competition where hackers from all over the world compete against time and the most patched and unto dated systems, software’s, devices and products etc. The concept of pwn2own started back in 2007 as - if you hack this laptop then it is yours - pwn to own. Now this elite competition has evolved into a very sick hacking competition (it already was) with hacks on real patched systems with a lot of money being awarded. Hence, I decided to try my luck - even if i do not succeed i will probably learn a lot of stuff on the way and get a glimpse into this world. Professionally, my day job is to hack embedded control units and help my company stay a little more secure than it was yesterday, therefore, i thought maybe i can apply the same skills i have on this target. I have worked on a lot of different systems as a developer, leader and a hacker in my career, so picking up something new meant connecting different points in time from my work experiences from the past and apply them at once.
What is Pwn2Own ?
The pwn2own competition is managed by ZDI which is part of Trendmicro, and ZDI puts up a blog post and rules of the upcoming event 3 months in advance about which targets are in scope and what the rules of engagement and win are. e.g.https://www.zerodayinitiative.com/Pwn2OwnIreland2025Rules.html In my case i decided to try the Pwn2Own Ireland 2025 as it now focuses on products (embedded products), there are separate pwn2own's for enterprise, ICS/OT, automotive but this one focus more on devices like home automation, speakers, phones, printers, routers etc.
The very first thing is to check how much money you want to spend on a target, as you need to purchase the target device so if you were to participate in the competition and want to attempt to hack an iPhone, then you gotta have the iphone, which costs quite some money - same principle applies to other devices also. So, i decided to purchase the Philips Hue Bridge Device, as that was the cheapest one on Amazon Germany, just around 43 euros. Other targets cost a lot of money.
Things to Consider:
Timeline:
As soon as the targets are announced by ZDI, you have relatively less time, to finalize a target - the more experienced & l33t researchers like the Summoning Team or Synaktiv or PCA Cybersecurity or others who have repeatedly cracked many devices on stage, probably buy most of the targets immediately and then work on them in various teams or as individuals. But for inexperienced pwn2own participants like me, i took 2 weeks to decide on a target and my buying decision was purely based on price a device would cost. Once you order the device, and if you are in Europe or the US, it probably takes really less time, as most of the devices in Pwn2Own will be available to ship immediately, but in some countries like India or other SE countries, its really hard to get some of the targets as they are not available locally but have to be ordered or imported from country outside. This costs time, which is precious as the since the date of announcement of the competition targets, participants have 3 months to research, find vulnerabilities and develop a working exploit on the target device in most cases remote code execution and the deliver on stage. So don't waste too much time in selecting a target. For targets like browsers or virtual boxes in other categories, they are readily available, but this is out of scope for this discussion.
Probability:
Lets say you find a bug and wrote an exploit on the most latest version that you have 1 month or 2 months before the competition date, and say the version is 1.1.1, as the competition comes closer, the vendor decides to send a patch, that kills your bug, or your exploit does'’t work at all due to some other factor you are not aware of that got introduced in the update, which means now you have even less time to find the bug and write/reworks your exploit before you take the stage if you will. Vendors will send and apply patches, till the last minute of the competition in order to kill the bugs and avoid paying the money in full. therefore, be advised and plan accordingly while considering these situations.
Defend your exploit code:
If you’ve ever heard of defensive programming, then in simple terms it means that considering almost every condition and failure scenario your code will move through and achieve what is supposed to. In a high stakes environment like pwn2own it could be possible that you tested your exploit on v1.1.1 but in the competition you got v1.1.2, the bug is still present but your exploit fails, due to a certain condition introduced in the new version, therefore pwn2own gives you 3 attempts on stage to fix your exploit code or something else - I’ve never been on the pwn2own stage so I don't know how stressful or easy it is to make it work if something goes wrong. Therefore, always write your exploit code considering these variations in target software versions, regional changes, environment difference etc.
pwn2own is a competition where if something has to go wrong, then it will go wrong so plan accordingly!
Basic Strategy
Now with that being said, let’s get back to our approach - Once we received our target, the first thing for us was to power it up and check its functionality:
Power Up - trivial (For automotive Grade devices, this is not so simple like plugging in and everything starts working)
Connect to Network via Ethernet - easy
Enable internet on the device - later
Create Hue Bridge app account - later
Register the device in the Hue app Account - later
Play around with full functions - later
There was a lot of stuff that I did in between. We moved a little carefully, such that we should be able to save a snapshot condition and logs on the device's boot up and its interaction with its network somewhere so that we might refer back to it in the future.
Philips, please disable your UART !!
Colin o Flynn article
After Following Colin’s article, even I had the boot delay set to 0, which means, there is no way to stop at u-boot to alter the security string. However, as shown in the article, if you short the SPI chip select logic to 0, then the u-boot driver fails to find the chip from where the kernel needs to be picked up and thus drops you to a nice u-boot shell. (Unfortunately, i do not have screenshot for this glitch) But this needs to be timed correctly, when you see the below on the console.
After trying a couple of times - I did it with my bare hands and a jumper cable.
From here it felt like the struggle is over to extract the firmware, but this was only the beginning.
All the methods previously shown to reset the security string from u-boot and then using that to login to the device did not work - as after booting it would drop you to a console which asks for some cryptographic key or passphrase before showing the login prompt, which I did not have. This seems to be introduced by Philips after learning about the previous attacks conducted by Colin and other researchers.
However, there is still another way. Kids Stuff !
Modifying the default boot parameters of the Hue Kernel Command line is still possible - and I could use this to drop into a bare shell.
std_bootargs=board=BSB002 console=ttyS0,115200 ubi.mtd=overlay rootfs=/dev/mtdblock:rootfs rootfstype=squashfs noinitrd init=/bin/sh
This is pretty common for embedded devices running Linux -- I used to do this all day long when I started my career so this was familiar territory.
So ideally once, you drop yourself to “/bin/sh” bare shell, you can basically run everything from the cli and dominate the device, but for me it was not that simple for this device.
I thought running /sbin/init from the bare shell /bin/sh would start everything, it did but then it locked the console for a password.
After hitting a wall with persistent changes on the Hue Bridge’s file system, I decided to try a different approach—Ramdisk. The idea was simple: load an emergency kernel with a temporary file system packed with minimal utilities. This would give me a cleaner environment to poke around and dig deeper into the device’s internals.
From the boot logs, I learned that the Hue Bridge uses an MTD-based NAND layer with a SquashFS file system and some overlay magic. The catch? Any changes made in the /bin/sh environment wouldn’t stick and would vanish after a reboot and never make it to the actual /sbin/init boot process. I spent days trying to crack this, but persistent changes on MTD were a no-go.
So, Ramdisk became the plan. The goal: boot into a better file system environment and then dump the MTD blocks one by one outside the device using nc.
Lets see how we can load a Ramdisk - You can find a bunch of Ramdisk’s from here - you need a a specific one that can understand the NAND https://downloads.openwrt.org/releases/21.02.2/targets/ath79/nand/
We already had bootdelay set to 5 (thanks to our earlier glitch) and changed the boot command line to /bin/sh. U-Boot conveniently offers a TFTP boot option, which is perfect for loading a Ramdisk over the network.
Back in the day, TFTP was common because it’s lightweight and easy to embed in U-Boot. It allows network boot or RAM load out of the box. There’s also DFU boot, another U-Boot feature that later became popular with Raspberry Pi and other dev boards..
From uboot envars we have
To load the Ramdisk, we need a local TFTP server. Here’s the setup:
Connect both over Ethernet, and you’re good to go. U-Boot will use these settings to pull the Ramdisk image from your TFTP server during boot.
I am using from the below ramdisk.
Philips, please enable Secure Boot - at-least the basic one !!
Once the system pulls the image into RAM and starts booting, you’ll need to enter failsafe mode, otherwise, the image will spiral into an endless kernel panic. (Debugging that rabbit hole is a story for another day.)
Failsafe mode basically gives you a minimal shell environment so you can work with the temporary file system without crashing the device. From here, you can start dumping MTD blocks using nc or whatever method you prefer.
Now we’ve got our emergency Ramdisk running, and it’s time to start pulling the firmware from the MTD partitions. Before you dive in, make sure to configure the network interface, usually eth1 on this device and set the IP address correctly so the device can talk to your host machine.
Once that’s done, you can start dumping the MTD blocks one by one and stream them out using nc (netcat). This gives you a clean way to extract the raw firmware without relying on the device’s restrictive overlay filesystem.
Once you’ve got the Ramdisk running and the network configured, do a quick ping from your host machine to the device to make sure connectivity is solid. If that checks out, the next step is simple:
Start a netcat server on your host machine.
From the device, stream the MTD partitions over to your host using nc.
This way, you’ll have the raw firmware safely outside the device, ready for analysis.
nc -l -p 9000 > <firmware.bin> - on Linux acting as server
dd if=/dev/<partition> bs=1M | nc <your Linux server IP> 9000 - on device
Run the above commands for all the partitions.
The real stuff here is the UBI/SquashFS file system, it holds the root tree of the device: binaries, configs, libraries, and everything else that makes the Hue Bridge tick.
After dumping the MTD partitions, the next step was parsing them. For that, I turned to some Python-based UBIFS reader utilities. They’re super handy for extracting and navigating the contents of these NAND-based file systems without having to mount them directly on the device.
Finally, I could confirm that the files I pulled were indeed from the Hue Bridge and not some random junk. That meant I successfully extracted the actual firmware (I might share the decryption key if Philips reaches out to me)from the device. The version I got was 1959194040, which is an older build.
For comparison, if you download firmware from Philips’ official site, you’ll get a blob that’s packed, obfuscated, and encrypted. I tried that route too, but the good news is, somewhere in the extracted file system, there’s a decryptor(Please don’t ask for the Decryptor). So, that’s a win.
At least up to this point, the goal was achieved: firmware extraction from the device itself. Other methods didn’t work for me, and I could’nt find an older article that extracts firmware from a newer device . There are old threads on OpenWRT forums about this, but Philips has patched a lot since then.
Could there be a cleaner way to do this? Probably. Did I have time to explore it? Nope—the clock was ticking. This whole process took about 3–4 days of solid work.
Troubleshooting Tips:
- As always make sure your hardware connections are not loose - this has caused me time well wasted over the span of my career in a lot of variety of ways
- I spent a lot of time getting the /bin/sh and then pivot to /sbin/init by doing all sorts of ubifs magic, overlayfs, mtd mounting etc. The steps here however worked somehow after a lot of trial and error.
- Don’t get locked down by dead-ends and quickly move to another approach - Go in the rabbit hole that is worth while
- As I had limited time probably just 2 weeks so i only could go for a few rabbit holes.
When I used to work as a low-level developer i have worked and wrote code for most of the things mentioned here. However, there were a few things, that were new to me until here.
I would also like to Thank my dear friend Alexandre Opeck for some cool discussions(quantum JTAG :) ) we used to have during our coffee breaks on various strategies for this device.
In the next one, we will have a look at the functionality and other items I investigated!
Resources:
https://research.checkpoint.com/2020/dont-be-silly-its-only-a-lightbulb/
https://www.reddit.com/r/Hue/comments/3x12y6/jailbreaking_the_v2_hub/
https://www.jkry.org/ouluhack/HackingHueBridge?utm_source=chatgpt.com#Getting_root_shell_.28HW_hacking.29
https://blog.kleine-koenig.org/ukl/philips-hue-bridge-v21.html
https://ottelo.jimdofree.com/sonstiges/philips-hue-bridge-wlan/
https://www.synacktiv.com/publications/i-hack-u-boot
And others …
