Proxmark3 community

atmel9077

Contributor

Registered: 2017-06-25

Posts: 46

ISO 15693 on the MFRC522 (Limited support, work in progress)

Hello
Ages ago I posted about the fact that the MFRC522 reader chip from NXP (and possibly its clones) could be used to do "something else" than reading/writing ISO14443/MIFARE tags.

I've recently been working on reading 15693 tags with an Arduino Uno connected to the RC522 even if I thought it had little chances to work... and it eventually worked!

So I created a test sketch but it's yet very very dirty. If you want to test you may need to change the chip select and reset pins. The sketch should print the UID of an ISO15693 card.
That's the only thing it can do, next step would be some simple commands (read/write blocks), then I'll probably move to another platform (such as ESP32 thanks to its huge processing power) to do some more advanced stuff. (Maybe I'll someday try sniffing?)

There are two HUGE problems tho.
First problem, it takes 1280 bytes of RAM just to send an INVENTORY command.
Second problem, I have to disable interrupts to avoid screwing up the timing, but this might make millis() time measurements wrong.

How does it works ?.
To send the data I just flip the InvMod bit in the TxModeReg register. Doing it fast enough allows me to modulate the carrier.
To receive data I read the TestADCReg which shows the values of the two 4-bit inphase and quadrature ADCs.

Timing is quite tricky. In the 15693 standards all frequencies are 13.56MHz divided by powers of two, but on the Arduino frequencies are 16MHz divided by powers of two. To get a good compromise between timing accuracy and buffer size, I set the SPI clock divider to 8 so i have 2Mb/s / 250KB/s raw data rate. Because the ATMEGA328's SPI transmitter is not double buffered the actual datarate is actually 230.9 KB/s (and thus 230.9 Ksamples/s).

Here are the following steps this sketch performs in order to read a tag:
- Prepare a transmit buffer from the INVENTORY command (the CRC is already included)
- Prepare a receive buffer
- Transfer data to the TxModeReg to send the command
- Transfer I/Q samples from TestADCReg to the RX buffer
- Convert the I/Q samples into amplitudes
- Discretize the amplitude.
- Decode the Manchester coding
- Check CRC

And then finally print the UID.

Last edited by atmel9077 (2020-02-20 13:19:47)

Gambrius

Contributor

From: germany

Registered: 2019-10-28

Posts: 25

Website

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Hallo atmel9077,

Your Post is quit impressive!
I couple month ago, I was interested in reading / writing iso15693 but my equipment was a MFRC522 witch is "normally" not capable of doing iso15693. Thats why I switched to the PN5180 witch can do both. ISO144443 and ISO15693. (Back when I switched it could only do ISO15693, but toeddy extended the Lib of ATrappmann to do both. Really good job done.).

Could the way you choose to implement the iso15693 reading with an MFRC522 be used to use the MFRC522 to emulate an iso15693 tag as well?
Would be great to get an exchange with you to go even further with the MFRC522.

Regards,
Gambrius

atmel9077

Contributor

Registered: 2017-06-25

Posts: 46

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Thanks for your reply!
I will try to create an ISO15693 library for the RC522, and then I will see if I can implement emulation, but I don't think it's possible. Sniffing MIGHT be as the RC522' receiver is more or less a software defined radio frontend. The problem is that the SPI bus is limited to 10Mbps which gives a 1.25MHz sample rate, which is not ideal to properly demodulate 848kHz carriers.

Also, have you tried to run the sketch with your rc522 and was the range decent ?

Regards,
Atmel9077

atmel9077

Contributor

Registered: 2017-06-25

Posts: 46

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Update :

The (very partial) ISO15693 library for the RC522 is in progress and will come soon.

The two major problems are :
  - A 1280 byte buffer is requiered to store analog transmit/receive samples
  - Interrupts are DISABLED when transceiving.
  - Signals are NOT processed in realtime.
    -> Before transmitting, the first part of the buffer is set acccording to the data, and the rest is prepared for receiving
    -> The first part of the buffer is sent to the RC522's TxControlReg in order to transmit, and then samples from the TestADCReg fill the remaining part of he buffer in order to receive
    -> The remaining part of the buffer is processed in multiple steps to decode the data.
  - The sample rate is LOWER than the 423kHz tag's subcarrier. The subcarrier is thus NOT demodulated. But it still works!

Here is what I've been able to do so far :
- Transceiving
  -> Reader to card
        Data rate : Only HIGH is supported (26.67kbps, 1 out of 4 coding)
        Modulation : Only 100% is supported, but 10% should be possible
  -> Card to reader
        Data rate : Only HIGH is supported (26.67kbps)
        Modulation : Only single subcarrier is supported
  -> Airtime : 217 bytes of DSP buffer gives 1ms of airtime. (Either transmitting or receiving).
  -> DSP buffer size : a 1280-byte DSP buffer allows to transceive 17 bytes. that's enough to send a 5-byte Inventory request and to receive the 12-byte tag response.

- Inventory.
  -> Anticollision is NOT implemented.
  -> Only 1 timeslot is supported
  -> If more than one tag is present in the field, the library will report that no tag is detected.

- Select

- Read single block
  -> Only 4-byte blocks are supported
  -> I will add support for block lock status
  -> ONLY selected mode is supported.

- Write single block
  -> Only a 4 byte block can be written
  -> Because of the very limited airtime I can not get the response from the card so I need to read the block after writing it.
  -> I will try to add support for the Option flag to force the tag to respond after an EOF, rather than once the EEPROM has been written.

- Reset to ready

Last edited by atmel9077 (2020-02-20 13:15:53)

Gambrius

Contributor

From: germany

Registered: 2019-10-28

Posts: 25

Website

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Wow, this looks promissing.
Please keep up the good work, and keep uns knformed.

Regards,
Gambrius

atmel9077

Contributor

Registered: 2017-06-25

Posts: 46

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

I'm still working on it
I don't think I'll add additional functionnality but I certainly need to improve the demodulator. Rangs is 7-8c m at best, but using an SDR I saw that tags do actually respond twice as far (15 cm). Looks promising!
I need to clean the code and to solve the problem of some tags refusing to respond to write commands with option flag set.

Hope I'll have more time to play with that as I'm stuck at home because of quarantines (whole country is quarantined)

Gambrius

Contributor

From: germany

Registered: 2019-10-28

Posts: 25

Website

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Hallo atmel9077,

I think that 7-8 cm is good enough. For sure sounds 15 cm better, but i would like to see rather more features with the iso15693 tag than a higher read distance.

Would it be possible that you implement a iso15693 tag simulation? I really like to emulate / simulate an iso15693 tag without using a proxmark.

Regards,
Gambrius

atmel9077

Contributor

Registered: 2017-06-25

Posts: 46

Re: ISO 15693 on the MFRC522 (Limited support, work in progress)

Unfortunately, I doubt tag emulation is possible with RC522 (even if it would be cool!) because the RC522 is only a reader device. Emulation would mean:
- Detecting the reader's field to receive
- Changing the reader's impedance to transmit
I would'nt say it's impossible,  but I would be surprised if it worked well.
Second problem, emulation must be done in realtime, and this is close to impossible on an ATMega328, at least with the Arduino framework. This may, however, be possible with an ESP32 (240MHz dual-core 32-bit CPU with onboard wifi+BT)

Concerning the 15693 reader :
- I will add support for reading block lock status and perhaps LOCK BLOCK command. (Be careful with this command!)

- I'm facing problems with WRITE SINGLE BLOCK on some tags (more details here). Some tags don't like my write commands so I may have to revert to a "dirty" blind write + read sequence.

- One byte, transmitted or received, takes 70 bytes in the transmit or receive buffer. I chosed a 1280-byte buffer as this is the minimum to perform an INVENTORY without anticollision. This equates to a total of 17 bytes. Or 10 "payload" bytes after removing the CRCs, command codes and flags. INVENTORY commands with anicollision or addressed mode mean 8 more bytes to transmit and 560 additional bytes of buffer, leaving 208 bytes for the rest of the sketch. At this point it will more or less be useless, if it even compiles...

So yes, I'll try adding features, but I don't expect miracles.

I would also like to know, whether you tested my super-dirty test sketch or not, and if yes have you had good results ?

Regards,
atmel907