I am trying to read and write data on Mifare DESFire cards using ISO 7816-4 APDU commands. I followed the steps:
Select application using {00,A4,04,00,07,D2,76,00,00,85,01,00}.
I get the response as 9100.
Then I select file using {00,A4,00,00,02,3F,00} and I get the response as 9100.
Then I try to read the file using command {00,B0,00,00,03} and I get an error with code 6A86.
Now I want to know the exact commands to read and write the data on the cards. I think I still don't get the meaning of P1 and P2 in read/write commands. I already tried many other combinations but I always get errors like 6A86, 6982, etc.
I assume you receive the status word 9000 on success. If you actually receive 9100 when using ISO/IEC 7816-4 basic inter-industry command APDUs something very strange must be going on. 91xx status words should only be returned when you use the ISO/IEC 7816-4 wrapped command set (i.e. when the class byte of the command APDU is set to 0x90).
Let's look at what you currently do:
You start my selecting the MIFARE DESFire ISO AID D2760000850100:
00 A4 0400 07 D2760000850100
This makes sure that the card is in ISO/IEC 7816-4 framing mode and automatically selects the MF (master file; i.e. the PICC level application).
You then, again(!), select the MF (PICC level application):
00 A4 0000 02 3F00
So you are now at the same level as after step 4.
Finally, you try to read 3 bytes starting at offset 0 from the currently selected file using the READ BINARY APDU:
00 B0 0000 03
Since the currently selected file is the MF you can't read binary data from it. The MF does not have a data part. Consequently, the card reports the error code 6A86 ("wrong parameter P1 and/or P2") as it tries to tell you that reading at offset 0 (P1|P2 = 0x0000) from the MF (currently selected file indicated by the upper bit of P1 being zero) makes no sense.
Therefore, before you can read binary data, you need to select an elementary file (EF), probably even located in a different application (dedicated file, DF), that contains an actual data part. This can be done bei either explicitly sending SELECT commands for EF (and, if necessary, the DF) or by implicitly selecting the EF using a short file identifier in P1 of the first read binary command. In the latter case, you would set the upper bit of P1 to one to indicate that the remaining part of P1 encodes a short file ID. In both cases you would need to know the file/application identifiers of the files and applications that you want to read from.
Related
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 have started working with the NXP NTAG 424 TT chip together with nfcpy and an Identive SCL3711 Reader/Writer. I can successfully send and receive APDU commands, securely authenticate myself and send and receive commands in encrypted communication mode.
However I can't read or write Data to the chip, and I don't know why. Here is what I do (mostly taken from the NXP application note Page 24):
I send the command "ISO Select NDEF application using DF Name"
00A404C07D276000085010100
Then I perform the secure authentication protocol via AuthenticatEV2First with key 0x00
I try to write some data as follows:
cmd_header = 02000000040000
cmd_data = 00D1FF00 (before padding)
cmd_data = 00D1FF00800000000000000000000000 (after padding)
The complete command which I send looks like this:
cla cmd P1&2| Lc |ISO Header | encrypted Data |LE
90 8D 00 00 1F 02 000000 040000 6688A4D75482FC972C2447A1A20F0AC9C073C1CF506B2BD3 00
However the chip only responds with 917E: "Length Error"" which translates to "Command size not allowed"
What am I doing wrong? It can't be the encryption, I tested that with various other commands (getTTStatus, SetConfiguration) and these all worked fine. I quadruple checked the header. Did I perhaps fail to select the correct File, or did I miss some other steps? Also what does "Command size not allowed" mean? This error is pretty cryptic to me (which is funny when working with encrypted chips :D).
Any help is greatly appreciated!
Best regards,
Phil
The length of "encrypted data" field in your case is 24 bytes, whereas the length which you have mentioned in ISO Header is "040000" i.e. 4 bytes.
Your encrypted data length should match with the length of data you are writing.
In your case there is mismatch in both lengths and resulting in error.
Hope the information is clear.
Cheers!
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.
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?
I posted this to the net-snmp mailing list Monday and got no reply, so I am trying here.
I am confused and I hope someone can help.
I am writing an SNMP agent for a Cortex M4 application.
The SNMP books I have bought and what I have read on the net indicate that all data fields should be ASN.1 encoded. I know the OIDs are ASN.1 encoded. I am not sure if that applies to other fields like Request ID.
Looking at snmp commands sent by net-snmp, it appears that the Request ID field is a simple (4 byte) 32 bit integer.
Here is a screen shot showing an snmpget transaction monitored through Wireshark:
http://www.ko4bb.com/net-snmp/RequestID.png
It shows the RequestID to be 1750020546 (decimal) and 0x684F31C2 in hex. The data field in Wireshark also shows it to be “68 4f 31 c2”
This is not ASN.1 encoded, otherwise the first 3 bytes would have their bit 7 set to 1 and the last byte would have bit 7 set to 0, meaning the first 3 values would be >0x7F and the last value should be < 0x80
So is ASN.1 not used for the RequestID field?
I added the wireshark tag, as this is purely a Wireshark issue.
The Request ID field, is strictly in ASN.1 BER format, which is 02 04 68 4f 31 c2.
You should be careful that Wireshark is too smart to parse the data and hide some details from you.
Please check the botton panel where 68 4f 31 c2 is highlighted. Wireshark highlights them, but intentionally ignore 02 04 ahead. That's the problem.
As #GuyHarris pointed out in the comment, this Wireshark behavior is configurable. Other packet analyzers (such as Microsoft Network Monitor) might behave differently in the same scenario.