Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LF-RFID Support for RadioKey/Securakey #2619

Closed
tacticalkeyboard opened this issue Apr 26, 2023 · 20 comments · Fixed by #3697
Closed

LF-RFID Support for RadioKey/Securakey #2619

tacticalkeyboard opened this issue Apr 26, 2023 · 20 comments · Fixed by #3697
Assignees
Labels
Feature Request New feature or user-story you wanna add to flipper RFID 125kHz 125, 134 kHz RFID

Comments

@tacticalkeyboard
Copy link

tacticalkeyboard commented Apr 26, 2023

Describe the enhancement you're suggesting.

I'm hoping support for SecuraKey/RadioKey can be added to the LF-RFID app.

There was a post was made in the forum here back in September:
https://forum.flipperzero.one/t/securakey/6434

I'm able to provide raw reads of my own keys. (I have 3 of them that can be tested with)

Anything else?

Just a huge thank you to the Flipper team for the consistent firmware updates. This is a great tool.

Edit. Here's a RAW read of one of the tags.
SecuraKey.zip

@hedger hedger added Feature Request New feature or user-story you wanna add to flipper RFID 125kHz 125, 134 kHz RFID labels Apr 30, 2023
@skotopes
Copy link
Member

ASK record looks good. Should be totally feasible.

@halfaura
Copy link

Hello. I was wondering if support for linear 125khz keys an/or securakey/radiokey was still being worked on?

@skotopes
Copy link
Member

Not really. We are mostly busy with NFC refactoring now, we'll be able to take close look after its completion.

@halfaura
Copy link

Thanks for responding so quickly. I appreciate all the work you guys do.

@lukzluthor
Copy link

Same here, Looking for Securakey support. Proxmark 3 has it. I would figure it would work on flipper as well.

@hi-im-vika
Copy link

Is there still work being done on this? I am interested in getting this working for my Flipper. Any tips on getting started with adding support for this (or any other raw captured data) into the firmware? I tried looking at previous pull requests for adding support for new LF-RFID devices but couldn't find anything helpful to me. I have several raw captures of my own key I can work with.

@zinongli
Copy link
Contributor

zinongli commented Jun 1, 2024

@hi-im-vika I'm also looking into this. But I am learning while doing so I'm going slowly. I found this to be potentially useful but I'm no way close to understanding how it works.

Flipper's official pulse plotter is also a useful tool. I'm learning by looking through OP's dump with it and looking into the source code.

Here's what I've learned so far and I might sound dumb because C, RFID, and Javascript are all new to me:

  1. OP's dump will be recognized as Pulse Width Modulation(PWM) with sync/delimiter on FZ pulse plotter. But PM3's Securakey decoder seems to assume Manchester modulation. I have no clue what their relationship is.
  2. PM3's Securakey decoder looks for preamble sequence 0111111111001, which I cannot find in pulse plotter's PWM output or viewing the dump with a hex editor and converting them to binary by hand.
  3. Pulse plotter's PWM output seems to be 4-bit off sometimes. For example:
    FF FF FF FD 76 5F BF FF FF FF FE BB 2F DF
    I assume the actual information is D765FB EBB2FD instead of FD765FBF FEBB2FDF. The hanging Fs probably should've been grouped with other FFs

But that's all that I've learned so far. If you'd like to chat on a more regular basis you can find me on discord @torron0483 (If attaching discord id is prohibited here please let me know and I will delete this).

@hi-im-vika
Copy link

Thanks @zinongli, I am also learning so I don't mind if it's a slow process! Here are some links on the Proxmark3 forum that I found that could be relevant:

I've seen the Manchester code mentioned a couple times while reading through the threads, but I'm not sure what it means either. The official SecuraKey white paper attached above doesn't mention PWM either, so I'm guessing it's not related?

@zinongli
Copy link
Contributor

zinongli commented Jun 2, 2024

@hi-im-vika Thank you! These are really helpful. After reading them and some trial and errors, I am suspecting if FZ have automatically performed Manchester demodulation on OP's dump already. My reasoning is below:

My understanding of the processing steps as of now is raw radio frequency -> ASK demodulation -> Manchester demodulation -> look for preamble in binary -> parse binary into hex -> done.

I assumed Securakey has preamble = 01111111110 because according to the PM3's securakey reader the sequence should start with a 0, nine 1s, and then a 0 as marker bits to separate between bytes. So a typical sequence should look like this:
0111111111 0 01011010 0 00000000 0 00000010 0 00110110 0 00111110 0 01100010 0 00001111 0 01100000 0 00000000 0 0000
I ignored the extra 01 in the end of PM3's preamble search because it's not actually content of the preamble but more of a verification of specific bit-format.

So I just looked up the preamble in the .ask.raw in binary and found 14 instances where this sequence was present. And for each instances, the bytes after the preamble would repeat for a lot of times. A sample looks like this:
'0111111111 0 11100110 0 11100110 0 11100110 0 11100110 0 11100110 0 11100110 0 11100110 0 11100110 0
So I collected the 14 instances and converted the repeating bytes into hexes. They were:
4C CE 9E C4 6C 46 7E 46 C4 E4 EE CE C4 E6

I didn't know what to make out of this. But when I tried to perform this same look up after I performed Manchester demodulation on the .raw binary file, I couldn't find the preamble anywhere. Nothing with the .psk.raw before or after Manchester demod either.

So this is why I came to the hypothesis that FZ has already performed Manchester demod on the signal, and that Securakey transmit information by repeating each byte for many times before they resume to the next byte, each repetition sequence leading by a preamble. (I could be wrong about other stuff, but the repetition should be present no matter which stage of decoding/demodulation this dump is at. A wave should always be able to pass through a linear transformation.) This format doesn't conform to the suspected format in the PM3 code at all except the preamble. I don't know what I'm doing wrong here. Please let me know if you have any ideas.

By the way, do you mind posting your dump here as well? Some comparison between keys can be really helpful for reverse engineering.

@hi-im-vika
Copy link

@zinongli Sorry, I don't want to post the dump of my keys, but I really appreciate you working on this. Thanks a lot! I've barely made any progress on my end of things 😅

@zinongli
Copy link
Contributor

zinongli commented Jun 10, 2024

@hi-im-vika I totally understand. I highly recommend the flipper-rfid-raw repository and Derek Jamison's youtube channel.

The former has a python notebook in there that might require ten minutes of small changes and setting up before you can start analyzing raw signals. It's a very automated script and it shows you the processes with graphs. It works regardless of the modulation or rf clock.

Derek has an entire Low Frequency RFID playlist that goes from time sample series to data parsing and rendering. His videos helped me a lot getting started coding for FZ.

I might be too dumb to use it, but the only help I got from Flipper lab's pulse plotter is confirming the rf clock. Nothing else. the repo mentioned at the beginning was SO MUCH more helpful and it should've been included in Flipper lab.

Also, if you got to my PR and look through my code, I left tons of comments wherever I could, so hopefully it can be a helpful reference to learn FZ developing. And since you have the fobs, might as well compile the commit and give it a try!

Please at me with whatever question you have about all these jargons and scripts. It took me a difficult time to learn this with very limited resources, so I know that feeling sucks.

skotopes added a commit that referenced this issue Jun 13, 2024
* Create protocol_securakey.c
* decode and render done
* Support for Radio Key Securakey
  Support both 26- and 32-bit format
  Solves issue #2619
* debugs and improvements
* Formatting in response to requested changes
* fixed wiegand parity bit calculation
* format
* debug unnecessary assert
* LfRfid: swap vendor and protocol names in securakey
* fixed manually generated keys issues
* fix bit length render error caused by bit length fix

Co-authored-by: あく <alleteam@gmail.com>
@EricRibeiro
Copy link

Hey folks, thanks for the great work!

I pulled in e7d0afd via the Development update channel and tried reading my Secura Key without success.

I'm wondering if anyone else was able to.

@skotopes
Copy link
Member

@EricRibeiro Securakey is actually a company name, they you bunch of different technologies and key types.
Do you know which type of key do you have?

@EricRibeiro
Copy link

EricRibeiro commented Jun 13, 2024

@EricRibeiro Securakey is actually a company name, they you bunch of different technologies and key types. Do you know which type of key do you have?

That's my bad! I have a Radio Key proximity tag:

I see on their website they have several models (RKKT-02, RKKTH-02 and RKKT-01), but I can't make out the difference visually.

@skotopes
Copy link
Member

@EricRibeiro do you have proxmark? Can you share RFID RAW files?

@EricRibeiro
Copy link

@EricRibeiro do you have proxmark? Can you share RFID RAW files?

Unfortunately, I do not own a proxmark 😔.

@zinongli
Copy link
Contributor

zinongli commented Jun 13, 2024

@EricRibeiro do you have proxmark? Can you share RFID RAW files?

Unfortunately, I do not own a proxmark 😔.

You can read raw with flipper. Turn on Debug and go RFID - Extra Actions and you'll see read raw.

Edit: also, the main difference between your photo and the RKKT-02 fobs I've tested on is mine have trademark sign next to the Securakey.
image
This might help differentiating the two.

@EricRibeiro
Copy link

the main difference between your photo and the RKKT-02 fobs I've tested on is mine have trademark sign next to the Securakey.

@zinongli, good catch! Looking back on their website, the RKKT-01 also has the trademarked sign. The RKKTH-02 is the only one that matches the tag I own. Thanks! 🙏

You can read raw with flipper. Turn on Debug and go RFID - Extra Actions and you'll see read raw.

Perfect, thank you! @skotopes, can I DM you the raws on Discord? I would rather not upload them to GitHub.

@skotopes
Copy link
Member

@EricRibeiro sure, but keep in mind that person who actually implemented this protocol is @zinongli

@zinongli
Copy link
Contributor

count me in! my discord is @torron0483

skotopes added a commit that referenced this issue Jun 30, 2024
* Create protocol_securakey.c
* decode and render done
* Support for Radio Key Securakey
  Support both 26- and 32-bit format
  Solves issue #2619
* debugs and improvements
* Formatting in response to requested changes
* fixed wiegand parity bit calculation
* format
* debug unnecessary assert
* LfRfid: swap vendor and protocol names in securakey
* fixed manually generated keys issues
* fix bit length render error caused by bit length fix
* 1.0
* edit the citation in comments
* backward compatibility
* debug
* debug preamble false positives
* temporary fix: writing RKKTH causes second to last byte not encoded. unknown reason
* slightly more elegant solution to the weird bug
* plausible solution, much more elegant
* finally fixed it. stupid mistake
* clean up and format. ready for new PR

Co-authored-by: あく <alleteam@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request New feature or user-story you wanna add to flipper RFID 125kHz 125, 134 kHz RFID
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants