I'm REing the Bluetooth protocol for the Ecoflow Delta 2 power station, and so far I've had some success. But there's a strange behaviour that, while not hampering my efforts, has me puzzled.
The packets come as a 16 byte header, a variable length payload, and a 2 byte CRC. The header contains the sorts of things you would expect: a magic number, payload length, and message type. But there's a 1-byte field that is used to XOR the payload. Most of the time this field is 0, but there are occasional runs of 0x34, 0x25, and rarely 0x28. I've not observed any other values, but they might occur. The CRC is calculated based on the raw payload, not the cleartext version.
I'm struggling to figure out why the designers should have done such a thing. It can't be for encryption because the field is 0 more often than not. It can't be for error-checking because the CRC is calculated on the "encrypted" array - and there's a CRC anyway.
There doesn't seem to be a pattern in the number of messages that are XORed either.
