Add new SubGHz protocol: Hormann BiSecur #118
Conversation
user890104
requested review from
Willy-JL,
Sil333033,
HaxSam and
MatthewKuKanich
as code owners
|
the protocol seems to work quite well, managed to pick up just fine from the raw recording, well done! might be a good idea to include this frequency in default list? i had to add it manually to be able to pick it up, the closest one in default list is 868.35 which doesnt catch it... i changed the hash data function to make a 32 bit hash, we have this in momentum and xfw (maybe rm, not sure if he took that) because we use hashes for detecting duplicates and 256 values is a bit too little and causes false collisions of hashes. also seems like unfortunately you got the short end of the stick with how the whole subghz protocol framework is designed, its all based around a 64bit data buffer so i see you had to duplicate the code for serializing and deserializing in order to save more than that... this is not ideal for 2 reasons, 1 because we are short on internal flash memory and reusing existing code saves some bytes, and 2 because we have additional logic in the default behavior to save coordinates of signals if user has a gps module. reworking the whole framework would not be feasible due to compatibility, so i think the easiest solution would be to use the generic function, and the overwrite the Key value it saved... ill try to get that working shortly |
|
i made the change mentioned above, it seems to work fine for me. ill wait to merge in case you want to discuss this further. and thank you! |
|
Thanks for the review and the fixes. Feel free to merge it. |
What's new
This is a garage door remote protocol. It uses 2FSK at 868.276 MHz center frequency with a bandwidth of about 25 KHz. There are 3 types of preamble data, then the actual bytes are encoded using G.E.Thomas Manchester encoding. The first byte is the protocol type, the next 4 are the remote's serial number, then there are 16 encrypted bytes, and finally a one byte CRC-8 checksum. The encrypted bytes are using AES-128 but with a bit of obfuscation before and after the encryption, and probably contain the rolling code counter. Both an encoder and a decoder are implemented, the signal can be decoded in real time during SubGHz Read operation. It can be decoded later from a Read RAW file. Saving and loading the decoded result is also possible.
A future improvement will be the ability to capture the unencrypted seed and counter. There is a cloning feature of the remote, which is supposed to transmit these unencrypted (using OOK), so the replacement remote can learn them and configure itself. It would be probably implemented as a separate app. Including the seed and the counter inside the .sub file will make it possible to generate the next code in the sequence automatically.
More information: https://tib.flowcenter.de/mfc/medialink/3/deb1359464e0b867ef1d0e0c18700c3516f1174e5066a73086af5e8c9374b7a741/6134c3-9029-uncovering_vulnerabilities_in_hoermann_bisecur.pdf
For the reviewer