diy solar

diy solar

Zigbee Sniffer

Picked one up, the instructions above were a bit out of date.

I got the "Zigbee sniffer package rev. 2.0" download from https://dsr-iot.com/downloads.

From it I flashed the file ..\zb_sniffer_target\CC2531 USB donglezboss_sniffer.hex to the chip using https://www.ti.com/tool/FLASH-PROGRAMMER.
(I had also loaded the SmartRFStudio in trying to follow the instruction above and it may or may not have provided the USB driver.)

Also from the "Zigbee sniffer package rev. 2.0" download was the Wireshark interface, ..\zb_sniffer_bin\zb_sniffer_host\gui\zboss_sniffer.exe

From there I launched zboss_sniffer.exe, entered the two highlighted
fields, then clicked start and presto! Zigbee packets!

I found two active Zigbee channels, 0x0F and0x19. The first is pushing
about 4 to 5 packets per second, mostly 64 bit IEEE 802.15.4 Beacon packets.
0x19 is more active with about 35 packets per second, most show up as
Zigbee or IEE 802.15.4 protocol.

Also entered 5a6967426565416c6c69616e63653039 as the Trust Center link
key into wireshark. Not sure if it's correct for me, but it's the zigbee default.

Next step is to try and figure out the network encryption key (aka Transport
Key). Below is some output from Wireshark. KillerBee has tools that might
help with that (e.g., zbdsniff, zbgoodfind) if I can get them to run on windows.
1636205464337.png


1636206018204.png
 

Attachments

  • 1636206103400.png
    1636206103400.png
    44.7 KB · Views: 4
Last edited:
Picked one up, the instructions above were a bit out of date.

I got the "Zigbee sniffer package rev. 2.0" download from https://dsr-iot.com/downloads.

From it I flashed the file ..\zb_sniffer_target\CC2531 USB donglezboss_sniffer.hex to the chip using https://www.ti.com/tool/FLASH-PROGRAMMER.
(I had also loaded the SmartRFStudio in trying to follow the instruction above and it may or may not have provided the USB driver.)

Also from the "Zigbee sniffer package rev. 2.0" download was the Wireshark interface, ..\zb_sniffer_bin\zb_sniffer_host\gui\zboss_sniffer.exe

From there I launched zboss_sniffer.exe, entered the two highlighted
fields, then clicked start and presto! Zigbee packets!

I found two active Zigbee channels, 0x0F and0x19. The first is pushing
about 4 to 5 packets per second, mostly 64 bit IEEE 802.15.4 Beacon packets.
0x19 is more active with about 35 packets per second, most show up as
Zigbee or IEE 802.15.4 protocol.

Also entered 5a6967426565416c6c69616e63653039 as the Trust Center link
key into wireshark. Not sure if it's correct for me, but it's the zigbee default.

Next step is to try and figure out the network encryption key (aka Transport
Key). Below is some output from Wireshark. KillerBee has tools that might
help with that (e.g., zbdsniff, zbgoodfind) if I can get them to run on windows.
View attachment 71492


View attachment 71494
Have you been able to beat the encryption on any systems?
 
Nope. Most of the schemes I've seen to break it require a handshake key. I haven't seen such a key yet, but the project got pushed to the back-burner.
 
Had some time to conduct a few experiments. First, I noticed that all of the beacon packets on channel 0x19 had the same data. So, I changed from Savings Mode to Full Saving to see if anything changed and did spot something:

1671821368085.png

That was pretty exciting as I started thinking I wouldn't need to decode the data, I could just map it. Then I realized there was a nonce, so that burst that bubble.

So, then I tried recording on both channels and disconnected, then reconnected after 15 minutes the zigbee dongle. Also tried with rebooting the Envoy. What I was hoping for was to see the zigbee network security key transmitted unencoded. No such luck. There was no halting of communication with the dongle unplugged either, I finally realized the batteries must have continued to transmit even if no one was listening.

Then I tried turning a battery off for 30s and back on. On Channel 0x14 I was rewarded with an association request, association response, and an APS command containing a key-transfer packet. From the request:

1671826235942.png
We can see the device is a "full function device", meaning that it can perform as a router. Power Source = AC/Mains Power indicates that it is not battery-powered and will always be awake.

The default Zigbee default global trust center link key is shown in a response packet, but not the network key. Adding it to Wireshark it I could see there are "Transport Key" packets a few minutes later of type 0x79, 0x23. Entering the 0x79 key doesn't seem to do much. Putting in the type 23 key reveals some more, but it doesn't seem to clear the picture up in Wireshark as expected. So, I'm not there yet...
 
Address 0x0000 is the Pan Coordinator, and from traffic it looks like it is also 0x576d... looking at the traffic I know I have 4 IQ batteries and an empower, assuming battery traffic is roughly equal then... ??

AddressPacketsTx PacketsRx PacketsDevice???
"0x0000"19429409715332PAN Coordinator (zigbee stick?)
"0x576d"52734697576PAN Coordinator
"0x92a4"46294160469IQB4?
"0xa846"41383721417IQB?
"0x1eb8"42933857436IQB?
"0x51c7"1305125055IQB?
"0xa6f0"32226656Enpower?

Might be wrong on 576d, in which case 51c7 might be the Enpower and I'm not sure what 0xa6f0 might be.
 
Seems to be 128 bit AES with no integrity protection, at least in that setting it shows transport keys when used with the default center key (i.e., 5a6967426565416c6c69616e63653039). Most of what I've seen online has 32 bit integrity protection, so quite possibly this is wrong. Also, entering the first key does not automatically transpose the other keys (although, each device might have its own key).
(With no integrity protection, in one of the "unknown Commands", is a "Key ID: Key-load key").

JSON is nice in that it has a key-value pair, for example ["kwh", "12"]. That is looking at the key gives you some context as to what the value means.

Zigbee is not like this. Zigbee uses "Zigbee Cluster Libraries" (ZCL) to provide the context, instead of transmitting a string of the context a data value is supplied. There are a lot of ZCLs and different packets can reference different ones. For example, a SensorTag might be On/Off, Temperature Measurement.

When the library is public (published?) it is probably relatively easy to parse what's going on. What I'm seeing a lot of is "ZCL: Unknown Command". Assuming I have the correct network keys and integrity protection that is. There are manufacturer's codes for the ZCLs, so it might be possible they publish them, something to follow up on.

If not, it might be possible to deduce them with a controlled capture with the system at different operational conditions. A quick scan by packet size shows probably less than 50 types of messages, but still a monumental task.
 
Last edited:
From what I've been reading, Zigbee presently uses a 4-byte MIC. So, I need to dig deeper, quite possibly the default center key isn't what is used. I did see an article that said the install code on some devices was used as an input to a Matyas-Meyer-Oseas (MMO) one-way compression function (https://en.wikipedia.org/wiki/One-way_compression_function), which outputs a 128-bit hash (pre-configured link key).

1671989882604.png <sigh>

Update:
Zigbee 3.0 (going forward) silently ignores the request to join the network if a device attempts to authenticate using the well-known ‘ZigBeeAlliance09’ trust center link key.
https://www.digi.com/resources/documentation/digidocs/pdfs/90001539.pdf
older?: https://www.digi.com/resources/documentation/Digidocs/90001942-13/Default.htm
https://serdmanczyk.github.io/XBeeAPI-PythonArduino-Tutorial/
 
Last edited:
Back
Top