I was modifying a piece of PC software I wrote to read multiple NDEF records from an NFC tag. However, one of the tags I have contains a record with what seems to be a mangled NDEF header. It's the last record of 6, the other 5 coming in as expected. I've listed it below. For simplicity, all values are listed in hexidecimal and the payload has been truncated.
Record #6
Header: 42
Type Length: 03
Random Bytes: 00 00 00
Payload Length: 2C (44)
Rec. Type: 6E 2F 70 (n/p)
Payload: **
As you can see, 3 random zero bytes are shoved between what should be the Type Length and Payload Length. I have double checked the Length Field in the TLV and found that it accounts for these 3 bytes. I'm not getting any data truncated off of the end of the TLV due to these added bytes.
I decided to do a sanity check with NXP's TagInfo app to make sure I wasn't just reading the data incorrectly. Checking the data dump from a full scan, I saw that the data does in fact match. I've listed the memory scan below. Only the relevant data points are listed and the payload is, again, truncated.
Memory Dump
addr data
...
[30] -- -- 42 03 |--B.|
[31] 00 00 00 2C |...,|
[32] 6E 2F 70 ** |n/p*|
[33] ** ** ** ** |****|
...
[3D] ** ** ** FE |***.|
...
We thought that maybe this was an issue with padding given that, in this case, the Terminator TLV appears at the end of page 0x3D. However, due to the nature of previous records, this is not always the case. Sometimes, the Terminator TLV shows up in the middle of a page.
However, the strange thing is that, in the same TagInfo app on the NDEF page, it reports the NDEF message as follows.
NDEF Message
...
[A8] 52 03 2C 6E 2F 70 ** ** |R.,n/p**|
[B0] ** ** ** ** ** ** ** ** |********|
...
[D8] ** ** |** |
...
Somehow, the software has not only removed the 3 extra bytes, but has correctly set the SR bit in the NDEF header. I have double checked this with another NFC app on Android and have confirmed that the other app is able to read the NDEF Message this way as well.
My question is, is there a reason or logic behind how the app is able to correct not only the the added bytes, but also the NDEF Header? I'm not sure if this is Android doing the correction or something else deeper in the NDEF message structure. Either way, I'm looking at the right way to make the correction while not effecting how I read the other 5 records held within this tag.
Those bytes are also part of the payload length
If the record does not have the SR (short record) bit set, then the payload length is 4 bytes long rather than one byte.
https://learn.adafruit.com/adafruit-pn532-rfid-nfc/ndef#payload-length-9-9
The first byte is 0x42, which in binary is 0100 0010. If we separate that out, we can see that the record has the ME (or 'Message End') bit set, as well as a TNF ('Type Name Format') of 0x02 - 'MIME Media Record'. The SR bit is bit 4, which is zero in this case.
That's also why they disappear in the version corrected by the TagInfo app - it has set the SR (which is why the header jumps to 0x52) and removed the unnecessary bytes.
Related
Recently checked some Zalman keyboard, sniffing USB reports i receive this:
key '3' pressed on keyboard:
00 00 00 00 00 01 00 00 00 00 00
keys '3' + '2' pressed:
00 00 00 00 80 01 00 00 00 00 00
keys '3' + '2' + '1' pressed:
00 00 00 00 C0 01 00 00 00 00 00
My question is what is that? This is definitely not usb hid usages codes. Where i can find translation table for this? Something like that:
USB HID to PS/2 Scan Code Translation Table - Microsoft
It seems that each of the three keys you pressed corresponds to one bit in the report. The bit is 1 to indicate that the key is pressed and the bit is 0 to indicate that it is not pressed.
HID allows keyboards to define their own report format. You can look at the HID descriptors reported to the computer by your keyboard in order to understand what the report format is supposed to be.
I stumbled upon this question whilst doing some research into a bug I've been having with my HID parser.
For what it's worth, I'll add a couple of points to the accepted answer, based on my interpretation of what's happening here.
In the HID Usage Table spec, it specifies the following for the Keyboard/Keypad usage page:
The usage type of all key codes is Selectors (Sel), except for the modifier keys Keyboard Left Control (0x224) to Keyboard Right GUI (0x231) which are Dynamic Flags (DV).
So, key codes are to be interpreted as Selectors.
Looking at the section that defines the Selector type (3.4.2.1), it states that Input tags with the "Sel" type will have the Array flag set.
Till now, I've been interpreting key code fields based on the presence of the Array flag, but a random keyboard that wasn't working led me to research this a bit further.
I discovered on the re-read that the spec "sneaks" in a bit of a gotcha... an exception to the Array rule above.
In the same section further down, it describes how selectors come in three forms. The last form is applicable to my problem:
Any selection of a set. The control is implemented as a set of bit fields in which each bit represents a single selection. This control is defined by a Main item with the Variable flag set and the Report Size equal to 1. The Report Count will be equal to the number of selections in the set.
Turns out this is the approach used to specify key codes in the problematic report descriptor.
... one bit for each useable usage id on the keyboard page, plus spares. 240 fields in the report representing each possible key code. Considering the keyboard has a key rollover of 6, it's a rather mad way of describing the reports, and I'm sure there must be something I'm missing in their rationale.
Regardless, the spec says it's fine so I've updated my HID parser to handle this case.
So I've basically reiterated what David has already stated, but I believe this is the rationale as to why it can be so.
I've got a couple of NXP MIFARE Ultralight tags (type 2) that contain some data in the first record. I'm using an ACS 1252U to read the tags, and I've tried manually iterating over some of the data to get a sense of what's on the tag, but I can't seem to figure out how to determine where the record begins and where it ends.
Here's some detailed information on the NFC tag and the record I'm trying to read:
And here's some data from one of my tags starting at page 04:
03 ff 01 5a
c4 0f 00 00
01 45 62 63
61 72 64 2e
6e 65 74 3a
62 63 61 72
64 39 39 37
30 31 1e 34
Now if I convert all of that to ASCII, I get the following:
ÿZÄEbcard.net:bcard997014
All I know is that the actual data I'm after (or the payload) begins at 99701, but how in the world am I supposed to know that? Surely there's something in the data that can tell me where the record's payload starts and where it stops?
The data follows the Type 2 Tag specification just fine. A Type 2 tag has its data pages starting at page/block 4. Data is embedded into TLV structures.
In your case, the first byte of page 4 is the tag of an NDEF Message TLV (0x03). The next byte indicates that the length filed is encoded in 3-byte format. Consequently, the length is 0x015A (= 346 bytes). Thus, you have to read the next 87 pages (= ceil(346/4) since data starts at page boundary) to retrieve the complete NDEF message.
The NDEF message itself consists of 1 NDEF record (the header byte 0xC4 indicates that the record is the first (MB=1) and last (ME=1) record of the message). The record is an NFC Forum external type (TNF=4 in the header byte). The type name has a length of 0x0F (= 15 bytes). The payload has a length of 0x0145 (= 325 bytes). Consequently, the type name is "bcard.net:bcard" and the payload is '39 39 37 30 31 1E 34 ...' (ITN doesn't seem to have published a specification on how their bcard type is structured).
See How to interpret NDEF content on Mifare Classic 1K on how to decode these TLV structures and the NDEF message.
I've got a contactless chip card (not bank or SIM) which I can interact by NFC channel (ISO14443, ISO 7816 Part 4).
All I want to get from this card is getting of UID of the card, which can help me to differ one card from others. As I understand this is PAN value which I can get under the tag '5A'.
Firstly, I can send this command to the card
00:a4:04:00:0e:32:50:41:59:2e:53:59:53:2e:44:44:46:30:31:00
and get positive answer (SW:9000) with the AID value.
So, I have AID and I can send such command
00:a4:04:00:LеnAID:<AID>:00
to open file for reading TLV-based info under different Tag, am I right?
But when I send ('5A' - tag for PAN)
00:CA:00:5A:00
I have bad response -> 6E:00
So,
1)Should I change Class value (CLA = 00 for right now)? And for what value?
2)Maybe I have to change INS value for READ RECORD (B0 or B2 or something else) because "The kernel uses the value of the AFL (i.e. tag ‘94’) to issue one or more READ RECORD commands retrieve the Application data elements", in my case tag '5A' for PAN.
If so, what the complete workflow should be for getting PAN?
UPD.
When I sent
ff:ca:00:00:00
I receive
6e:00
For unknown for me reason I couldn't get positive answer on command
FF:CA:00:00:00
I got answer 6E:00
But I found another way how to get card info. I have to execute not one but a sequence of commands:
1) Firstly I have to find out the AID of the applet. If you know AID you can skip this step (2PAY.SYS.DDF in my case)
00:a4:04:00:0e:32:50:41:59:2e:53:59:53:2e:44:44:46:30:31:00
2) Then SELECT APPLICATION
00 A4 04 00 AID-Lenth AID
3) After that we GET PROCESSING OPTIONS
80 A8 00 00 02 83 00 00
4) And READ RECORD
00 B2 01 14 00
For decoding TLV-response I use this utility - https://www.emvlab.org/tlvutils
In response I got not only 5A tag but also others and for right now I have to parse the whole R-APDU for fetching particular tag value.
Is there any java-libs for parsing TLV-response?
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.
What APDU command gets the PIN from the smart card and write the Changed PIN into the card?
For writing the code on card I have found 80 D4 00 00 08 01 02 03 04 05 06 07 08 to set pin 1 2 3 4 5 6 7 8 but we got 6D 00 in response i.e Instruction code not supported or invalid.
Or are there any WIN APIs that can be used?
Thanks in advance.
Severe misunderstanding: Nothing gets the stored PIN from the card. Using the VERIFY command you can only supply a comparison value and find out, whether it is correct - if it is not, the retry counter will decrease and the PIN may block. There is the standard command CHANGE REFERENCE DATA, see ISO 7816-4, but standard commands have CLA=00 while you currently try CLA=80 (first byte of the command).
6D00 can also be found there and since it means "wrong INS code" the whole command may be wrong. (A PIN consisting of non-printable bytes is also somewhat untypical.)
Without knowing, which card you have and which specification it complies to, you will not make significant progress.
While WINSCARD may be your friend to get the command transported, it will not help in the respect of finding the correct bytes.