I'm using a springcard reader and a standard Type 4 passive tag. I've logged the communication protocol and I don't quite understand what is going on.
The full sequence is at the bottom of the message.
Why after receiving the CC+OK the reader restarts with the initial message
00 A4 04 00 07 D2 76 00 00 85 01 01 00
and also gets an error from the tag.
I'm trying to understand the protocol because I need to implement an emulation of a passive Type 4 tag using a microcontroller and a NFC frontent (AS3953)
The full communication log:
NFC Tag Tool v.2.10.5227.20069
Reader: EMPTY
Disconnect, disposition=1
Reader: MUTE
Reader: EMPTY
Reader: PRESENT
Connect to 'SpringCard NFC'Roll NFC 0', share=2, protocol=3
Connected to the card
Is the card a NFC Forum Tag ???
Reader: INUSE
< 00 A4 04 00 07 D2 76 00 00 85 01 01 00
Transmit << 00A4040007D276000085010100
Transmit >> 9000
> 90 00
< 00 A4 00 0C 02 E1 03
Transmit << 00A4000C02E103
Transmit >> 9000
> 90 00
< 00 B0 00 00 0F
Transmit << 00B000000F
Transmit >> 000F20003B00340406E104100000009000
> 00 0F 20 00 3B 00 34 04 06 E1 04 10 00 00 00 90 00
This card is a NFC type 4 Tag
< 00 A4 04 00 07 D2 76 00 00 85 01 01 00
Transmit << 00A4040007D276000085010100
Transmit >> 6A82
> 6A 82
SelectNfcApplication failed Check error : file not found (Check error : file not found)
< 00 A4 00 00 02 3F 00
Transmit << 00A40000023F00
Transmit >> 9000
> 90 00
< 00 A4 04 00 07 D2 76 00 00 85 01 01 00
Transmit << 00A4040007D276000085010100
Transmit >> 9000
> 90 00
< 00 A4 00 0C 02 E1 03
Transmit << 00A4000C02E103
Transmit >> 9000
> 90 00
< 00 B0 00 00 0F
Transmit << 00B000000F
Transmit >> 000F20003B00340406E104100000009000
> 00 0F 20 00 3B 00 34 04 06 E1 04 10 00 00 00 90 00
< 00 A4 00 0C 02 E1 04
Transmit << 00A4000C02E104
Transmit >> 9000
> 90 00
< 00 B0 00 00 02
Transmit << 00B0000002
Transmit >> 000A9000
> 00 0A 90 00
< 00 B0 00 02 3B
Transmit << 00B000023B
Transmit >> D101065402656E6F6B0A000000000000000000000000000000000000000000000000
000000000000000000000000000000000000000000000000009000
> D1 01 06 54 02 65 6E 6F 6B 0A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 90 00
Found a Text
Done!
1 NDEF record(s) found in the tag
Read terminated
Why does the reader restart to select the NFC Forum Type 4 Tag application after receiving the capability container + OK?
There is nothing that requires the reader application to do this (but there is also nothing the prohibits this behavior). Thus, the reader does this because the reader application is implemented that way.
It could be, for instance, that the application is split in several layers. The first layer only checks for presence of an NFC Forum Type 4 Tag application (by selecting the application and trying to find a capability container) and the second layer then tries to access and read data from the NFC Forum Type 4 Tag application independent of whether the application had been selected before.
Why does the tag return an error (6A82) after it receives the subsequent SELECT command for the NFC Forum Type 4 Tag application?
This is a good question and suggests that the tag application is poorly implemented and does not recognize a SELECT command while it is already selected.
It seems that only after the master file had been selected (and consequently the NFC Forum Type 4 Tag application had implicitly been deselected) a new SELECT command for the NFC Forum Type 4 Tag application is recognized. Again this is not mandated by the NFC Forum Type 4 Tag Operation specification. The first SELECT command could have (and in my opinion: should have) worked just as well.
Why the reader requests 0x3B (59) bytes at the end of the communication sequence eventhough the previously read NDEF message size indicates only 0x0A (10) bytes?
It seems that the reader does not optimize communication by reading only the relevant bytes of the NDEF file. That's a legitimate scenario according to the Type 4 Tag Operation specification. The capability container contains parameters that permit the reader to do this:
000F20003B00340406E10410000000.0x003B (59 bytes).0x1000 (4096 bytes).Therefore, the reader may read up to 4096 bytes from the NDEF file and is allowed to read up to 59 bytes in one READ BINARY APDU. Consequently, the reader may read up to 59 bytes (starting at offset 2) which is far below byte offset 4096.