I have an NFC label (tag type NTAG213, NXP Mifare Ultralight) with NDEF text encoding that my code is unable to decode due to an unfamiliar block 4.
I have the same chip in an ID card encoded using different means from the label, and this is read OK.
BOTH label and ID card are read correctly by my Android using the NfcTools app
Label does not decode (encoded text is "2A0001")
[04: 0103a00c] [05: 34030bd1] [06: 01075400] [07: 32413030] f8 00
What is the [01...] content of block 04, spilling into block 5
"03...." NDEF start is in middle of block 5, why?
ID card decodes OK (encoded text is "200001")
[04: 030bd101] [05: 07540032] [06: 30303030] [07: 31fe0000] 8e 00
"03...." in block 4 indicates NDEF message
On MFU tags, called "Type 2" by NFC forum, you shuold first get block 3 (called "CC"), where you'll get information about encoding and version.
Then blocks 4+ contain TLVs (Type, 1 byte, Length, 1 byte, Value, Length bytes).
Here in the first example, there is a Type 1 TLV, 3 bytes long, value "a00c34" before the actual NDEF TLV that contains the NDEF record.
You should get document "NFC Forum Type 2 Tag Operation Specification" from NFC forum. CC is explained in section 6.1, TLV format in 2.3.
Related
I've bought some MIFARE Ultralight stickers from Amazon. All of them have their page 3 set to E1 10 6D 00
My understanding is that I now can't set these 10 bits that are already set, so I've only got 22 bits that can effectively be used in the OTP page now. In fact I tried setting to 0 but it didn't work (which makes sense as the docs state that they will be ORed before writing).
As it happens it doesn't really matter to me for what I want to use them for but I'd like to at least point this out in an Amazon review for anyone else that might want to use the OTP page and buying from this seller.
I'm new to NFC so not sure what to expect but I feel I've been sold a duff product. Can you confirm that I should expect page 3 to be 00 00 00 00?
Thise heavily depends on what you wanted to buy and what you actually received.
If you bought those tags as "MIFARE Ultralight" tags, then you would typically expect that the OTP area is in its factory state (i.e. all zeros).
However, if you bought them as NFC tags (or as NFC Forum Type 2 tags or as NTAG), then the initial content of the OTP erea makes sense to some extent. The value that you found in the OTP area is the Capability Container and indicates that the tag is formatted according to the NFC Forum Type 2 Tag specification (i.e. that it came preformatted as NFC tag). Typically, there will also be some data already written to the next page (probably 03 00 FE 00 in your case). NFC (Forum) tags won't make use of the OTP area as a one-way counter, so there is no problem with having them already set and used as Capability Container.
The problem that I see with the memory content that you described is the data area size indicated in the Capability Container. 0x6D indicates 872 bytes of data memory. This is fine if the tag is not a MIFARE Ultralight tag but an NTAG216, which has exactly that amount of data memory available and always comes in this preformatted state.
However, if the tag is actually a MIFARE Ultralight tag (chip MF0ICU1), then this Capability Container would specify more data memory than the tag actually has. This would render the tag unusable for proper NDEF message handling and, since the OTP bits cannot be cleared, you could not change the indicated size to the value that's actually available (48 bytes = 0x06).
Note: Based on OP's comments, the tags are indeed NTAG216 (bought from www.amazon.co.uk/gp/product/B075RXBVKM). Hence, the memory content is perfectly fine.
What information is contained within the manufacturer block of a Mifare Classic? From what I can gather:
Bytes 0 through 4 contain the UID
Byte 5 contains the BCC for the UID
What about the rest of the data?
The data sheet provides no clue, and also does not distinguish between byte 5 and others (so these may be different in chips by other manufacturers).
I assume, that you mean a sort of checksum, but don't recognize the abbreviation BCC.
This question already has answers here:
Reading correct data from NFC wrist band with NXP Mifare Ultralight in C
(1 answer)
Defining a NDEF Message
(2 answers)
Closed 5 years ago.
I'm trying to read NDEF records out of some NTAG213 & NTAG216 NFC tags, and I seem to be getting some extra bytes in the user memory i'm not expecting.
Based on the spec, the user memory should start from block 4, but when I read from the NTAG213 tags, i see 7 extra bytes before the NDEF record start, and 2 extra bytes for the NTAG216 tags.
Here's the example of the NTAG213 memory:
01| 04 ae f4 d6
02| 0a d7 49 80
03| 14 48 00 00
04| e1 10 6d 00
05| 03 db 91 01 <-- NDEF starts at 91?
06| 1a 54 02 65
07| 6e 43 4f 43
08| 4f 4e 55 54
09| 20 42 4f 44
10| 59 20 4d 49
11| ...
The NDEF record appears to start with the header byte (91) in block 05, rather than the start on block 04.
Does anyone know what the extra bytes are for, or how I can tell what the offset should be for reading back just the NDEF data?
The bytes look a bit like some of the "Memory content at delivery". But i'm not sure what the purpose is.
Storage of NDEF data on Type 2 Tags is defined by the NFC Forum Type 2 tag specification. This specification defines that the first four byte of the user memory (fourth page) describe the NDEF capabilities of the tag and that the following bytes contain a sequence of Type-Length-Value (TLV) constructs, one of those (T=3) is the NDEF Message TLV that contains the actual NDEF data. Other TLV's describe memory locations that contain tag specific data like lock bytes and must be skipped when reading or writing NDEF data.
Your example content is an NTAG216 (not NTAG213).
The content of the fourth page is a magic byte (0xE1) that indicates NDEF format, followed by the NDEF mapping version (0x10 => Version 1.0), followed by the raw tag capacity in multiples of 8 (0x6D * 8 == 872 byte user data), followed by the read/write permissions (0x00 => readable and writable w/o restrictions).
The fifth page starts with the NDEF TLV Type (0x03 => NDEF message), followed by the TLV Length (0xDB == 219 byte) which gives the TLV Value field size. The bytes following are the actual NDEF message data but be aware that for some tags this may not be contiguous memory (other TLVs may indicate memory bytes that must be skipped when reading or writing).
For all the bells and whistles you can study an ndef read and ndef write or obtain a copy of the Type 2 Tag specification from the NFC Forum specifications page.
I want to write an NDEF message (containing a text NDEF record) to an NFC tag (Mifare Ultralight TYPE 2) using APDU commands. Tag has 4 byte memory banks starting form 0x00 to 0x2B. Which memory location should I write raw binary representation of my NDEF message?
In Type 2 specification, the data blocks start at byte 0x10
See page 5 for a brief overview of type2 memory spec and memory structures on page 29:
http://apps4android.org/nfc-specifications/NFCForum-TS-Type-2-Tag_1.1.pdf
Also, here is an example empty NDEF message written to the tag memory
"Hey bro, what's up ?"
I'm in trouble with NDEF message formatting.
I went through the NFC forum to know how to build a NDEF message with a single NDEF record (text RTD) with a payload, so I can program my tag (M24LR16E) through I2c.
In addition to this, I programmed my tag with an external writer to have an example of a well formatted record.
Then I programmed my tag through I2C with the exact same value, and everything worked well. Changing the payload characters gave me the proof of my success =)
"But you didn't come here to show us that anything worked well, no?"
You're right, know I'm trying to change the payload length and I get troubles. As soon as I change the PAYLOAD_LENGTH of the NDEF record it is no more recognized anymore as one. I changed the PAYLOAD_LENGTH from 10 down to 5, so it's not a problem of overflowing the config field.
"Great story, show me some code/config"
Here is my record configuration :
"Header" (MB ME CF SR IL TNF) : 0xD1
PAYLOAD_LENGTH : 0x0A
TYPE LENGTH : 0x01
TYPE : 0x54
PAYLOAD :
0x02 ; UTF-8, 2 byte language code
0x65 ; e
0x6E ; n
7 Other boring bytes
Also, I noticed that if I override the 6 bytes before my NDEF message, the NDEF message isn't recognized anymore. I have no idea on what could be this data as the NFC specification doesn't talk about this, neither the tag datasheet.
"You're supposed to ask a question..."
Uh, well...
Is there anything else than the PAYLOAD_LENGTH field of the NDEF record that I should change?
What are those essential data before my NDEF message?
My reader: Nexus 4 with NXP's "TagInfo" app
Unfortunately, you won't find much information on how to use that tag to store NDEF messages on the NFC Forum website. The reason for this is that there is currently no Tag Type specifiction for ISO 15693 tags (though standardization is ongoing).
I assume the memory contents of the tag looks like this (including the bytes you did not understand):
E1 4x yy 00
03 0E <YOUR NDEF MESSAGE> FE
If that's the case, the first 4 bytes are the capability container (indicated by the magic byte 0xE1 and the version nibble 0x4). x shoud be 0x0 indicating (application level!) read & write access. yy should be the overall size of your available data memory (excluding capability container) divided by 8. So far you should be able to keep those values...
But then there is the NDEF message TLV structure which embeds your NDEF message: 0x03 is the tag indicating an NDEF message. 0x0E is the length field. So that's what you need to change in addition to the payload length of your record. Android is quite picky when it comes to that length field. If this does not match the exact length of your NDEF message, most Android versions will ignore the message. The last byte, 0xFE is the (optional) terminator TLV. This should immediately follow the last data byte on your tag to tell the NDEF tag parser to stop parsing.