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.
Related
I am trying to collect temperature and humidity from beacons, that sends this raw data:
020106 020AFC 0A16 ABFE 70BF01 00DB00DB
where:
0x02 – length (2 bytes)
0x01 – type (flags)
0x06 – value (BIN=00000110)
0x02 -length (2 bytes)
0x0A type («Tx Power Level»)
0xFC – value (DEC =-4)
0x0A – length (10 bytes)
0x16 - type («Service Data - 16-bit UUID»
0xABFE - UUID = FEAB
0x70 – frame type (temperature and humidity)
0xBF – TX#1m
0x01 – TX power
0x00DB – temperature (DEC=219 = 21.9 C)
0x00DB – humidity (DEC – 219= 21.9C)
I am trying to build an instance, but it looks like that it is not correct, WAIDW?
m:9-10=feab, i:11-14, p:6-6, d:14-17
Thank you for your help
Try this:
"s:0-1=feab,m:2-2=70,i:3-8,p:3-3,d:5-6,d:7-8"
That expression will:
match on a 16 bit service UUID 0xFEAB (which you show)
make sure the first byte after the service UUID is 0x70 (which you show). This will ensure it is a temp and humidity frame
put the full bytes of the frame into the first identifier field accessible by beacon.getId1() (this is not very useful, but you are required to have at least one identifier field for your beacon parser)
put the raw temperature value into the first data field accessible by beacon.beacon.getDataFields().get(0)
put the raw humidity value into the second data field accessible by beacon.beacon.getDataFields().get(1)
I am working on a Mobile Programming project. The Mobile program aims to write uri information like http://example.com as uri payload and wifi credentials so that when you tap nfc tag you can connect to wifi and open up uri in the browser.
I have tested to write two information into one nfc tag but it does not seem to provide two operations at the same time.
If the project is successful on tap onto nfc tag the mobile has to popup wifi connection and open uri in the browser.
If anyone has the clue i will be so pleased to follow!
NDEF message is composed of NDEF Records. In this case, the message should consist of 4 records namely:
URI Record Type representing http://example.com
Recommended Action Record
Title Record
Wifi Simple Configuration Record defined by Wi-Fi Alliance Mime Type being application/vnd.wfa.wsc (Android Code that writes such record)
NDEF message consisting of the first 3 records is as follows. Please update it to contain the 4th record yourself.
----------
Offset Content Length Explanation
0 0xD1 1 NDEF header. TNF = 0x01(Well Known Type). SR=1, MB=1, ME=1
1 0x02 1 Record name length (2 bytes)
2 0x30 1 Length of the Smart Poster data (48 bytes)
3 “Sp” 2 The record name
5 0x81 1 NDEF header. TNF = 0x01, SR=0, MB=1, ME=0
6 0x01 1 Record name length (1 byte)
7 0x00, 0x00, 0x00, 0x0C 4 The length of the URI payload (12 bytes) (long format)
11 “U” 1 Record type: “U”
12 0x03 1 Abbreviation: “http://”
13 “example.com” 11 The URI itself.
24 0x11 1 NDEF record header (SR=1, TNF=0x01)
25 0x03 1 The length of the record name
26 0x01 1 The length of the “act” payload.
27 “act” 3 Record type: “act”
30 0x00 1 Action = Launch browser
31 0x11 1 NDEF record header (SR=1, TNF=0x01)
32 0x01 1 Length of the record name
33 0x12 1 Length of the record payload (18 bytes)
34 “T” 1 Record type: “T” (=Text)
35 0x05 1 Status byte for the Text (UTF-8, five-byte code)
36 “en-US” 5 ISO Language code: US-English
41 “Hello, world” 12 The text: “Hello world”, encoded in UTF-8.
----------
To answer your question of whether its possible to get the Android reader to handle these multiple records we should look at the NFC Tag Dispatch system
This system creates an intent with
- action = NfcAdapter.ACTION_NDEF_DISCOVERED
- MimeType = mimetype of the first record
- Intent's Extra NfcAdapter.EXTRA_NDEF_MESSAGES contains complete Ndef message
Therefore, Android populates mimetype of first record only.
Its left to the application or service that picks up this intent to process all the NDEF records as needed.
I write a text to a Mifare Classic 1K tag using the NFC Tools app on my Android device (through the built-in NFC reader). This text is "moretto" (my last name).
Then, I'm trying to read this text (NDEF format) using the NFC reader ACR1255U with the library provided by ACS.
I am able to get following:
Read block 4: FF B0 00 04 10 response: 0000030ED1010A5402656E6D6F726574 9000
Read block 5: FF B0 00 05 10 response: 746FFE00000000000000000000000000 9000
I know that FE indicates the end of content and 6D6F726574746F is my text. But how do I identify where the text begins? I have difficulties to understand the TLV format described in the NXP documentation.
First of all, NXP's proprietary NDEF mapping for MIFARE Classic tags is specified in these two application notes:
NFC Type MIFARE Classic Tag Operation
MIFARE Classic as NFC Type MIFARE Classic Tag
As you already found (Unable to authenticate to a MIFARE Classic tag used as NDEF tag), the NDEF data is stored in the data blocks of certain sectors (the NDEF sectors, marked as such by means of the MIFARE Application Directory). Thus, the data relevant for NDEF is the combination of all data from these blocks.
E.g. if your NDEF sectors are sector 1 and 2, you would need to read blocks 4, 5, 6 (= blocks 0..2 of sector 1) and blocks 8, 9, 10 (= blocks 0..2 of sector 2) to aggregate the data of the NDEF tag.
In your case, the data from blocks 4 and 5 seems to be sufficient (since the end of tag data is marked in block 5, as you correctly found yourself). The relevant tag data in your case is
0000030E D1010A54 02656E6D 6F726574
746FFE00 00000000 00000000 00000000
The tag data itself is packed into TLV (tag-length-value) structures. A TLV block consists of a mandatory tag byte, a conditional length field, and an optional data field:
TLVs that don't have length and data fields:
+----------+
| TAG |
| (1 byte) |
+----------+
TLVs where the data field has a length from 0 to 254 bytes:
+----------+----------+-----------+
| TAG | LENGHT n | DATA |
| (1 byte) | (1 byte) | (n bytes) |
+----------+----------+-----------+
TLVs where the data field has a length from 255 to 65534 bytes:
+----------+----------+-----------+-----------+
| TAG | 0xFF | LENGHT n | DATA |
| (1 byte) | (1 byte) | (2 bytes) | (n bytes) |
+----------+----------+-----------+-----------+
The interesting tags in your specific case are:
NULL TLV: Tag = 0x00, no length field, no data field
Terminator TLV: Tag = 0xFE, no length field, no data field
NDEF Message TLV: Tag = 0x03, has field, has data field (may have zero length though)
Consequently, in your case the data decodes to:
00 NULL TLV (ignore, process next byte)
00 NULL TLV (ignore, process next byte)
03 NDEF Message TLV (contains your NDEF message)
0E Lenght = 14 bytes
D1010A5402656E6D6F726574746F Data = NDEF Message
FE Terminator TLV (stop processing the data)
An NDEF message can consist of 0, 1 or more NDEF records. In your case, the NDEF message decodes to the following:
D1 Record header (of first and only record)
Bit 7 = MB = 1: first record of NDEF message
Bit 6 = ME = 1: last record of NDEF message
Bit 5 = CF = 0: last or only record of chain
Bit 4 = SR = 1: short record length field
Bit 3 = IL = 0: no ID/ID length fields
Bit 2..0 = TNF = 0x1: Type field represents an NFC Forum
well-known type name
01 Type Length = 1 byte
0A Payload length = 10 bytes
54 Type field (decoded according to the setting of TNF)
"T" (in US-ASCII) = binary form of type name urn:nfc:wkt:T
02656E6D6F726574746F Payload field (decoded according to the value of the Type field)
Therefore, your NDEF message consists of one Text record (NFC FOrum well-known type with the data payload 02656E6D6F726574746F. This record payload decodes to:
02 Status byte
Bit 7 = 0: Text is UTF-8 encoded
Bit 6 = 0: Not used
Bit 5..0 = 0x02: Length of IANA language code field
656E IANA language code field
"en" (in US-ASCII) = Text is in English
6D6F726574746F Text
"moretto" (in UTF-8)
I am sending below APDU command to ISODep tag and I am getting '6700 wrong length'
byte[] command = new byte[]{ (byte)0x80, (byte)0xD0, (byte)0x01, (byte)0x00, (byte)0x07,(byte)0x22 , (byte)0x22,(byte)0x12 , (byte)0x34 , (byte)0x56 , (byte)0x78 , (byte)0x90 };
Please suggest if something is wrong in above command.
You are sending a case 4 APDU there, right? Your Lc indicates 0x07 bytes of data, and there's a Le of 0x90 trailing.
Check with your specification whether this command is actually expecting a case 4 structure, or whether you just got the data length in the Lc field wrong (0x08 instead of 0x07).
My goal is to have an Android phone (Samsung Galaxy Nexus) communicate with a TI TRF7970A card in emulation mode (emulates ISO-14443 type B tag) through NFC.
I understand that the PCD (Android phone) sends out a "REQB" with a given AFI and then which ever PICC's (in my case only PICC is the TI TRF7970 card) that have a matching AFI will send an "ATQB" back to the PCD.
In some TRF7970A firmware the "ATQB" response was set up like so:
0x50; //
//PUPI
0x80; // PUPI_0
0x12; // PUPI_1
0x34; // PUPI_2
0x56; // PUPI_3
//Application DATA
0x40; // APP_0 AFI Telecommunication (Telephone,GSM) All Sub families 1-F
0xE2; // APP_1 CRC_B of the AID (multibyte application identifier code which identifies an application provider or issuer and indicates if the application provider is registered with ISO)
0xAF; // APP_2 CRC_B of the AID
0x11; // APP_3 # of applications (1)
//Protocol DATA
0x80; // Data rate capabilities (Same bit rate from PCD to PICC and from PICC to PCD compulsory)
0x71; // Max Frames (128 bytes) / Protocol Type (supports PICC ISO 14443-4)
0x85; // FWI (0b1000 - 8192 ETUs or 77328.6 us) / ADC (0b01 - determines what APP_0-3 are if 0b00 then App data can be anything) / FO (0b01 - CID Supported - used for identification of multiple cards in the Active state)
This "ATQB" has the PCD (Android phone) automatically launch the web browser with URL "http://www.Cisco Auth Complete".
Question:
(1) Which field tells the phone to automatically launch the web browser? How can I change that field so that I can manually chose which application acts on the intent?
I've tried looking online to learn how I can manipulate the fields but have had no luck.
I read 3 Type B 14443-4 Smart Cards (MAXIM-MAX66020k-00AA+) with my Android phone and the "ATQB"'s were as follows:
Card 1 Card 2 Card 3
0x50 0x50 0x50
//PUPI
0xd8 0x99 0x1a
0x60 0x5c 0x61
0x02 0x02 0x02
0x00 0x00 0x00
//Application Data
0x10 0x20 0x10
0x10 0x00 0x10
0x11 0x2b 0x11
0x11 0xe0 0x11
//Protocol Data
0x00 0x00 0x00 106Kbits/sec
0x00 0x00 0x00 16 bytes / Not type B -4 complient)
0x00 0x00 0x00 32 ETUs / Application is proprietary / Nad "nor" CID are supported
I tried sending these exact ATQB messages with the TI TRF7970A card but the Android phone still does not act on the "ATQB" response.
Question:
(2) Can you point out a reason why any of these last 3 "ATQB"'s wouldn't be excepted?
(3) What are some legit "ATQB"'s that when sent to my Android phone it will create an intent?
(4) Are there rules I can follow so that my android phone always creates an intent on the "ATQB"'s I respond with from the TI TRF7970A?
If you could direct me to a source that can explain any of this, it would be greatly appreciated.
Thanks in advance!
-Derek
I think you are looking in the wrong place. The TRF7970A is probably emulating an NFC Forum Type 4 Tag, containing an NDEF message.
How this results in an intent is explained at http://developer.android.com/guide/topics/nfc/nfc.html