Skip to main content
Olivier Bontron
Associate II
October 2, 2019
Solved

NFC0541 read Mifare Classic 1K

  • October 2, 2019
  • 31 replies
  • 9958 views

I’m using NFC05A1 and the STMF4xx-Nucle-Polling project.

I’d like to interact with  a Mifare classic card 1K.

I am aware Stm won’t provide any code that would deal with encryption and this is not what I’m asking for.

The issue I encounter is about the first step after SELECT : this is a clear text message, starting with 30 then the sector number. What I expect is the card answering with a nonce.

The issue I encounter is I receive a ‘framing problem’ or ‘timeout’ error message.

Here are the first four requests, which are working fine I think, the fifth one does not.

* Request 1:

Answer to rfalISO14443ATransceiveShortFrame  (with RFAL_14443A_SHORTFRAME_CMD_REQA as a command) is : 04 00.

* Request 2:

Then there is another rfalISO14443ATransceiveShortFrame   instruction this time with RFAL_14443A_SHORTFRAME_CMD_WUPA

*Request 3:

Then a rfalNfcaSelReq  structure is set :

selReq (rfalNfcaSelReq  structure)

selReq.selCmd = 93

selReq.selPar =20

rfalNfcaTxRetry( ret, rfalISO14443ATransceiveAnticollisionFrame( (uint8_t*)&selReq, &bytesTxRx, &bitsTxRx, &bytesRx, RFAL_NFCA_FDTMIN ), ((devLimit==0)?RFAL_NFCA_N_RETRANS:0), RFAL_NFCA_T_RETRANS );

Request answer : the request result consists in

the card Uid  D0 74 CC A4, (correct uid)

and the bcc CC

*Request 4:

Then another request is a SELECT.

selReq.selCmd =93;

selReq.selPar= 70;

selReq.nfcid1[0]= D0

selReq.nfcid1[1]=74;

selReq.nfcid1[2]=CC;

selReq.nfcid1[3]=A4;

selReq.bcc=CC;

       rfalNfcaTxRetry( ret, rfalTransceiveBlockingTxRx( (uint8_t*)&selReq, sizeof(rfalNfcaSelReq), (uint8_t*)selRes, sizeof(rfalNfcaSelRes), &bytesRx, RFAL_TXRX_FLAGS_DEFAULT, RFAL_NFCA_FDTMIN ), ((devLimit==0)?RFAL_NFCA_N_RETRANS:0), RFAL_NFCA_T_RETRANS );

Its results can be found within selRes :

Sak:  08

So far, the device is a Mifare Classic (sak 08) , this device is device[0] and its uid is known.

*Request 5 : this is where there is an issue.

Ask the card to access sector 00.

As Mr Michael Roland suggested in this post :

https://stackoverflow.com/questions/56334836/is-there-any-function-for-reading-nfc-a-iso14443a-tag-with-x-nucleo-nfc05a1

lenTx = 0;

bufferTx[lenTx++] = 0x30;

bufferTx[lenTx++] = 0x00; // sector

lenRxMax = 16;

lenRx = 0;

status = rfalTransceiveBlockingTxRx(&bufferTx[0], lenTx, &bufferRx[0], lenRxMax, &lenRx, RFAL_TXRX_FLAGS_DEFAULT, rfalConvMsTo1fc(5));

Answer

status value :  9

Another attempt with different flags.

status = rfalTransceiveBlockingTxRx(&bufferTx[0], lenTx, &bufferRx[0], lenRxMax, &lenRx,

RFAL_TXRX_FLAGS_CRC_TX_AUTO | RFAL_TXRX_FLAGS_CRC_RX_REMV | RFAL_TXRX_FLAGS_NFCIP1_OFF | RFAL_TXRX_FLAGS_AGC_ON | RFAL_TXRX_FLAGS_PAR_RX_REMV | RFAL_TXRX_FLAGS_PAR_TX_AUTO | RFAL_TXRX_FLAGS_NFCV_FLAG_AUTO, RFAL_NFCA_T_RETRANS);

Same answer

status value :  9

ERR_FRAMING                          = 9, /*!< Framing error */

I’ve added some logs within rfalTransceiveBlockingRx to have a look at the states :

platformLog("gRFAL.state %d\r\n", gRFAL.state);

do{

    rfalWorker();

    platformLog("gRFAL.TxRx.state %d\r\n", gRFAL.TxRx.state);

  }

Logs for the successful requests (REQA, SEL) are :

gRFAL.state 3

gRFAL.TxRx.state 83 (RFAL_TXRX_STATE_RX_WAIT_RXS)

gRFAL.TxRx.state 90 (RFAL_TXRX_STATE_RX_FAIL)

gRFAL.TxRx.state 0 (RFAL_TXRX_STATE_IDLE)

status is 0 ERR_NONE            

Logs for the last read request are :

gRFAL.state 3

gRFAL.TxRx.state 83(RFAL_TXRX_STATE_RX_WAIT_RXS)

gRFAL.TxRx.state 84 (RFAL_TXRX_STATE_RX_WAIT_RXE)

gRFAL.TxRx.state 84

gRFAL.TxRx.state 84

gRFAL.TxRx.state 84

gRFAL.TxRx.state 84

gRFAL.TxRx.state 84

gRFAL.TxRx.state 90(RFAL_TXRX_STATE_RX_FAIL)

gRFAL.TxRx.state 0(RFAL_TXRX_STATE_IDLE)

status is 9 ERR_FRAMING /*!< Framing error */

Many thanks in advance,

Olivier

    This topic has been closed for replies.
    Best answer by Olivier Bontron

    Dear Ulysses,

    Thank you so much for your invaluable answer.

    I went through your template and managed to get how you went from 'a2 0f' … to 'a2 1e' …

    Despite I’m not at ‘write’stage but still in the ‘authentication’ process, I guess the rationale is alike and if so the template you sent will definitely  help a lot.

    The answer the reader should send back to the card for authentication is made of :

    8 bytes + 1 parity bit on each byte + 2 bytes CRC (on these 8 bytes) + 1 parity bit on CRC bytes (as you said 'Also the CRC bytes again will have a parity'.).

    Once reshifted the way the template is, the size stays unchanged : it makes

    8 * 8 bits + 8 * 1 bit + 2 * 8 bits + 1 bit = 89 bits.

    This is the situation you described with the 36 bits example, which requires to be sent in raw mode, isn'it?

    Could you tell me how to opt for raw mode please ?

    Thanks in advance

    Olivier Bontron

    31 replies

    Ntuye.1
    Associate
    April 3, 2020

    CR95HF

    - hello, i am use cr95hf to read, write block with is014443A tag 

    - SEND: 02 02 00 00, RECEIVE: 00 00

    - SEND: 02 07 02 00 00 00 00 02 02, RECEIVE: 00 00

    - SEND: 09 04 3A 00 5A 04, RECEIVE: 00 00

    - SEND: 09 04 68 01 01 DF, RECEIVE: 00 00

    - SEND: 04 02 26 07, RECEIVE: 80 05 04 00 28 00 00

    - SEND: 04 03 93 20 08, RECEIVE: 80 08 4B F3 A7 05 1A 28 00 00

    - SEND: 04 08 93 70 4B F3 A7 05 1A 28, RECEIVE: 80 06 08 B6 DD 08 00 00

    - after how to authentication with key A, read/write block?

    - I send: 04 0D 60 01 FF FF FF FF FF FF 4B F3 A7 05 28, recieve: 87 00?

    Ntuye.1
    Associate
    April 3, 2020

    CR95HF

    - hello, i am use cr95hf to read, write block with is014443A tag 

    >> SEND: 02 02 00 00

    << RECEIVE: 00 00

    >> SEND: 02 07 02 00 00 00 00 02 02

    << RECEIVE: 00 00

    >> SEND: 09 04 3A 00 5A 04

    << RECEIVE: 00 00

    >> SEND: 09 04 68 01 01 DF

    << RECEIVE: 00 00

    >> SEND: 04 02 26 07

    << RECEIVE: 80 05 04 00 28 00 00

    >> SEND: 04 03 93 20 08

    << RECEIVE: 80 08 4B F3 A7 05 1A 28 00 00

    >> SEND: 04 08 93 70 4B F3 A7 05 1A 28

    << RECEIVE: 80 06 08 B6 DD 08 00 00

    - after how to authentication with key A, read/write block?

    >> I send: 04 0D 60 01 FF FF FF FF FF FF 4B F3 A7 05 28

    << recieve: 87 00?

    Brian TIDAL
    ST Technical Moderator
    April 3, 2020

    Hi,

    as explained in https://community.st.com/s/question/0D53W000003xs2CSAQ/cr95hf, the 87 00 timeout reply is caused by incorrectly formatted Auth with key A command.

    Rgds

    BT

    In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.
    Ntuye.1
    Associate
    April 3, 2020
    How correctly formatted Auth with key A command?
    Brian TIDAL
    ST Technical Moderator
    April 3, 2020
    In order to give better visibility on the answered topics, please click on Accept as Solution on the reply which solved your issue or answered your question.