LFRFID Securakey: Add Support for RKKTH Plain Text Format

[zinongli]

What's new

• As the title says, now the same code supports one more format of Securakey's RadioKey: RKKTH. The previous support was only for RKKT.
• This format is not found in PM3’s repo but can be decoded from raw readings of RKKTH fobs.
• This new format’s encoded data is shorter than RKKT (the format that’s already supported). So the decoder buffer size doesn’t change. But encoding will differ in bit length according to the exact format (RKKT: 96bit, RKKTH: 64bit).
• Since this format of RKKTH doesn’t include facility number, decoded data will have all zeros in its facility code section (byte 0 and 1), which will be the condition the encoder will examine before deciding which format to encode in.
• There isn’t any change in the existing support for RKKT fobs. Existing files are readable, emulatable, and writable. This update ensures backward compatibility.
• Some side note:
  • This issue was raised only 8 hours after the initial introduction of the protocol’s support. The exposure led to the discovery of this new undocumented format. PM3 has been supporting RKKT for 6+years and this never happened. This discovery in reverse engineering relies on the popularity of Flipper Zero and the amazing community. It’s a wonderful thing to happen.
  • This improvement would not be possible without the support from @EricRibeiro. The debug process had been difficult and required tons of back and forth between edits and testing. Eric owns the key fobs and reader, I don’t. So thank him for flashing and testing 10+ versions and being so helpful and responsive the entire time.
• Why call it plaintext? Because any of the four formats stated on their website are Wiegand variations. But the readings from Eric's fob and LF-RFID Support for RadioKey/Securakey #2619's OP's raw reading both contains nothing in regards to parity bits. It's just plaintext laying in there.

Verification

• I believe @skotopes have received raw readings from Eric previously. Reading function can be tested with rfid raw_analyze in CLI. Otherwise, a genuine RKKTH fob and reader are required for testing. Eric has access to two fobs and one reader. I was told reading, emulation, and writing all works for both fobs. He has suggested me requesting him to be the reviewer but I haven't figured out how. Any help is appreciated.
• @hi-im-vika I believe your fobs is also transmitting in RKKTH format based our conversation on discord. Would you mind sharing the results here if you managed to test it on your end?

Checklist (For Reviewer)

• PR has description of feature/bug or link to Confluence/Jira task
• Description contains actions to verify feature/bugfix
• I've built this code, uploaded it to the device and verified feature/bugfix

[EricRibeiro]

I've tested reading, writing, and emulation with an RKKTH tag, and everything is working perfectly. Thanks for the excellent work! 🎉

[hi-im-vika]

@zinongli I can confirm that this works perfectly for me, for scanning and emulating. Thank you for your hard work!!

[skotopes]

@zinongli thank you for your hard work. Really awesome to see new protocols implemented by community