Even More Bluetooth Smart Bulb Hacking

Broken Bulb Leads to Reverse Engineering Adventures!

One morning, my Magic Blue bulb fell and broke. Normally, this would be annoying, if not upsetting, but I was happy about it — I’ve wanted to break it open for a while to see what’s inside and try to reverse engineer it. Finally, I got the opportunity!

Ah, the sweet smell of opportunity!
Ready… aim… start hacking!

Inside the Bulb

First of all, I should say that I found this bulb much easier to take apart compared to the WiFi bulb I worked on previously. By applying just a little force and cutting the red Live power wire from the bulb base, I was able to completely remove the cover and get just the electronics.

Some pliers, elbow grease, and viola!
Taking apart the bulb is easy 💡
Guts… yum!
The LED Board
I found the bulb!

Let There Be Light!

I figured out that if I wanted actual light output, I will probably need to supply some power to the “V+” pin, as it is the one that goes to the LED board. I connected that pin to the power supply, and then started from a low voltage, limiting the current to 80mA, and slowly raised the voltage limit. At some point, around 5V, a dim red light started to appear, and as I went up with the voltage knobs, I suddenly got green and then blue. It was working: the bulb circuit was powered. Warm white actually required a little higher voltage; 12V seemed to do the trick.

Getting the Firmware

By looking closely at the logic board, I discovered they used the nRF51822 chip — the same chip I used for the ng-beacon and for the Purple Eye Robot! This is really great for a couple of reasons. First of all, I am already familiar with the chip, and second, it is always fun to see commercial vendors choosing the same products you use in your DIY experiments :-)

The surprise programming interface — “GND”, “CLK” and “IO”
openocd -f interface/cmsis-dap.cfg -f target/nrf51.cfg -c init;exit
Info : nRF51822-QFAB(build code: C0) 128kB Flash
openocd -f interface/cmsis-dap.cfg -f target/nrf51.cfg -c "init; halt; flash read_bank 0 magicblue.bin 0 131072; exit"
arm-none-eabi-objcopy -I binary -O elf32-littlearm --binary-architecture arm magicblue.bin magicblue.elf

Playing with the Firmware

Once in the IDA, I switched to Thumb instruction mode (also explained in the WiFi bulb post linked above), and went hunting for strings. There were just a few strings, most of them named the source files of the bulb firmware, but there was one string consisting of the 16 hexadecimal digits: "0123456789ABCDEF":

(gdb) target remote localhost:3333
Remote debugging using localhost:3333
0x00000000 in ?? ()
(gdb) monitor reset halt
nrf51.cpu: target state: halted
target halted due to debug-request, current mode: Thread
xPSR: 0xc1000000 pc: 0x000006d0 msp: 0x000007c0
(gdb) continue
Continuing.
set {char}0x20002047=0x28
The “Bulb” in blue fade mode
print {char}0x20002047
Take that, standard feature-sets!

Concluding Thoughts

Overall, the live-debugging method proved itself as a very efficient reverse-engineering technique: it took me just a little more than one hour from the moment I connected the debug interface until I could do the things mentioned above. It kept me focused on the more interesting parts, and I had to read almost no unrelated code.

Google Developer Expert for Web Technologies, Maker and Public Speaker

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store