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.
Related
I'm developing a USB HID device that interfaces with Teams.
The issue:
I get ring-HID for Incoming Teams call, but when I accept the call from the host-- I don't get the hook-off HID, nor any other HID from the same usage-page, like mute or hold.
Details:
Using pywinusb (from the same windows10 host), I'm able to receive all HIDs.
Using Wireshark to sniff usb-- I don't see the off-hook HID from Teams, so I can assume it simply "decides" not to send it to my device.
Now, Teams is a real blackbox for me, but I wonder whether anyone has some insights into that (maybe relevant Teams-dev || someone that encountered this issue is the past || fw-dev for Teams-compliant device).
The relevant device's HID report descriptor usage page looks like this:
Usage Page (LEDs) 05 08
Logical Minimum (0) 15 00
Logical Maximum (1) 25 01
Usage (Off-Hook) 09 17
Usage (Mute) 09 09
Usage (Ring) 09 18
Usage (Hold) 09 20
Usage (Microphone) 09 21
Report Size (1) 75 01
Report Count (5) 95 05
Output (Data,Var,Abs,NWrp,Lin,NPrf,NNul,NVol,Bit) 91 22
EDIT:
The device uses Android OS, using linux usb gadget function f_hid via configfs. For this reason I decided to add the linux-related tags.
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.
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?
Apple Wallet supports the Value Added Services protocol. I want to use this to read the Walgreens loyalty card (the only NFC-enabled loyalty card I have), to better understand the technology.
The APDU commands needed for this can be found on page 68 in the NFC.15 spec, where APDU command SELECT FILE is described:
http://www.gsma.com/digitalcommerce/wp-content/uploads/2014/07/NFC.15-Version-1.0-Mobile-Commerce-NFC-Coupons-and-Acceptance-Technical-Proposal.pdf
Trancieving the following APDU SELECT FILE to the Apple Watch (while having the card selected)
00 A4 04 00 07 A0 00 00 05 59 00 01 00
Returns
6A 82 (File not found)
From the documentation I expected this command to select the present loyalty card file, or a special response containing a list of more specific IDs if multiple files are available. What am I doing wrong? Does the Apple Wallet use a custom RID?
Karl, You need the Merchant ID or Application ID. Without the AID (Based on the NFC Spec) you will not be able to get the Customer ID or even get any other data from the Reward pass.
Check this blog entry for more details:
http://flomio.com/2016/07/nfc-enabled-passes-on-apple-wallet/
In case anyone is wondering if simply specifying a different 2 byte Application Code after the RID of A0 00 00 05 59, which the NFC.15 document assumes is 00 01 will yield a successful file/application selection (SW 90 00), it won't. I tried all 65,536 combinations of these two bytes with no luck. So yes, some additional information is clearly needed. The link above is now dead, so I have raised a support inquiry with Apple Pay (as other posts mention) to see if the documentation required by NFC terminal makers/integrators can be made available under NDA. So far the Apple support team is giving me a bit of a runaround but I think once they understand that I'm seeking non public documentation I'll get the information I need :) I'll keep this post updated if they respond to my inquiry.
I'm trying to write an application that will interact with smart cards using an ACS ACR122U card terminal. According to all that I can find the API uses a combination of standard APDU commands and psuedo-APDUs to interact with the terminal, however psuedo-APDUs don't seem to work as claimed.
The API Reference (provided on the ACS site) indicates that APDUs of the form "FF XX XX XX ..." will be interpreted by the terminal (rather than sent to the card) but I always get a response status of "6E XX" (which I interpret as me sending an invalid class ID).
I've tried sending commands to flash the LEDs on the terminal using "FF 00 40 0F 04 00 00 00 00" and also tried to get some unique identifier from the card using "FF CA 01 00".
I can't find anything useful within the ISO 7816-4 document (the standard for smart cards) and the API reference provided by ACS. Also, ACS are not very forthcoming with information.
Does anyone have any ideas as to what I may be doing wrong or where I might look for additional information?
I can get an ATR - Answer To Reset from the terminal when a card is connected. I'm developing for interaction with Mifare 1K cards and would like to read from them and interact with the LEDs and buzzer on the terminal.
You can retrieve the API documentation here. This is ACS' proprietary APDUs so don't refer to standard ISO-7816 specification. Refer to section 6 for pseudo-APDU requirements.
To simulate LED, refer to section 6.2 for details and appendix E for example. You may try changing your APDU as follow: FF 00 40 FF 04 0A 0A 03 03. Please note that I set the LED control and also put non-zero values for LED duration.
For the second APDU, refer to section 4. Please note that you are missing P3/Le in your APDU (shall be FF CA 01 00 00) and you need the card reader connected with PICC.