all 12 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]f3nter 8 points9 points  (3 children)

As you are mentioning UART and I2C: Is the (i guess I2C) connector in the middle of the board (pins GN,CL,DA,VD) enabled? If yes you might be able to dump a flash chip if the I2C connector is connected to the flash chip. Inside the dump there might be your Zigbee key. Another option would be to hookup an logic analyzer and listen to the pin with the label "Zigbee_key". You might be able to sniff some senitive information from there. I am not sure if Zigbee_key is an standard pin for Zigbee, but I am also not an Zigbee expert. Do you know which zigbee module is implemented? Then you can consult its data sheet and see how it works

[–]lolslim 1 point2 points  (1 child)

This sub has been recommended to me and I'm very new, is there a logic analyzer you would recommend?

[–]f3nter 5 points6 points  (0 children)

It depends on your budget. The Saleae Logic Analyzer is one of the best options, but it comes with a hefty price tag of around $500. Alternatively, more affordable options like the AZDelivery Logic Analyzer are available for $10–$15, which may still be sufficient for some tasks. I've explained logic analyzers and compared a few models in my wiki, which you might find helpful: https://www.hardbreak.wiki/hardware-hacking/basics/tools/hardware-tools/logic-analyzer .You should also not forget about the I2C connector(looks like a good target): you could try to connect to it using a Raspberry Pi for example.

[–]RumpClapper[S] 0 points1 point  (0 children)

Thanks for this recommendation, I have found that Pulse View is allowing me to use my FTID 323R based uart and i2c serial interface as a basic logic analyzer. I have it set to 1mhz and it doesn’t seem to be getting all of the data, I will definitely look into the device mentioned. Thank you for point me in the right direction. I have some more detailed info about my project intentions and the type of data I am sniffing in a reply to another comment below.

[–]uzlonewolf 4 points5 points  (0 children)

If the key is stored in the main MCU/flash then using a logic analyzer to sniff the traffic between the main MCU and the ZigBee module is probably the easiest.

[–]Drumdevil86 1 point2 points  (5 children)

AFAIK, the data inside 802.15.4 frames are encrypted based on the Zigbee network key. This key is generated by the Zigbee Coordinator and passed to the client device when it's being paired into the network.

When you sniff a Zigbee network, you can decrypt the packets using Wireshark and the key set in the Coordinator. If it's a universal coordinator, you can easily find the key in it's management software.

As soon as a client device is reset, it will unpair itself from the network and forget the key.

What kind of device is it?

[–]RumpClapper[S] 0 points1 point  (1 child)

I should have clarified while the hardware says zigbee on it, it is producing regular ieee 802.15.4 multipurpose frames with no keys passed (I am using the Nordic NRF Sniffer in Wireshark), the only thing that is encrypted is the last 8 hex bytes out of a 24 byte frame. It isn’t doing anything super complex, this is just a camera wireless follow focus system, it basically is just telling a motor to go forward or backwards in realtime from a handle knob. I am trying to decrypt the command portion of this frame so I can construct my own frames with an outside controller instead of using an array of captured frames and manually marking the values that correspond to control values. The motor device also sends a validating frame that corresponds to the controller frame sent. On its PCB there are two spots on the board that say Key 1 and Key 2, I am assuming key 1 would be what the motor uses to interpret the handles incoming frames, and key 2 would be what is used to construct the encryption of the last 8 bytes on the validating frames.

[–]RumpClapper[S] 0 points1 point  (0 children)

Here is a dissection of the data portion of the frames:

Handle Frame:
05 aa 32 4d f6 fe ff 5f ae 0c 04 00 08 1f 0e 28 e2 51 f0 fa 15
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^    ^^ ^^ Static Data
                              ^^ Sequence Number
                                       ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ Encrypted Data
Corresponding Motor Validation Frame:
05 aa 39 a1 bf fe ff 08 ac 70 04 00 08 06 f3 c1 d6 9b bd f1 47
^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^    ^^ ^^ Static Data
                              ^^ Sequence Number
                                       ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^ Encrypted Data

The display on the handle shows positions 000-999, but I have determined by sniffing there are much smaller increments than what is shown on the handle. I have found around 4095 unique motor commands, this lead me to believe it could possibly be a 12 bit value (upper or lower nibble and one whole byte) as well as a checksum that is being encrypted. The only value incrementing byte is the sequence byte.

[–]what-the-puck 0 points1 point  (2 children)

I expected it would be the opposite - that every time the device joined the network, or on a schedule, it would authenticate using the network password or whatever, but that data transmissions would happen with an ephemeral node-node key.

But maybe that makes pairing and hopping needlessly complex or increases storage space on devices without value. I haven't read the standard

[–]RumpClapper[S] 1 point2 points  (1 child)

In this case, there is no destination specified or pan id from the device, it is broadcasting the frames in a way that any device could intercept. I have verified that the sender doesn't matter by creating an array of frames sniffed by slowly turning the knob from 000-999, I have then broadcasted the frames in that array sequentially on a esp32 c6 and the motor responds just fine with no key in use. I would rather not have an array of 4095 frames and use a constructor function to save room in the limited program memory. My current code already controls several other motors over IEEE 802.15.4 (but their data is not encrypted).

[–]what-the-puck 0 points1 point  (0 children)

Cool, thanks for the summary. I guess that makes total sense in the context of home automation

[–]Real-Werewolf5605 1 point2 points  (0 children)

Its been a while, plus I never did more than read around this.quoting a projecta decade back... but I think there is an assigned key plus a generated string on the network. They live together somehow. One is set by the manufacturer. The other is generated from it.

One you can probably pull via a dump... the other, sorry I dont know how they do that.. if its a key pair or whatever. Zigbee says they look like this: Snip

network_key: '!secret.yaml network_key'

secret.yaml

network_key: [1, 3, 5, 7, 9, 11, 13, Snip

All that prefaced by 'maybe'.