Local backend for sureflap protocol messages into mqtt.

[plambrechtsen]

Following on from this post, I thought I should create a new issue: https://github.com/alextoft/sureflap/issues/8#issuecomment-727288100

Hopefully sureflap don't go and close this hole off as the fact they don't validate CAs is brilliant should you want to run your own backend.

I setup a mosquitto backend with the aws api endpoint bouncing via PolarProxy to do the ssl decoding into a pcap.

Seems that it creates topics based on the mac addresses of devices connected in reverse byte order.

v2/production/hubuuid/messages/devicemac

The first message that comes through it:

Hub has gone offline 5fb08bc7 0220 Hub online at 15 2 0 39

The first value is hex for the utc timestamp, then 0220 seems to be a message counter.

Anyone else interested in decoding the protocol and building a local client?

Then figuring out what the /api/credentials is supposed to contain.

[FeLLa-23]

Hello, I hope I'm not too late on this Topic!

I'm very interested to get this IoT device working without the hub/cloud, even if it is not possible to rebuild every functionality.

So, few days ago I started on my own on gathering data about the devices internals (I own the catflap, feeder and hub). My first thought was to sniff the IEEE_802.15.4 protocol and check if the data is encrypted or not. This was easily done with a flashed CC2531 and whsniff. The devices sending on channel 15 and the protocol was identified as "LWmesh" by Wireshark.

Next step was to write an filter with the needed data fields and sniff a few days. For this I used:

tshark -i <( /usr/local/bin/whsniff -c 15 ) -Y lwm -o data.show_as_text:TRUE -T fields -e frame.number -e frame.time -e wpan.src64 -e wpan.dst64 -e wpan.src16 -e wpan.dst16 -e _ws.expert.message -e data.data -E separator=";" > output.csv

The result can be seen in the screenshot below (Hub: b1:d9:6d:fe:ff:12:1f:80, Feeder: 70:b3:d5:f9:c0:00:9d:06, Flap: 70:b3:d5:f9:cf:00:fb:14): (The two empty columns is the short identifier and just used in the upper layer's IEEE_802.15.4 messages).

At the moment I collect data over the next days for reversing the protocol and in the meantime I did some research on the documentation of the used microchips, because apart of the MITM approach, maybe it is possible to dump the firmware or getting acces on some kind of debugging console.

So, these are my first attempts before I've found this thread and I hope we can share our findings and getting full access over our devices.

Greetings!

[Hoefnix]

Hello, I hope I'm not too late on this Topic!

I'm very interested to get this IoT device working without the hub/cloud, even if it is not possible to rebuild every functionality.

So, few days ago I started on my own on gathering data about the devices internals (I own the catflap, feeder and hub). My first thought was to sniff the IEEE_802.15.4 protocol and check if the data is encrypted or not. This was easily done with a flashed CC2531 and whsniff. The devices sending on channel 15 and the protocol was identified as "LWmesh" by Wireshark.

Next step was to write an filter with the needed data fields and sniff a few days. For this I used:

tshark -i <( /usr/local/bin/whsniff -c 15 ) -Y lwm -o data.show_as_text:TRUE -T fields -e frame.number -e frame.time -e wpan.src64 -e wpan.dst64 -e wpan.src16 -e wpan.dst16 -e _ws.expert.message -e data.data -E separator=";" > output.csv

The result can be seen in the screenshot below (Hub: b1:d9:6d:fe:ff:12:1f:80, Feeder: 70:b3:d5:f9:c0:00:9d:06, Flap: 70:b3:d5:f9:cf:00:fb:14): (The two empty columns is the short identifier and just used in the upper layer's IEEE_802.15.4 messages).

At the moment I collect data over the next days for reversing the protocol and in the meantime I did some research on the documentation of the used microchips, because apart of the MITM approach, maybe it is possible to dump the firmware or getting acces on some kind of debugging console.

So, these are my first attempts before I've found this thread and I hope we can share our findings and getting full access over our devices.

Greetings!

You effort is greatly appreciated. For now, because of the lak of an alternative, I retrieve the information on de server for any changes in the status. I works well, but I would prefer a more 'internal/local' solution.

Regards

[mretallack]

Hello, I hope I'm not too late on this Topic!

I'm very interested to get this IoT device working without the hub/cloud, even if it is not possible to rebuild every functionality.

So, few days ago I started on my own on gathering data about the devices internals (I own the catflap, feeder and hub). My first thought was to sniff the IEEE_802.15.4 protocol and check if the data is encrypted or not. This was easily done with a flashed CC2531 and whsniff. The devices sending on channel 15 and the protocol was identified as "LWmesh" by Wireshark.

Next step was to write an filter with the needed data fields and sniff a few days. For this I used:

tshark -i <( /usr/local/bin/whsniff -c 15 ) -Y lwm -o data.show_as_text:TRUE -T fields -e frame.number -e frame.time -e wpan.src64 -e wpan.dst64 -e wpan.src16 -e wpan.dst16 -e _ws.expert.message -e data.data -E separator=";" > output.csv

The result can be seen in the screenshot below (Hub: b1:d9:6d:fe:ff:12:1f:80, Feeder: 70:b3:d5:f9:c0:00:9d:06, Flap: 70:b3:d5:f9:cf:00:fb:14): (The two empty columns is the short identifier and just used in the upper layer's IEEE_802.15.4 messages).

At the moment I collect data over the next days for reversing the protocol and in the meantime I did some research on the documentation of the used microchips, because apart of the MITM approach, maybe it is possible to dump the firmware or getting acces on some kind of debugging console.

So, these are my first attempts before I've found this thread and I hope we can share our findings and getting full access over our devices.

Greetings!

Hi, Would it be possible to provide the raw capture file? specificity any beacons? I have a surepet device but no hub. I have been looking at the protocol and it appears to be based on Microchip MiWi and I just need to see the initial handshake sequence.

[plambrechtsen]

Hi, Would it be possible to provide the raw capture file? specificity any beacons? I have a surepet device but no hub. I have been looking at the protocol and it appears to be based on Microchip MiWi and I just need to see the initial handshake sequence.

Are you sure you have the surepet "Connect" version? As that has the MiWi controller in it. As the standard non-Connect range doesn't include it.

[mretallack]

Hi, Would it be possible to provide the raw capture file? specificity any beacons? I have a surepet device but no hub. I have been looking at the protocol and it appears to be based on Microchip MiWi and I just need to see the initial handshake sequence.

Are you sure you have the surepet "Connect" version? As that has the MiWi controller in it. As the standard non-Connect range doesn't include it.

Yes, I got the "Connect" version without the hub, it was a cheaper option. The idea is that I could get the hub later if I don't manage to reverse engineer the protocol or if the protocol is using security options.

I can already sniff the beacon packet sent once the "setup" button is pressed and have made a start of creating a beacon response frame to start the handshake sequence, however it would be good to see a correct version. The Frame Control field is a bit confusing (a mixture of endian and the code etc...).

[plambrechtsen]

Yes, I got the "Connect" version without the hub, it was a cheaper option. The idea is that I could get the hub later if I don't manage to reverse engineer the protocol or if the protocol is using security options.

I can already sniff the beacon packet sent once the "setup" button is pressed and have made a start of creating a beacon response frame to start the handshake sequence, however it would be good to see a correct version. The Frame Control field is a bit confusing (a mixture of endian and the code etc...).

The hubs use MiWi and not Zigbee at all. I have just got a CC2531 to capture the traffic and after the 802.15.4 frame it is completely different. Some documents from Microchip talking about the protocol: http://ww1.microchip.com/downloads/en/DeviceDoc/MiWi-Software-Design-Guide-User-Guide-DS50002851B.pdf http://ww1.microchip.com/downloads/en/Appnotes/00001283B.pdf https://ww1.microchip.com/downloads/en/DeviceDoc/00001204C.pdf http://ww1.microchip.com/downloads/en/appnotes/an1066%20-%20miwi%20app%20note.pdf https://microchipdeveloper.com/led:miwi-protocol

If you look at the frame:

But the byte stream is:

08 fe 00 a6 01 2e 00 3c f7 01 00 05 00 00

So the first byte is the Frame Control, then sequence number as per the first PDF I posted on page 8.

So you'll need to build a whole new gateway to talk something other than zigbee to make it work. So I recommend just getting a hub as that will be cheaper and quicker... And if you do let me know as I would like to sniff all the traffic on the first boot.

[mretallack]

Yes, I got the "Connect" version without the hub, it was a cheaper option. The idea is that I could get the hub later if I don't manage to reverse engineer the protocol or if the protocol is using security options. I can already sniff the beacon packet sent once the "setup" button is pressed and have made a start of creating a beacon response frame to start the handshake sequence, however it would be good to see a correct version. The Frame Control field is a bit confusing (a mixture of endian and the code etc...).

The hubs use MiWi and not Zigbee at all. I have just got a CC2531 to capture the traffic and after the 802.15.4 frame it is completely different. Some documents from Microchip talking about the protocol: http://ww1.microchip.com/downloads/en/DeviceDoc/MiWi-Software-Design-Guide-User-Guide-DS50002851B.pdf http://ww1.microchip.com/downloads/en/Appnotes/00001283B.pdf https://ww1.microchip.com/downloads/en/DeviceDoc/00001204C.pdf http://ww1.microchip.com/downloads/en/appnotes/an1066%20-%20miwi%20app%20note.pdf https://microchipdeveloper.com/led:miwi-protocol

If you look at the frame:

But the byte stream is:

08 fe 00 a6 01 2e 00 3c f7 01 00 05 00 00

So the first byte is the Frame Control, then sequence number as per the first PDF I posted on page 8.

So you'll need to build a whole new gateway to talk something other than zigbee to make it work. So I recommend just getting a hub as that will be cheaper and quicker... And if you do let me know as I would like to sniff all the traffic on the first boot.

Yes, I have created a "wrapper" around the microchip MiWi protocol stack to run on a Pi. So far it receives the MiFi Beacon packet and generates a reply as per the MiWi protocol, however the Feeder ignores the reply.

The code is here:

https://github.com/mretallack/catfeeder

Mark

[plambrechtsen]

I have just posted my code here: https://github.com/plambrechtsen/pethublocal