search

Bluetooth-Devices / bthome-ble

Parser for BTHome BLE devices
https://bthome.io/
MIT License
64 stars 11 forks source link

Changing batteries in thermometer breaks encrypyion #116

Closed Komzpa closed 1 month ago

Komzpa commented 3 months ago

Describe the bug I looked at some gaps in my data and decided to change batteries in some of my pvvx-firmware flashed thermometers. After that they did not come back.

To Reproduce

Logger: bthome_ble.parser Source: components/bthome/init.py:48 First occurred: March 19, 2024 at 7:15:41 PM (4875 occurrences) Last logged: 12:42:54 AM

bed in-side CB9C: The new encryption counter (148) is lower than the previous value (154553). The data might be compromised. BLE advertisement will be skipped. entrance 48 7E17: The new encryption counter (194) is lower than the previous value (67117068). The data might be compromised. BLE advertisement will be skipped. nook 02CD: The new encryption counter (33221) is lower than the previous value (3103785729). The data might be compromised. BLE advertisement will be skipped. bed in-side CB9C: The new encryption counter (149) is lower than the previous value (154553). The data might be compromised. BLE advertisement will be skipped. plant shelf 531B: The new encryption counter (4723) is lower than the previous value (1642324699). The data might be compromised. BLE advertisement will be skipped.

Additional context Probably need to reset encryption counter if there haven't been a correct value in last couple measurements/seconds? I've seen a note that only overflow is allowed for now, maybe it's ok to allow low values for restarting the sequence too.

Ernst79 commented 3 months ago

Just restart Home Assistant and it should be fine again.

Komzpa commented 3 months ago

I restarted Home Assistant, this helped. However the issue seems to re-occur still:

image

image

image

It looks like voltage of the battery dipped once below good level, device rebooted and never came back in HA. I would love to be able to use these batteries a bit longer, they're reporting that they're 100% and device seems to work fine with just occasional hiccups.

Komzpa commented 3 months ago

The issue unfortunately continues to plague my setup.

image

Ernst79 commented 3 months ago

So, the issue isn't the battery change (as you can fix that with a restart of HA, and will only occur once every one or 2 years). But the problem is more related to the fact that the sensor becomes out of range, e.g. due to low battery voltage (which can happen due to low temperature for example).

In the PR you propose. you allow for the encryption counter to be lower than the previous value once, to allow for this situation, right?

Komzpa commented 3 months ago

Yes. I bought a bunch of sensors from aliexpress and they came with 80-90% alive batteries. I assumed initially that the batteries in them died completely or below some level where they are not sending bluetooth anymore. However when I was changing batteries devices looked fine, and later the issue got repeated even on new batteries.

I will be slowly debugging the pull request as I learn how it all works here, I will not mind if someone picks it up before me either.

I allow a reset once per 100 advertisements, so if someone does a replay while main sensor is alive it will get jammed, but if there's only one on the line it won't. However if the counter resets in principle this means attacker can record high-counter advertisements (even one) and use them to jam low-counter real device, even now. Maybe it's worth disabling this protection at all for now and if needed maybe address it in v3 or later with tracing full state machine of the possibilities, and treat encryption as enhanced CRC instead until then.

thecode commented 3 months ago

@Komzpa my experience with sensors from AliExpress was that they sometime have old or cheap batteries that won't last long, but if I understand correctly you already replaced the batteries. Can you add a link to the sensor which is making you problems? I can try to order one to understand if it is an hardware issue and if there is a way to improve it.

Komzpa commented 3 months ago

@thecode these are LYWSD03MMC with pvvx firmvare 4.7 and BTHomev2 + encryption enabled. The listing I ordered from is not up anymore but it was 10-pack from this store: https://aliexpress.ru/store/5064078, devices feel legit. I replaced the batteries in three of them, I see that it did not solve the issue in them so I stopped replacing batteries for now.

If I disable encryption my HA starts hallucinating new sensors at those devices supposedly due to some bit flips. Could it be that some CRC is not being checked on some other level? I see there is supposedly three octets of CRC on this diagram and that should kinda be enough to reject faulty messages? image

Komzpa commented 3 months ago

Findings of this weekend:

Ernst79 commented 3 months ago

The encryption part is also a bit out of my knowledge field. We use the same type of encryption as xiaomi-ble / xiaomi MiBeacon. But that is due to my limited knowledge, we just copied that more or less.

thecode commented 3 months ago

@Komzpa I have the same device from same seller, but didn't flash it with custom firmware, I will try to flash with pvvx firmware this weekend and report back.

The CRC is part of the Bluetooth receiver, not of this project, as far as I understand if the CRC is incorrect the receiver will drop he packet.

Komzpa commented 2 months ago

I'm running https://github.com/Bluetooth-Devices/bthome-ble/pull/119 for 5 days on my system without issues. I hope that can be reviewed and merged.

Ernst79 commented 2 months ago

@thecode you mentioned that you were going to do some tests, did you had time to do that? Can we merge the PR #119 ?

thecode commented 1 month ago

Sorry, I somehow missed this comment, I think it is good

Ernst79 commented 1 month ago

Should be fixed in 3.9.3