Hue Firmware Update

[Krocko]

Today Philips published firmware updates for various lights. Any chance to update the lights with deCONZ?

[rb2k]

That or https://www.charlesproxy.com/ on macOS. I guess we'd have to hope that they don't do certificate pinning in the app / firmware.

I sadly don't have a bridge anymore so I'm afraid I am not very useful :)

[timbru31]

I’ve already MITM myself with Burp. The problem is that the payload of the https request is AES encrypted, so we need to find the key in the bridge/or the bridge firmware.

So far I’ve had no time to look into this.

[rb2k]

Just to clarify do you mean that:

a) the MITM worked and you can see the HTTP interaction, but the body of the HTTP response is a binary blob.

or:

b) Do you mean that the whole communication was SSL encrypted because it's HTTPS

For b) charlesproxy installs an ssl certificate on the phone and will use it to re-encrypt the traffic For a) from what I understand, it's fine to have the files themselves be encrypted since the bulbs will handle the decryption

[timbru31]

a) MITM, including SSL, works but besides that the HTTPS the actual payload/body is AES encrypted.

For a) from what I understand, it's fine to have the files themselves be encrypted since the bulbs will handle the decryption

The OTA files are not the problem. But the AES encrypted request to ecdinterface.philips.com is the problem. Probably the response contains the URLs of the firmwares (they are located at http://fds.dc1.philips.com/firmware/)

[izzy84075]

Does anybody know what the latest version for LWB004 lights is? I gave away my Hue hub a while ago, so I have no way of sniffing out it's secrets.

[ooii]

Hi, long time since I did not visit deconz repo. I read through this thread and it seems Hue bulbs can be updated from Deconz, cf. Congrats this is the first time a Hue device was updated via deCONZ :). Is there any procedure I can follow to do that? I have maybe 40 bulbs and don't want to unpair/pair/unpair/pair them. Thanks.

[MattL0]

+1 i am currently updating a lot of my hue device... this is painful haha.... ( but can study at the same time). The task is almost finished now ( why the he** does it take 45 mins per device???)

any device are available for direct fw update via deconz?

[flobernd]

@manup Are there any updates regarding this feature? I would love to connect all my devices to deCONZ, but having no updates for all my Hue bulbs is no option for me at the moment.

[qvicksilver]

Tried reaching out on the Facebook page: https://www.facebook.com/HuePhilips/posts/1910598109072064?comment_id=1910732495725292&reply_comment_id=1910939499037925&notif_id=1571500554024772&notif_t=feed_comment

Followed up on that with a post on the forum: https://developers.meethue.com/forum/t/firmware-downloads/6242

Feel free to join in and create some buzz.

[ottelo9]

Judging by the filename and size, that's a firmware image alright.

100B-010C-01001A00-ConfLight-Lamps_0012.zigbee
|    |    + image file version
|    +- image type (device type)
+- manufacturer code 0x100b = Philips

These match the fields in the STD OTAU Plugin panel of the deCONZ GUI, see e.g. #96 (comment).

The image type and file version match the current (1.46.13_r26312) firmware for the Color Temperature bulbs and spots (LTWxxx).

Now the $100M question is whether this file is encrypted. If it isn't, you should be able to download it, feed it do the OTAU plugin and update the firmware from deCONZ. If it is, the file is useless without the decryption key.

How can I convert the Hex 0x01001a00 file version to the Version String 1.46.13_r26312?

[mories76]

I've bought myself a Hue bridge, ripped it open, became root. Connected both my iPhone and the HUE via InternetSharing on my iMac

This way I could capture an url for the latest HUE motion sensor firmware. http://fds.dc1.philips.com/firmware/ZGB_100B_010D/1107323831/Sensor-ATmega_6.1.1.27575_0012.sbl-ota (I will try to update one of my Motion sensor with this firmware via deconz) While the bridge is downloading/updating the firmware file it is stored as /tmp/image.fw

I've also found an url for the Bridge firmware. I think it's encrypted, not sure yet. There is a pem file somewhere on the filesystem, which might be used for decrypting the image.

There doesn't seem to be an easy way to a json like the way Ikea does. Still poking around.

update: Deconz says: 'Invalid' file when trying to open the OTA file.

[manup]

From a quick look in the hex editor it has at least a valid Zigbee-OTA header. Need to check further if there is something different from other ota files.

[timbru31]

AFAIK the actual firmware files can be flashed just fine with deconz, the problem is that we can’t generate/guess/decode the URLs for the firmware files other than manual sniffing.

Sent from my iPhone

On 12. Feb 2020, at 6:20 PM, Manuel Pietschmann notifications@github.com wrote:

 From a quick look in the hex editor it has at least a valid Zigbee-OTA header. Need to check further if there is something different from other ota files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[manup]

Did run some more tests. This particular firmware file does indeed have a valid header but no data which conforms to the specification. Also noticed that IKEA ota files cotain some "invalid" data at the end but at least have a valid fimware data section.

[manup]

I've tried to treat the whole unknown data section after the header as firmware but the sensor doesn't seem to like that since the update won't start. Notice that the reported file version is the same as given in the ota file (but usually it should work to overwrite the same version by unicast).

[ottelo9]

Any news about the new update?

[sorryusernameisalreadytaken]

Did I see that right that a lot of zigbee hue lamps got an update to software version: 1.50.2_r30933 and 5.130.1.30000 : https://www2.meethue.com/en-us/support/release-notes/lamps

I dont need new features but things like "Security improvements" :/

[timbru31]

@sorryusernameisalreadytaken I've did some sniffing again:

Firmware v1.50.2_r30933 for, e.g., LCT015 (Hue White and Color E27) is at http://fds.dc1.philips.com/firmware/ZGB_100B_010C/16783874/100B-010C-01001A02-ConfLight-Lamps_0012.zigbee

~@manup - was one able to successfully flash the firmware? I'm sniffing the ZigBee traffic, too - could one extract the decrypted firmware from a PCAP file?~ Erik just flashed it 🎉

Nevertheless, here it is. OTA starts at package 4020, finishes at around 49423 and I've hit the "restart/update" button in the Hue app at 54298, after that the bulb came back with the new firmware version. ota_zigbee.pcapng.zip

[ebaauw]

The file from the above link seems to be working?! It's downloading to one of my LTW013 spots, 20% in just under 10 minutes.

Would you be able to sniff the location of the 5.130.1.30000 firmware as well?

[timbru31]

The 5.1xx firmware is from the Lightstrips, isn't it? Sadly, I've got none of them.

[kmplngj]

The 5.1xx firmware is from the Lightstrips, isn't it? Sadly, I've got none of them.

@timbru31 is there a guide to get the firmware? I have the lightstrip and an hue bridge.

[ebaauw]

They seem to be consolidating firmware across multiple models. The 5.130.1.30000 is for:

• The three-channel gamut-B Extended color light spots (LCT003) and bulbs (LCT007);
• The Dimmable light bulbs (LWB006).

I suppose it supports all gamut-B extended colour and dimmable lights.

The 1.50.2_r30933 is for:

• The five-channel gamut-C Extended color light bulbs (LCT015);
• The white ambiance Color temperature light bulbs, spots, and candles.

I suppose it also supports the 2nd-gen lightstrip and other gamut-C extended colour and white ambiance lights.

The gamut-A Color light devices, like the 1st-gen lightstrips (LST001) and Blooms (LLC011) have different firmware, at least before the recent release.

64% after 30 minutes and counting...

[timbru31]

The 5.1xx firmware is from the Lightstrips, isn't it? Sadly, I've got none of them.

@timbru31 is there a guide to get the firmware? I have the lightstrip and an hue bridge.

Easiest way is to use your router's built in sniffing: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/270#issuecomment-488352044 Otherwise you need to connect your bridge to a computer and run Wireshark in between to sniff the URLs.

---

The 1.50.2_r30933 is for the white ambiance Color temperature light bulbs, spots, and candles.

Are you sure? My bridge reports that firmware for the LCT015 which is definitely a color capable light.

[ebaauw]

No, I confused myself once again. The 1.50.2_r30933 is white ambiance and gamut-C (five-channel) colour. Edited my comment above.

[ebaauw]

Done at 49:35. Reading SW Build ID in the GUI yields 1.50.2_r30933.

[volschin]

@ebaauw 5.130.xxx is for LWB004 and LST002 also. But it is not for LCT001 and LST001 having 5.127.xxx at the Moment. 1.50.2.xxx is for LTC012 also.

[ebaauw]

OK, the previous version, 01001A00, of the 010C firmware is at: http://fds.dc1.philips.com/firmware/ZGB_100B_010C/16783872/100B-010C-01001A00-ConfLight-Lamps_0012.zigbee.

Using the same naming scheme, I would hope that the 5.130.1.30000 (with version 42007530 and image 0104 would be at firmware/ZGB_100B_0104/1107326256/100B-0104-42007530-ConfLight-Lamps_0012.zigbee, but no such luck. Apparently we need a different name than "ConfLight-Lamps".

Second light done in 37:56; third is underway...
This sure beats resetting the lights, pairing them with the Hue bridge, resetting them again after the upgrade, pairing them with deCONZ, finding out not all scenes are restored, re-applying the scripts to create the scenes.

[volschin]

In my FHEM HueBridge Module I see 3 Updates announced on 2nd March: ZGB_100B_010E-ConfLight-ModuLum Samr21-25.4y ZGB_100B_010B - 5.130.1.30000 ZGB_100B_0105 - 5.130.1.30000 Y

Perhaps this helps

[zladukas]

Successfully updated couple of LWB010 and LTW012 with firmware 1.50.2_r30933, mentioned above. It took 24 .. 33 minutes.

[sorryusernameisalreadytaken]

Successfully updated couple of LWB010 and LTW012 with firmware 1.50.2_r30933, mentioned above. It took 24 .. 33 minutes.

Did I need vnc for that or can I use phoscon or REST?

[zladukas]

You need to use STD OTAU plugin in deconz-gui. There is no difference how You will reach it: vnc or XWindows emulator: Exceed, mobaXterm, XQuartz.

[dedepene]

silly question, but what's the easiest way to get the file to /data/otau considering it's not accessible via samba right away?

[timbru31]

silly question, but what's the easiest way to get the file to /data/otau considering it's not accessible via samba right away?

scp? (https://linux.die.net/man/1/scp)

[ebaauw]

Did some more sniffing, probing, and testing of the Hue devices I own, and found the following:

Image	Device(s)	Firmware	Works
0103	Gamut-A Color light	5.127.1.26581
0104	Gamut-B Extended color light	5.130.1.30000	Y*
0105	Dimmable light	5.130.1.30000	Y*
0109	Hue dimmer switch	6.1.1.28573
010C	Gamut-C Extended color light Color temperature light	1.50.2_r30933	Y
010D	Hue motion sensor	6.1.1.27575
0116	Hue button	2.30.0_r30777

*) The 010C firmware is in a .zigbee file that works with deCONZ' OTAU. The others are in .sbl-ota files, which are rejected by the deCONZ STD OTAU plugin (even after renaming the file manually). EDIT After updating the plugin to accept and handle these files (see below), it upgrades the corresponding lights alright.

Looking at the 0105 firmware file:

$ od -A d -x WhiteLamp-Atmel-Target_0105_5.130.1.30000_0012.sbl-ota 
0000000      f11e    0bee    0100    0038    0000    100b    0105    7530
0000016      4200    0002    0000    0000    0000    0000    0000    0000
0000032      0000    0000    0000    0000    0000    0000    0000    0000
0000048      0000    0000    ea78    0003    002a    0501    6600    20c0
0000064      2001    2215    0359    00ea    1524    e436    a836    2c82
0000080      b30a    726b    df37    0680    137c    0383    cbae    d265
0000096      f1e5    bd24    6dc3    467e    f611    3142    a6c1    8e1e
0000112      1361    c055    1e5f    e2c7    5433    ac94    4d37    02e2
0000128      573a    ed1f    2f93    2e8a    ca58    ec4f    a23c    0407
0000144      3e13    5d94    33d8    b9c6    9df6    ba42    3835    3362
0000160      63c8    8ba1    2131    95cb    db46    a648    2168    d877
0000176      8b8e    669a    c0b0    9c7e    d5ea    e3b6    105c    739b
0000192      a795    2b78    4de5    14fb    b76f    4427    ea90    a389
0000208      7af0    743b    cba8    bd1f    f957    5be1    6f43    beea
0000224      5bb6    9e87    b289    1019    cfe0    db64    02db    f9c1
0000240      b5d6    51f5    76aa    b980    3b0c    a22f    7e6a    c9d7
0000256      368d    490b    5f8d    092a    1dca    80d6    0a8e    0754
0000272      da92    e860    0a9a    2935    6019    d077    ad30    5e74
0000288      7998    230e    8bb4    713d    6e5d    ca25    f835    1a58
0000304      0024    bb1b    0dc7    70bf    98dd    08d8    f6e5    f50b
0000320      663f    b1c0    d78a    78c5    8e3d    6935    8ae7    6495
0000336      1fcf    50bb    a374    5205    5bc0    a90a    ec99    ba66
0000352      b317    2046    18d2    80a6    1f8b    3c3c    60dd    9980
0000368      54d8    471e    38db    ee8d    88e8    73da    26bb    9bcd
0000384      bb16    6cb7    6d88    8185    6511    5090    d720    557a
...
0256512      85ff    e062    8562    5176    beb8    e24c    05c7    ad3a
0256528      f665    c884    2019    b8b7    999f    1b7e    3f5b    adeb
0256544      c763    f13d    1fab    5c33    c1ec    9fbe    dd48    0456
0256560      97a3    7bfe    984d    8be5    3fac    521c    0f67    0bf3
0256576      e6e8    5eab    8726    6257    f85e    e0df    6d10    e826
0256592      0aef    5b6c    585b    a47b    2c75    dd71    f175    1df4
0256608      c131    1a07    12c4    d115    36ad    f3cd    f45a    9ff5
0256624      8f5c    c8f5    1918    de67

That's a valid header alright, but followed by a segment with tag 002A and a length that doesn't compute. The other .sbl-ota files have the same tag and invalid length.

Sniffing the OTA messages from the Hue bridge. First request from the light, offset 0, max size 64 is met with the first 64 bytes from the file:

1e:f1:ee:0b:00:01:38:00:00:00:0b:10:05:01:30:75:00:42:02:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:78:ea:03:00:2a:00:01:05:00:66:c0:20

Second request from the light, offset 56, max size 64. Apparently the light was only able to handle the header. The bridge returns the first 64 bytes of the 002A segment, unmodified:

2a:00:01:05:00:66:c0:20:01:20:15:22:59:03:ea:00:24:15:36:e4:36:a8:82:2c:0a:b3:6b:72:37:df:80:06:7c:13:83:03:ae:cb:65:d2:e5:f1:24:bd:c3:6d:7e:46:11:f6:42:31:c1:a6:1e:8e:61:13:55:c0:5f:1e:c7:e2

Third request, offset 120, max size 64; sniffer didn't capture the response. Fourth request, offset 184, max size 64. Response:

ea:d5:b6:e3:5c:10:9b:73:95:a7:78:2b:e5:4d:fb:14:6f:b7:27:44:90:ea:89:a3:f0:7a:3b:74:a8:cb:1f:bd:57:f9:e1:5b:43:6f:ea:be:b6:5b:87:9e:89:b2:19:10:e0:cf:64:db:db:02:c1:f9:d6:b5:f5:51:aa:76:80:b9

Last request for offset 256568 is met with:

ac:3f:1c:52:67:0f:f3:0b:e8:e6:ab:5e:26:87:57:62:5e:f8:df:e0:10:6d:26:e8:ef:0a:6c:5b:5b:58:7b:a4:75:2c:71:dd:75:f1:f4:1d:31:c1:07:1a:c4:12:15:d1:ad:36:cd:f3:5a:f4:f5:9f:5c:8f:f5:c8:18:19:67:de

As far as I can tell, the data is transferred unmodified.

[Hypfer]

I can't seem to get my Aurelle Panels (LTC013, LTC014, LTC015) to accept the 1.50.2_r30933 update. :(

They're all currently running 1.16.1_r19181

[ebaauw]

What image do they have?

[Hypfer]

Where does one find that information?

[ebaauw]

In the OTAU plugin in the GUI.

[Hypfer]

I only see the file information. Without selecting it everything stays 0x0

[ebaauw]

In the table you see columns Address, Version, Image. Select the row corresponding to your light and press Query. That should populate the Version and Image fields. The Image must match the image type from the firmware file. Different firmware images might still use the same version (as e.g. the 0104 and 0105).

[Hypfer]

Oh I see. Image is 0x010e for the Aurelle panels

[Hypfer]

Hm. Apparently it is possible to edit the Image Type using deconz.

Will a modified update brick the device?

[kcdr]

My update seems to fail: I tried to update LCT010 to 1.50.2_r30933. The update via OTAU-Plugin finishes and says "done". But in Phoscon and Rest-Api the Version is still 1.29.0_r21169

@ebaauw do you have the same effect? Any hint what goes wrong on my side? Thanks in advance.

[ebaauw]

See https://github.com/dresden-elektronik/deconz-rest-plugin/issues/270#issuecomment-498345803.

[dedepene]

Did some more sniffing, probing, and testing of the Hue devices I own, and found the following:

Image Device(s) Firmware Works 0103 Gamut-A Color light 5.127.1.26581
0104 Gamut-B Extended color light 5.130.1.30000
0105 Dimmable light 5.130.1.30000
0109 Hue dimmer switch 6.1.1.28573
010C Gamut-C Extended color light Color temperature light 1.50.2_r30933 Y 010D Hue motion sensor 6.1.1.27575
0116 Hue button 2.30.0_r30777

As far as I can tell, the data is transferred unmodified.

So how would you go about flashing the 0104? I had no luck renaming it to .zigbee and the default extension is not registered by the deconz plugin at all.... :(

[ebaauw]

I think the OTAU plugin rejects the .sbl-ota files (even after renaming them), because if the invalid segment with 002A tag and bogus length.

I've tried to treat the whole unknown data section after the header as firmware but the sensor doesn't seem to like that since the update won't start.

@manup, did you ever release this tryout logic? Could you publish a beta of the OTAU plugin (or the code) with this change?

Notice that the reported file version is the same as given in the ota file (but usually it should work to overwrite the same version by unicast).

I cannot get my 010C light to re-upgrade either. I think the Hue devices might actually reject a firmware upgrade to the current version; the Hue bridge doesn't provide any way to do that.

[manup]

@manup, did you ever release this tryout logic? Could you publish a beta of the OTAU plugin (or the code) with this change?

Yes I tried a few things but couldn't get it to work :/

I want to open source the OTA plugin as separate repository, but will take a bit since the build system needs to be adapted. Meanwhile I can provide the OTA plugin as zip: std_otau_v2.5.75.zip

[ebaauw]

No Makefile? That's created by qmake, of course.

I do get an error that crc8.c and crc8.h are missing.

$ qmake
Info: creating stash file /home/ebaauw/GitHub/std_otau/.qmake.stash
Cannot read /home/compile.pri: No such file or directory
Cannot read /home/ebaauw/GitHub/common.pri: No such file or directory
WARNING: Failure to find: ../../deconz/crc8.c
WARNING: Failure to find: ../../deconz/crc8.c

[Hypfer]

/*! Checks if a new otau image for the node is available in the otau folder.
    Otau images must be in the <otau> directory and must have a proper formatted filename.
    All numbers are hexaecimal and in capital letters.
    filename: <manufacturer code>-<imagetype>-<fileversion>-someArbitraryText.zigbee
    example: 113D-AB12-1F010400-FLS-RGB.zigbee

    \param node - the node for which the check will be done
    \param path - the path to look for .zigbee files
 */
bool StdOtauPlugin::checkForUpdateImageImage(OtauNode *node, const QString &path)

So if we name the Hue firmware update files correctly and just throw them into the default otau directory, I'd assume that deCONZ will automagically update all matching nodes without requiring the user to manually select a file in the GUI?

The content of this comment should definitely be documented somewhere else than just inside a zip file in response number 97 of a random github issue.

[ebaauw]

I'm sorry @manup, I cannot get the std_otau sources compiled, even if I comment out the crc8 stuff (which I think/hope is only for the BitCloud firmware?). It seems to be incompatible with the deconz-dev package on my pi:

In file included from /usr/include/deconz.h:20,
                 from std_otau_plugin.h:7,
                 from std_otau_plugin.cpp:9:
/usr/include/deconz/aps.h:95:22: error: variable ‘deCONZ::DECONZ_DLLSPEC deCONZ::Addres’ has initializer but incomplete type
 class DECONZ_DLLSPEC Address
                      ^~~~~~~
/usr/include/deconz/aps.h:97:1: error: expected primary-expression before ‘public’
 public:
 ^~~~~~
/usr/include/deconz/aps.h:97:1: error: expected ‘}’ before ‘public’
/usr/include/deconz/aps.h:96:1: note: to match this ‘{’
 {
 ^

Looking at otau_file.cpp, I think the commented code is almost what's needed to make the plugin accept the invalid Hue files, except for setting the sub.tag to 0. From my sniffer log above, the Hue bridge does send the invalid segment, incl. the 002A tag unmodified.

                DBG_Printf(DBG_OTA, "invalid length %u for tag 0x%04X total image size %u (treat hole data section as update)\n", sub.length, sub.tag, totalImageSize);
                sub.tag = 0;
                sub.length = (arr.size() - offset) - headerLength;
                stream.device()->seek(arr.size() - sub.length);