"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.
Related
I am having trouble reading and writing to different NFC tags with OMNIKEY 5426G2.
I can read and write the first 16 pages (4 bytes each) but the moment I send a command to read the 17th page - I get an error 0x6A 0x82 which means that address does not exist.
For example sending 0xFF 0xB0 0x00 0x06 0x04 gets me the 4 bytes on the 6th page
But when I do 0xFF 0xB0 0x00 0x10 0x04 - I get 0x6A 0x82 in return saying that this address does not exist.
All the tags that I use have this problem - different NTAG's, Mifare Ultralight C tags but ICODE SLIX tags are fine.
P.S. The same PC/SC commands work perfectly fine with ACR1252 reader so this is something related to OMNIKEY reader. Maybe some extra commands are missing.
P.P.S. Strange thing is that I can read/write all the bytes and pages by using a demo version of this library https://smartcard-api.com/buy-smart-card-api-library-license/
And since they are also using PC/SC commands - it clearly says that I am missing something.
Please help me understand what is going on. Thanks!
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.
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
i am looking for APDU to find UID of contact less ISO 14443 smart card and how to use it to print in Linux terminal. Problem is that i found many people talking about it, but there is no solution. Can anyone help is this regard???
Thanks
"Get Data Command" is defined in PCSC 3 v2. If your driver is PCSC v2 compliant, you can get UID using it:
Class = 0xFF
INS = 0xCA
P1 = 0x00
P2 = 0x00
Le = 0x00 (return full length: ISO14443A single 4 bytes, double 7 bytes, triple 10 bytes, for ISO14443B 4 bytes PUPI, for 15693 8 bytes UID)
Returned value is:
Data+SW1SW2
See the other answer, it is likely that most readers do support the pass through to the card reader by now.
Nobody can help as the UID is specified in the ISO 14443 T=CL transport protocol while APDU's are specified in the ISO 7816 application layer protocol.
So you need access to a lower level API for your contactless reader. PCSC will not suffice (unless there has been a pass through implemented for the specific reader that returns the UID).
What is the MozWebSocket firefox binary message client -> server packet structure?
Sending ArrayBuffer (0x01 0x00 0x01). Really sent 0x88 0x82 0xE7 0xEB 0x20 0x30 0xE4 0x03. First 2 bytes doesnt change on different sessions (id size?).
Here is for example chrome binary message packet structure -
0x82 - id
0xYY 1bit - is masked? 7bit - data length
0xZZ oxZZ oxZZ oxZZ - 4 byte mask
data (masked)
Note: Firefox currently only supports sending strings.
Seems like there is no way to send binary data using firefox?
Only Chrome currently supports sending binary object types. Firefox does not yet support sending binary types. However, Mozilla is working on the issue so there should be support in a Firefox release soon.
I believe the packet structure is identical to Chrome's (or any other browser's). Looking at the data framing section of the latest spec suggests that this is a connection close message:
0x88: The leading 8 shows that this is the final fragment of the message. The trailing 8 is the opcode for a connection close frame.
0x82: The msb shows that the message contains a mask. The remaining 7 bits give the length of data sent - 2 bytes in this case.
0xE7 0xEB 0x20 0x30: The mask used to decode the message.
0xE4 0x03: The message sent - (0xE4^0xE7) (0x03 ^ 0xEB) [ == 0xE7 0x0C I think]
Assuming you aren't closing the connection client side, you could check whether your version of Firefox supports sending binary messages.