Reverse-Engineering Philips Wiz Smart Bulbs

I reverse-engineered my Wiz smart-bulbs so I could control them without the Wiz app.

I’m going to walk through my reverse-engineering process here, just in case that helps anyone. If you mainly want to know about the protocol, I’m sure someone else has already documented it by now. If you want a library to control them without much fuss, you may be out of luck for the time being.

tl;dr:

echo '{"params":{"b":255,"c":0,"g":0,"r":15,"w":43},"id":542,"method":"setPilot"}' \
	> /dev/udp/10.0.0.95/38899

You can guess what r, g, and b are. The c and w are for “cool white” and “warm white” respectively.

Did you know you can send UDP packets directly from bash?¹   Me neither.

Why?

These bulbs themselves are pretty decent, but I don’t like the Wiz app. Partly for privacy reasons, and partly because I don’t want to rely on a proprietary application to control something basic and fundamental like my lights.

I was also considering building a fun little physical controller for each room’s lights with e.g. an ESP32 and 5x linear (sliding) potentiometers. Nothing beats a correctly located physical control. As an apartment-dweller, I like to have the dimming built into the bulbs themselves, but admittedly they really were onto something way back when they started installing lightswitches at the entrances and exits to rooms.

Also, if we’re being honest, I just wanted to fool around with Wireshark and learn how it works. I’ve had half a mind for a while now to start monitoring other devices in my home and see what kind of information they leak. This was a good first step, since, like everyone’s first Arduino project, it has the satisfying culmination: “Hey look, I can make the lights blink!”

Background

The bulbs I have are the Philips Wiz Bulbs, which are controlled primarily via WiFi. These are distinct from the Philips Hue bulbs which require a base-station and (IIRC) are using something like 433 or 900 MHz for control input.

They’ve got something like an ESP8266 inside, and can host their own WiFi AP for setup. Essentially all that this does is allow you to push the credentials for your main home WiFi network onto the bulb using the Wiz app. Once the bulb has saved the credentials for your home network, all further interactions will occur there.

It’s reasonable to presume that they’re authenticating and securing a DHCP lease. For the sake of convenience, I might have my router’s DHCP server assign specific IP addresses to them, so they won’t hop around as the leases expire.

After they’re connected, they could be listening on some port, or they might theoretically be polling some Wiz server, but the latter seems unlikely.

I expect that I can sniff the wireless traffic, record all the packets going to the bulb or coming from it, and then analyze those to reverse-engineer the protocol. Theoretically, there could be encryption set up in such a way as to require reverse engineering the Wiz app itself to defeat it, but I doubt they’d have bothered.

Setting Up Wireshark

I’ve hooked up an old, cheap wireless dongle which supposedly has decent Linux drivers.

However, Wireshark starts up without any interfaces available. I definitely remember, once, being able to select an interface to monitor on this screen.

You have to add your user to the wireshark group, and then you probably have to log out and log back in again to get that group attached to your login shell. I will instead live dangerously and opt for sudo wireshark.

It works perfectly now.

Monitoring the Wireless Network

If you simply double-click on a wireless interface that’s not already associated to an AP, you’ll get no packets:

When I checked ip link, the interface is state: DOWN. To get the interface up and associated, you can use tools like wifi-radar, Wicd, NetworkManager, etc. You can even use wpa_supplicant manually, but it’s a pain. The easiest thing you could possibly do is move to a machine that’s already associated with the Wireless AP you want to monitor, so that’s what I did.

If this works, you’ll see a great many packets. Who knew your computer did this much talking behind your back? Not to worry, I’m sure they’re all fine.

We’ll need some way to filter these packets. The IP or the MAC address for one of the lightbulbs would be the natural choice. I logged into my router to see an overview of the devices it was aware of, and it helpfully provides MAC addresses for everything.

Wiz also helped us out a little - the hostnames of the Wiz bulbs all start with wiz_. If you’re reverse-engineering something less helpful, it may be worth knowing that you can sometimes look up the manufacturer of a network device based on the MAC address.

In Wireshark, you can use a filter like eth.addr == xx:xx...:xx for MAC addresses.

If you look at the Source column for these Ethernet frames, you can see that Wireshark has replaced A8:BB:50 with WizIot. This is because it could look up the manufacturer for that MAC address prefix. Neat.

Those packets above were collected by turning the bulbs off and then back on. You can see they request IP addresses from DHCP. One of them was granted 10.0.0.242. Next, I’ll filter based on that IP address instead of the MAC. This will still filter for that specific lightbulb, but it will also naturally exclude all traffic below IP. The lower-level stuff is just noise to me at this point.

To be continued

After the above, I had to pivot and capture the packets a slightly different way. I will do a write-up of this process later.