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).
Related
I started reading into the topic of NFC/Smartcard-Communication and I found many different standards and commands depending on the Tag type (for example see here)
I also came across the APDU-commands which seem universal to the communication of nfc/smartcards?
Does this mean, that these higher level protocols are all based on apdu and can be translated?
As an example, I found NFC 14443-A commands implemented with the android.nfc.tech.NfcA library, such as:
Action
Byte
Read
0x30
Write
0xA2
And APDU commands like these:
Action
CLA
INS
P1
P2
LC
READ BINARY
0xFF
0xB0
...
...
...
UPDATE BINARY
0xFF
0xD6
...
...
...
GET DATA
0xFF
0xCA
...
...
...
MIFARE CLASSIC READ
0xFF
0xF3
...
...
...
MIFARE CLASSIC WRITE
0xFF
0xF4
...
...
...
The commands seem to be completely different.
It would also help alot, if someone could point to good documentation on the topic
Documentation I have found so far:
The Android documentation on nfca (Link)
APDU description on wikipedia Link
(The german version contains some return codes)
APDU commands (by a card-reader manufacturer) Link
You have it a bit wrong, 14443-3A is lower level that APDU's which come from the higher level ISO 7816 protocol.
But the Byte's ( 0x30 and 0xA2) you reference as NFC 14443-A are not from NFC 14443-A but look like vendor specific Mifare Ultralight protocol commands which are again above NFC 14443-A
There is also a complication and probably the reason you are confused with APDU's you listed according to the ISO 7816 spec, all the APDU's you specified have a CLA of 0xFF are "invalid".
The reason for this is that a USB readers also use ISO 7816 for the host CPU to talk the NFC chip to work mainly with NFC Type 4 Tags, because 0xFF are invalid for ISO 7816 the reader uses them for other non ISO 7816 things the NFC chip can do, e.g. communicate to non standard Mifare classic commands, turn on/off the LED's on the USB reader, etc
So really CLA's of 0xFF are just a way to wrap other commands.
Or in a rough pictorial form
I would read as much of the Standard specification documents shown in the Stackoverflow you linked to and I wrote. There are a lot of specifications used/part used
I know that they are really pay for items but they are out there on the Internet.
e.g.
http://www.emutag.com/iso/14443-3.pdf
http://www.emutag.com/iso/14443-4.pdf
For the higher level NDEF stuff https://github.com/haldean/ndef/tree/master/docs
For the Various NFC Forum Standards
Google Index of the 4 Types
I'm interfacing with a smart card (ISO 7816-4)
I have been given the below C-APDU to read a value:
CLA = 0x90
INS = 0x4C
p1 = 0x00
p2 = 0x00
length = 4
parameters = empty
Which returns the response 00000 2f4 9000
(9000 being what I understand to be the SW1/SW2, and the 2f4 part of that response contains the relevant data that I want to change)
Given this provided info, is it possible to determine what modifications to this C-APDU would I need to make to instead UPDATE this data (2f4) to be a different value?
I am quite new to this, and am trying to learn, so thank you for your responses.
My understanding is that CLA of 90 means a proprietary command set and an instruction (INS) 4C does not match any of the industry instruction commands.
Thus as this looks like a proprietary read command it is most likely that the update command is proprietary to the hardware you are issuing it to, so impossible to guess what it should be.
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!
Is it possible using ATR to determine whether I have ISO14443A or ISO14443B type card? If yes, how?
As mictter correctly explained, a real ATR only exists for ISO 7816 contact cards. I can follow the argumentation that the ISO 14443 equivalent could be the ATQA/ATQB as this is the first answer you get from tags after activation, though I would rather say that the equvalent of the ATR is a combination of ATQA + SAK + ATS (for Type A) and a combination of ATQB + Answer to ATTRIB (for Type B).
Regarding the ATR you see, I assume that this is a PC/SC-emulated ATR according to the PC/SC specification.
For smartcards (ISO 14443-4 transport protocol) this ATR would have the form
3B 8n 80 01 T[1]..T[n] xx
with T[1] to T[n] being
the ATS historical bytes for ISO 14443 Type A, or
a concatenation of the ATQB application data (T[1] T[2] T[3] T[4]), the ATQB protocol information field (T[5] T[6] T[7]) and the ATTRIB MBLI field (T[8]).
So you might be able to do some form of matching to guess if it is a Type A or B smartcard. I.e. if n == 8 and the parameters in T[1] to T[n] match something that you expect for those fields of a Type B card. Still I doubt that you will get reliable results for arbitrary cards.
For contactless memory cards, the situation is certainly better. For these cards, the emulated ATR looks like this:
3B 8n 80 01 T[1]..T[n] xx
with T[1] to T[n] containing an application identifier presence indicator (tag 4F). So T[1] to T[n] typically look something like this:
80 4F yy A000000306 ss nnnn 00000000
with ss identifying the card's protocol:
0x01: ISO 14443-1 Type A
0x02: ISO 14443-2 Type A
0x03: ISO 14443-3 Type A
0x05: ISO 14443-1 Type B
0x06: ISO 14443-2 Type B
0x07: ISO 14443-3 Type B
and nnnn identifying the card name (see the PC/SC specifications for a full list).
ATR exists for contact smartcards only. For contactless cards, its equivalent is called ATQ, and it comes in two variations: ATQ-A and ATQ-B, for each of the two ISO14443 types.
So the way I'd recommend to go is:
The reader sends both REQ-A and REQ-B, polling to see if there are contactless cards in range.
If a card responds with REQ-A, it is Type A; or if it's REQ-B, it is Type B.
The contactless reader's drivers should pass on this information to your software.
I recommend you get hold of a copy of ISO 14443-3 standard, it explain the initial steps of the card discovery and anticollision protocol, so you can see the differences between types A and B.
#haythem souissi
You can find list of card's in pcsc3_v2.01.09_sup (http://pcscworkgroup.com/Download/Specifications/pcsc3_v2.01.09_sup.pdf)
"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.