The 2.4GHz protocol is likely Zigbee related

[hdurdle]

I found the FCC test report for the connected flap: https://fccid.io/XO9-IMPD00003

The main report https://fccid.io/XO9-IMPD00003/Test-Report/Test-Report-3666579

This lists the "intentional radiators" in the kit, namely the RFID at 126 and 133 kHz, and the 2.4 GHz radio for transmitting to the hub. That is listed as 802.15.4 using O-QPSK modulation. https://en.wikipedia.org/wiki/IEEE_802.15.4

That's Zigbee - or at least something close to it. With the right SDR setup we may be able to decode the frames.

Plenty more detail in the FCC filing.

[freekeys]

Love this! How’s it going?!

[vm00z]

Hi there! Just got started dissecting the hub to gain more hardware/IoT knowledge. The hub that I have is model 00313-FG_05 and the wireless chip is MRF24J48MA. A quick Google search shows this Microchip product: https://www.microchip.com/wwwproducts/en/en027752, which basically confirms the use of ZigBee. I'm curious to decode the communications between the hub and door, see what information gets transported back and forth. Since I have little experience with the SDR/RF blah, it might take me a bit. I'll be sure to share anything I find 😸

[hdurdle]

Excellent - I never did get to investigating the Zigbee protocol myself, so will be very interested to see what you find. Good luck!

[wicol]

This is way over my head really, but do you think it would work to just pair it with a zigbee stick/hub and se what data comes in..? Or do you think they're doing something special in their zigbee communication?
I'm running a conbee + deconz REST service, and I'm thinking of buying a flap, perhaps without the hub to start..

[jandechent]

Hi, Im also investigating here. Did any of you manage to connect to a flap without Hub?

[wicol]

No, I didn't find any real pairing button on the flap and my conbee didn't say anything 🤷
But I didn't even manage to pair an ikea button either so who knows what's going on with my conbee...

[MadMonkey87]

I don't have a hub only the connect cat door. Does anyone know how the setup process of the hub works i.e how the pairing between the hub and the door gets iniciated?

[dwmw2]

Since I have little experience with the SDR/RF blah, it might take me a bit

Perhaps just sniff the SPI traffic from the CPU to the wireless chip? Whether it's ZigBee or a custom protocol, it should be relatively easy to follow at least the basic communication.

[dwmw2]

See also https://www.zigbee2mqtt.io/how_tos/how_to_sniff_zigbee_traffic.html

[staebchen0]

Hello, I would also be very interested in the topic.

That would be the fastest way to address the flap.

The question is, could you also lock and unlock the flap over it?
Or is only the chip code verified?

did you manage to decode the communication between the hub and the door?

[dwmw2]

I haven't tried yet. But it may well be possible to play man-in-the-middle. To the existing hub, you pretend to be a catflap. And to the catflap, you pretend to be a hub. And you just sit in the middle repeating what they say to each other.

It would be great to be able to talk to the catflap directly without needing to use the hub. I'm sick of my kitten's nightly curfew actually depending on the Internet connection being up, and on a web service that sometimes doesn't accept mode changes.

[staebchen0]

yes, that would be fantastic!
let me know when you find a way!

[koenbulcke]

Hi,

Got here through some Googling, basically, I think we are looking for the same; to pair&detect Sureflap actions through an USB based Zigbee/802.15.4 radio.

I wrote down my findings here: Koenkk/zigbee2mqtt#3261

Basically, in Wireshark, I see some stuff passing by, I'm a bit stuck what t do with it. I am "happy" to read that you confirm it is Zigbee based communication but the sniffing logs seem to indicate something else?

Cheers,

[koenbulcke]

From https://elinux.org/images/7/71/Wireless_Networking_with_IEEE_802.15.4_and_6LoWPAN.pdf , I saw that the following protocols run over 802.15.4 :

• Zigbee–Zigbee Alliance's mesh networking protocol
• MiWi Mesh and MiWi P2P–Microchip's proprietary mesh and P2P protocols
• 6LoWPAN–IPv6 over 802.15.4
• WirelessHART–Industrial Automation
• ISA100.11a–Manufacturing, Control, Automation

[koenbulcke]

think I found out the protocol, just checking now

[madgino]

think I found out the protocol, just checking now

Hi Koenbulcke,

Did you manage to get anywhere with the protocol

[koenbulcke]

Hi madgino,

Well only slightly, ; found out that the chipset used is likely from Microchip and the upper layer 802.15.4 protocol being "MiWi P2P" , see attached for the "MiWi P2P" spec vs a cap from Wireshark to illustrate my finding.

Data sheet and information on the Microchip website:
https://www.microchip.com/mplab/microchip-libraries-for-applications
https://microchipdeveloper.com/led:miwi-protocol

Didn't had time thought to see further if there exists anything for Linux that can "talk" 802.15.4 or one needs to purchase a Microchip controller could do this?

Cheers,

[willumpie82]

Maybe it makes more sense to investigate possibility to change the wireless mifi transceiver to an esp wifi controller, did anyone have a look at the wireless module in the door unit? Is it the bare mifi mrf24 controller or also e.g a pic32 + mrf24?

Edit: I had a look at the fccid docs and the wireless chip is connected to an stm arm controller (not enough pixels in the pdf to properly identify the parts). But looks promising

[plambrechtsen]

I was looking into this as well, but more from the MITM from the receiver to the mothership rather than trying to simulate the wireless protocol.

When it first booted it did a firmware upgrade and hit http://hub api surehub io/api/firmware
With a url encoding post of "serial_number=sn&page=xx&bootloader_version=1.177"
Then it downloads 76 payloads with similar headers and no clear strings in it so it looks like it was compressed or encrypted.

It seems like it happily supports a self signed cert. Phones home to 'hub api surehub io' and does a POST /api/credentials with a url encoded of the serial number:
serial_number=xxx&mac_address=xxx&product_id=1&firmware_version=x.xx
The response comes back with a device specific UUID, the AWS IOT MQTT endpoint
v02:deviceuuid:::1:v2/production/deviceuuid:awsiotendpoint.iot.us-east-1.amazonaws.com:MII..."
The data after the endpoint hostname looks on first glance like a certificate but it isn't, I think it is some sort of encrypted and signed data.
Then when it connects to AWS it also happily accepts a self signed, but it connects to AWS with a client cert and AWS won't accept any other IOT cert when connecting to the device.
But I see it again doing a MITM decrypt hitting a topic of:
Client ID: deviceuuid
Will Topic: v2/production/deviceuuid/messages
Will Message: "Hub has gone offline"

Ideally I would like to know what the response in the first api/credentials should be, as I think it is used for either the certificate to be transferred or setting time and such like, as each time it boots sections of it remain the same and others change including the end which looks like the payload is signed.
Then what topics are required to drive the doors and feeders.
I might just try pointing it to a local mtls mqtt host and see what I can poke into it.

Suggestions on how to decompile the PIC32 code?

[tinuva]

I have a screenshot from the app on what to do, when pairing pet flap to the hub.

[mretallack]

Hi,

I have a working app that can monitor my SurePet feeder. This uses the same protocol as the sureflap, but with different messages. It runs on a Pi with a BeeClick.

The code is:

https://github.com/mretallack/catfeeder

Mark

[kadzsol]

Would it be possible for someone having a flap and a hub to make some sniffs what I can study? I would be interested in at least 2 scenarios:

1. pairing flap and hub
2. exchanging some data (e.g. reading out pet state?)

To make the sniff you can use cc2531 with TI sniffer on channel 15: https://www.ti.com/tool/PACKET-SNIFFER (version 1)

[plambrechtsen]

Would it be possible for someone having a flap and a hub to make some sniffs what I can study? I would be interested in at least 2 scenarios:

1. pairing flap and hub

2. exchanging some data (e.g. reading out pet state?)

This has already been done with figuring out the pairing and unpairing process as well as I have mostly figured out the xor key. And I am fairly close to figuring out how the crc is calculated but have been working on the cloud replacement sticking with the existing hub and redirecting dns.

https://github.com/plambrechtsen/pethublocal

And specifically this is for pairing.

https://github.com/plambrechtsen/pethublocal/blob/3487bf5c49de099ced4ae8c802086fe1000d63ae/WemosPetHub/src/main.cpp#L257

And Mark's code also has the pairing process working after I took a trace and shared it with him.

[heisenberg2980]

Did anyone have any luck sniffing the traffic between the hub and the flap? @plambrechtsen is trying to see if the hub latest firmware (233.364) can be downgraded, but it might be also worth exploring the posibility of integrating the flap into a zigbee network so the hub is not required anymore.

[heisenberg2980]

As I have mentioned here PetHubLocal/pethublocal#23 (comment), I have done a small test disconnecting the sure hub, then enabling the "permit join" in my zigbee2mqtt and then putting the flap in pairing mode (which according to the Sure app just requires to click the settings button located at the left of the flap), and unfortunately the flap has not joined the zigbee network (1st step of the guide https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html), so it seems they have changed the protocol enough so that it is not recognised by the zigbee coordinator, which is a pity because it would have been the easiest solution.

[ChristophCaina]

As I have mentioned here PetHubLocal/pethublocal#23 (comment), I have done a small test disconnecting the sure hub, then enabling the "permit join" in my zigbee2mqtt and then putting the flap in pairing mode (which according to the Sure app just requires to click the settings button located at the left of the flap), and unfortunately the flap has not joined the zigbee network (1st step of the guide https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html), so it seems they have changed the protocol enough so that it is not recognised by the zigbee coordinator, which is a pity because it would have been the easiest solution.

Hi @heisenberg2980,
I write here, because I faced severe issues with my zigbee network (I'm using ZHA from HomeAssistant) after pairing my SurePetcare flap with their Hub.

For me, the information here helped to probably narrow the issue down to the flap itself, because the issues started shortly after the pairing was done - and remained, even if the hub itself was powered off.

So if someone here can help me and guide me a bit on how to get relevant information to make the ZHA and my coordinator more robust against the SurePetcare flap - or, if possible to provide relevant data that the device could be implemented into ZHA, I would really appreciate any kind of suport on this topic :)

Thanks and sorry for Hijacking this topic

[heisenberg2980]

@ChristophCaina to confirm that your issue is the catflap you can disconnect the hub and also remove the batteries from the catflap to see if your issues dissapear. If you do the test couple of times and confirm the issue dissapear when the catflap is off and reapear when it´s on, then I would say your catflap must be using the same channel than your zigbee network, and if so you could solve the issue by changing your zigbee network to a different channel (not sure how that is done in ZHA as I use Z2M). Just be aware changing the channel will require to repair all your zigbee devices

[ChristophCaina]

Hi,
I already removed the Batteries and first it appeared that my zigbee Network came back...

Unfortunately, later today the issues started to come back :-(

I noticed an increased amount of issues with zha were reported the last couple days and it appears, that the Developers have rolled Out some Changes in recent ha Versions that might also be related.
But I haven't recognized these issues with the Versions mentioned in These Reports, and rolling Back to several older Versions didn't Change that.

Anyway, thanks for your time.
And I hope, that my issues will resolve sooner than later... There are no Important deviced affected, and resetting them (remove Power) seems to Help for some time - but it becomes inconvenient

[heisenberg2980]

My advise would be to move your zigbee network to Z2M as I believe it is a better option in terms of stability and also number of devices and entities supported, maybe you can give it a try now that ZHA is giving you some troubles

[plambrechtsen]

The pet hubs support 3 frequencies and they can be set via the console if you are running the old firmware (which if you had it connected to the internet for the last year is unlikely).
So you could try moving channels on your Zigbee and if you have a 2.4g wifi move it to channel 11 as that is less likely to interfere as the default channel for the pet hub is zigbee channel 7 from memory.