What is the reliance on external cloud?

[charlietomo]

I am trying to work out what the reliance is on an external cloud for these Wiz bulbs. Ideally I would just use this component to control them locally, with the bulbs restricted from accessing the internet (via my network setup). Has anybody done this or have any insight?

I note that when a bulb is setup, the final stage is "registering on cloud".

[sbidy]

I have restricted the bulbs to my network. They can't connect to the cloud service form WiZ. But this will limit the features of the bulb because the app can only communicated via UDP. The UDP API for example doesn't support changing the fade speed and some other "advanced" features of the bulb. But you can change the color, scene, on/off and brightness.

The HASS integration uses this UDP API to communicate lockaly with the bulb. So you can isolate your bulbs to your local network and control them with HASS. I don't use the Cloud API.

Some tech details:

• The cloud connection is done via MQTT (mqtt-uat.wiz.world, mqtt-dev.wiz.world, us.mqtt.wiz.world)
• The connections to the cloud are always encrypted with TLS (Lets Encrypt)
• The bulb will be updated of-the-air via cloud connection (this will done automatically)
• The Firmware was singed (firmware.wiz.world)
• The bulb uses a "standard" ESP8266 Hardware
• The bulb updates the time via ntp.wiz.world

[probonopd]

Does anyone know full URLs for the OTA on firmware.wiz.world? I would like to have a look at the firmware without taking a device apart. Thanks!

[rampd2]

But I think without the certificate from Wiz it would not be possible to setup a local server.

I think it didn't work as I tried with eclipse-mosquitto docker image and as far as I saw, I subscribed to '#' (all topics?), and it didn't output something untill I published some test messages, so I can be sure that my dns setup (with fake answer (eu.)mqtt.wiz.world -> my mqtt broker) seems working.

If the bulb is just subscribing to the mqtt topic (would explain no messages), to which topic (1) should I send what messages (2)?

Actually I see that it tries to connect over tcp to port 8883 (secure-mqtt) but that does not work, probably because my mqtt broker (mosquitto) does not correctly listen on (just added as additional port host:8883 -> container:1883) and I don't have a valid certificate for eu.mqtt.wiz.world.

The broker console displays:

New connection from wizbulb-address:port on port 1883.
Client <unknown> disconnected due to malformed packet.

[sbidy]

So WiZ was acquired by Signify (Philips Lighting) . Maybe there are some changes coming in the future (maybe connect WiZ bulbs to the Hue bridge)

[GoobyCorp]

They use MQTT over SSL (port 8883). Maybe its possible to create a DNS entry pointing to a local MQTT broker (eclipse-mosquito). But unfortunately haven't time to test ist. But I think without the certificate from Wiz it would not be possible to setup a local server.

I plan to flash the lights to tasmota in the near time future.

I have tested it using no authentication and with self-signed certificates using mosquitto and it does appear like they will connect and accept messages.

[craigcabrey]

I was also able to get them to connect to a local MQTT server earlier this year. However I wasn't sure how to figure out what topics they would be listening for. Perhaps if we get a copy of the firmware we can dump strings?

[GoobyCorp]

That's certainly possible, I know it just uses an esp8266 like a lot of other smart home devices.

On December 13, 2021 6:17:24 PM EST, Craig Cabrey ***@***.***> wrote: I was also able to get them to connect to a local MQTT server earlier this year. However I wasn't sure how to figure out what topics they would be listening for. Perhaps if we get a copy of the firmware we can dump strings? -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: #85 (reply in thread)

-- Sent from my Android device with K-9 Mail. Please excuse my brevity.

[craigcabrey]

So for what it's worth, it looks like their latest firmware fixes the insecure MQTT (that is, no client side verification). I tested one of my spare bulbs and noticed a message in MQTT that it upgraded its firmware to 1.23:

{"method":"devDebug","env":"pro","params":{"rebootReason":"FW 1.23.0(1.22.13)-0x2/1c/402881f5/0/4010093c/38/0/402881f2"}}

Now it appears to skip the DNS lookup on bootup and connects directly to Amazon:

$ nslookup 18.208.176.54
[...]
Non-authoritative answer:
54.176.208.18.in-addr.arpa	name = ec2-18-208-176-54.compute-1.amazonaws.com.

As for how it upgraded firmware, I'm not exactly sure (since I have this VLAN blocked from the internet), but the app may have transmitted an updated FW payload?

[craigcabrey]

ahh I take that back, I see it connected now

[craigcabrey]

but ultimately, this DEV channel is read only (which makes sense), so we need to get ahold of a firmware dump that's unencrypted to see what methods are available.

it seems to monitor this topic from the logs of the mqtt server

1639447638: New client connected from 192.168.20.154:25342 as a8bb50fcce60_3223102 (p1, c1, k40, u'a8bb50fcce60').
1639447638: Will message specified (67 bytes) (r0, q0).
1639447638: 	DEV/pro/a8bb50fcce60
1639447638: Sending CONNACK to a8bb50fcce60_3223102 (0, 0)
1639447638: Received SUBSCRIBE from a8bb50fcce60_3223102
1639447638: 	OP/pro/3223102/devices/a8bb50fcce60 (QoS 0)
1639447638: a8bb50fcce60_3223102 0 OP/pro/3223102/devices/a8bb50fcce60

The last part is the MAC address of the bulb, not sure what the 3223102 identifier is. If I publish to that topic, it seems to crash the bulb. Just tried basic stuff like {"method":"status","params":{}} -- I'm assuming it's a crash since I see 1639447809: Client a8bb50fcce60_3223102 closed its connection. immediately after, then it rejoins after 10-15 seconds.

[GoobyCorp]

but ultimately, this DEV channel is read only (which makes sense), so we need to get ahold of a firmware dump that's unencrypted to see what methods are available.

it seems to monitor this topic from the logs of the mqtt server

1639447638: New client connected from 192.168.20.154:25342 as a8bb50fcce60_3223102 (p1, c1, k40, u'a8bb50fcce60').
1639447638: Will message specified (67 bytes) (r0, q0).
1639447638: 	DEV/pro/a8bb50fcce60
1639447638: Sending CONNACK to a8bb50fcce60_3223102 (0, 0)
1639447638: Received SUBSCRIBE from a8bb50fcce60_3223102
1639447638: 	OP/pro/3223102/devices/a8bb50fcce60 (QoS 0)
1639447638: a8bb50fcce60_3223102 0 OP/pro/3223102/devices/a8bb50fcce60

The last part is the MAC address of the bulb, not sure what the 3223102 identifier is. If I publish to that topic, it seems to crash the bulb. Just tried basic stuff like {"method":"status","params":{}} -- I'm assuming it's a crash since I see 1639447809: Client a8bb50fcce60_3223102 closed its connection. immediately after, then it rejoins after 10-15 seconds.

Might be some kind of weird MQTT implementation then, maybe there's some kind of exploit possible to dump the firmware from it.

[probonopd]

dump the firmware from it

Or find out the firmware update URL and download it from there?

[GoobyCorp]

dump the firmware from it

Or find out the firmware update URL and download it from there?

Possibly but if it's over HTTPS that probably won't happen.

[brettonw]

I use the bulbs on a subnet that does not have internet access. Every so often I open it up and use the app from my phone to connect to the bulbs, and they get firmware updates. That said, they work perfectly with the local only interfaces that sbidy has put together here. It's probably the most reliable component of my home setup, honestly.