I write data to a 14443A Tag with a HTC One SV (PN544, Android 4.1.2), using the "binary update" APDU command, but I see between the message size (byte#5) and the beginning of the NDEF record two additional zero-bytes (#6,7). I checked the ISO7816 standard and can't see the purpose of these two additional bytes, is this conforming to the standard ? I'm parsing the APDU/NDEF message in a C-program, how can I find the beginning of the NDEF message, can I assume that these two zero bytes are always there or do I have to search for the "D1" byte ?
The ISO7816, UPDATE BINARY:
CLA As defined in 5.4.1
INS 'D6'
P1-P2 See text below
Lc field Length of the subsequent data field
Data field String of data units to be updated
Le field Empty
If b8=1 in P1, then b6-5 are set to 0 (RFU bits). bit5-1 of P1 are a short EF identifier and P2 is the offset of the first byte to be updated in data units from the beginning of the file. If b7=1 in P1, then P1||P2 is the offset of the first byte to be written in data units from the beginning of the file.
cmdMessage = "\u0002"+"en"+"erase";
Tag tag = intent.getParcelableExtra(NfcAdapter.EXTRA_TAG);
NdefRecord txtRecord = new NdefRecord(NdefRecord.TNF_WELL_KNOWN, NdefRecord.RTD_TEXT, new byte[0], cmdMessage.getBytes());
NdefMessage newMessage = new NdefMessage(new NdefRecord[] { txtRecord});
writeNdefMessageToTag(newMessage, tag);
0x00: 0x02
0x01: 0x00 CLA
0x02: 0xD6 INS, bin update
0x03: 0x00 P1, Address MSB
0x04: 0x00 P2, Address LSB
0x05: 0x0E Lc, msg size
0x06: 0x00 ??
0x07: 0x00 ??
0x08: 0xD1 NDEF header, TNF
0x09: 0x01 type-len
0x0A: 0x08 payload-len
0x0B: 0x54 "T"
0x0C: 0x02 0x02
0x0D: 0x65 e "en"
0x0E: 0x6E n
0x0F: 0x65 e "erase"
0x10: 0x72 r
0x11: 0x61 a
0x12: 0x73 s
0x13: 0x65 e
after sending the 0x9000 acknowledge the smartphone is sending another write message: what's the purpose of this additional write access ? I guess that 0x0C is the size of the NDEF message which was written in previous sequence, but why sending this information in a separate write access ?
0x00: 0x03<\n>
0x01: 0x00<\n>
0x02: 0xD6<\n>
0x03: 0x00<\n>
0x04: 0x00<\n>
0x05: 0x02<\n>
0x06: 0x00<\n>
0x07: 0x0C<\n>
The first two bytes of the NDEF message file contain the data size (i.e. the number of valid bytes in the file). In the first write command (i.e. while writing the NDEF message, these two bytes are set to zero. Thus, if the write operation is interrupted before the whole message was written, reading the the NDEF file will show an empty file instead of a corrupted NDEF message. Then, when the whole NDEF message was successfully written to the file, another write command is issued to update the data size to the size of the NDEF message. Now, if the file is read, the reader will receive the correct NDEF message size and will thus be able to read the full NDEF message.