Challenge response LF RFID tags (2 way communication)

125 kHz RFID
#1

hey @Astra,

in this post you’re mentioning that Flipper Zero likely will not be able to support challenge response LF RFID tags as a tradeoff for supporting Indala:

The problem here is that Flipper’s LFRFID system can’t work with challenge-response cards, only one-sided communication is supported. This was a sacrifice to support indala cards (which work on 62.5 khz, actually), so Hitag chips are probably out of the question

is that a hardware limitation in the design, or a software limitation.
or in other words, any chance we can expect future firmware updates supporting challenge-response cards on LF RFID? or would it be possible to write an app ourselves eg to read UID’s from these type of cards?

1 Like
#2

I’m not an expert but my first guess is the radio stack or hardware. Hopefully someone more knowledgeable will come along and enlighten us. If I understand correctly the radio stack firmware is on the radio chip separate from the Flipper firmware. I had to reprogram the radio chip on a different project to interact with a different set of protocols. It involved using a USB to serial flashing device directly connected to the chip. I don’t know what the process would be on the Flipper but it was mentioned that you couldn’t easily jump back and fourth with the radio stack. That comment might have only referred to the sub ghz radio though so take my statement with a grain of salt.

#3

hehe, no worries, plenty of salt here.

As for as I’m informed, I thought there’s no LF RFID radio chip, that most of the LF RFID is handled in software.
in contrast with subghz which has the CC1101 chip and the NFC which has the ST25R3916-AQWT chip.

so i’m kinda hoping that LF RFID challenge response support could be hanlded in software as well :crossed_fingers:

1 Like
#4

fyi, I’m working my way through the flipper schematics and source code to hopefully find how I could write some external app for reading eg Hitag x cards.

@Astra , my idea is to (ask) modulate the carrier wave generated by flipper in reading mode with the hitag ‘request uid’ phrase (11000b) and then leave the field on, to read the uid response.
That, I believe, should be possible. the following comms to read/write configuration on the tag is likely a whole other matter.
Please do share your thoughts on this, cuz after going through the schematics and LF RFID source code I do not understand why you posted that challenge response was sacrificed for supporting indala (PSK) cards.

Thx

1 Like
#5

small update,

meanwhile I managed to read out the SN & configuration page from a Hitag 1 RFID tag :raised_hands:
currently still using a raw file dump which I analyse afterwards, but I’m working on making an in app parser as well…

to be continued :wink:

2 Likes
#6

here’s another update:
currently my coding can read out & parse all public (non-encrypted) memory blocks from a Hitag 1 RFID tag.
At times my app crashes for unknown reasons, so likely there’s some code clean up to be done.

Next on the agenda:

  • include the encryption algorithm so that the encrypted memory blocks can also be read (if user knows the pasw, or using dictionary attack)
    → should anyone have documentation available on how the data is encrypted on hitag’s, feel free to forward me :wink:
  • add emulation functionality
  • see how I can share this on github (I’ve had my fair shair of programming in various languages, but those were always solo projects, no opensource stuff yet. → any direction on how to share this to make it a default app on the flipper are welcome too (@Astra ?)
2 Likes
#7

Great work! I believe the standard process is to

  1. Fork the firmware.
  2. Add your code to the fork.
  3. Make a pull request.
  4. The maintainers will then accept or deniy your pyll request.
#8

yet another update:

I’m working on the emulation functionality, biggest challenge was to detect commands from the reader, since the flipper hardware is not build for this (it’s built to read tags which are continuously transmitting data, whereas a reader just sends a short command in otherwise long moments of silence).

The good news is that I managed to actually detect commands (including CRC check) from a reader device by looking at ripples in the carrier field, and to prepare the reply messages (also including CRC check).
Now working on switching the flipper from read mode (to detect commands) to emulate mode to have an undisturbed bidirectional communication.

Once that is up and running, I think I might actually try to commit it to github as part of the official firmware :slight_smile:

3 Likes
#9

alright, we have a go.

I finally managed to do a successful emulation of Hitag 1 with both basic & advanced communication protocol.
It did take quite some finetuning on timer settings, but it’s working :slight_smile:

It’s not working 100% yet, sometimes the reader doesn’t detect my replies, but if the reader just keeps trying, then on a next round it does usually work. and since this is all mostly miliseconds, it doesn’t matter that much in the end :wink:

so i can finally see into getting this into the official firmware build …

3 Likes
#10

Very cool!

#11

fyi, meanwhile I reworked my code to integrate it into the main RFID app so that from a flipper use point of view you don’t need to worry about what type of rfid tag you’re working with.

and…
pull request has been launched :smiley:

4 Likes
#12

Great news!

1 Like
#13

Love it! Great work.