I'm using the pcsc-sharp library to communicate with an ACR122U Reader an read/write information to MIFARE Classic 1k cards.
After getting familiar with the library and the APDU concept I'm able to use the cards UID as identifier in my applications.
Now I am in need of setting my own ID's to the card. Therefore I read some manuals regarding NXP's MIFARE (like MF1S70YYX_V1) and also got some information about ISO 7816-4.
I'm aware of the need to do authentication before accessing the cards memory to perform read/write operations and I know the standard Key value.
I downloaded the pcsc-sharp examples from GitHub and ran the Mifare1kTest example. I works but card.LoadKey in Line 36 fails. The response values of the Apdu command in LoadKey is SW1=99 SW2=0, which I cannot find in any documentation. Commenting out the "throw new Exception" section makes the example work.
My question now is, which values are the correct ones to pass to Card.LoadKey, respectively which are the correct values to use for parameters in the Apdu Command. What is meant with "keynumber" (Sectornumber - Sector/Block Combination)? Is the LoadKey call necessary, if the example works?
Your question is broad, but these should work for you. Code is explained with comments
var loadKeySuccessful = card.LoadKey(
KeyStructure.VolatileMemory,
0x00, // first key slot
new byte[] {0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF} // key
);
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
Im trying read data from NFC tag using MFRC522. I can read ID, SAK, ATQA ,ATS, but im not understand how read blocks data from tag and file JSON.interested in a simple sequence of commands performing a given task.
I have NFC type 4A Mifare plus.Reading ID is performed using functions Anticollision and Select.
According to the Mifare Plus datasheet just Transceive as you would do a a Mifare Classic 1/4K whose datasheet Section 12 says Transceive 30h00h to read block 0
As you don't specify how you are connecting to the MFRC522 and with what language, but you can read the ID, etc you must be familiar in sending commands like Transceive to it and getting data back.
How a JSON file is stored in the blocks is specific to your implementation (though it could be a propriety encoding of NDef only you will know by looking at it)
I am developing a USB HID device using an STMicro microcontroller. I started with STMicro's HID example which works fine. I am using C++ on Windows 7 64-bit for the PC side. I have an application that works with my device. There is one thing I can't figure out, however.
The example firmware only allowed sending and receiving 2 bytes at a time, which is determined by a HIDP_CAPS.OutputReportByteLength and InputReportByteLength. I would like to send more data than this at once, but I can't figure out how to increase the report lengths. I successfully changed the endpoint wMaxPacketSize, the VID and PID, and a few other things, but I can't figure out how Windows is calculating the in and out report lengths. There doesn't seem to be any fields in my report or device descriptions that indicate this length, but I can't imagine where else it might be coming from.
Can anyone tell me how Windows determines the HIDP_CAPS.OutputReportByteLength and HIDP_CAPS.InputReportByteLength?
How can I increase these lengths?
I figured it out. I thought I would post here in case anyone else needs to know. I'm not entirely sure I really understand it all, so if I made a mistake, someone please correct me.
I had to change the report description in my firmware. I had several usages. Windows gets the report description and figures out which usage requires the longest length and uses that length. On one of my input reports I made the following changes (the input report is just an array of bytes in firmware):
0x27, 0xFF, 0xFF, 0xFF, 0xFF, //Logical maximum is 4 bytes long, and has a value of 0xFFFFFFFF
0x95, 0x01, //There is one report
0x75, 0x20, //There are 32 bits per report
I did something similar for the output, but there is no report number field (0x95).
Windows now tells me I can send and receive 5 bytes, which I believe means the end point plus report number times report size.
I'm attempting to start coding for the new NTAG21X due to be released by the end of the year. There is very limited information available regarding the new tags. Only released to partners :-(
I'm trying to figure out how to use:
password protection on the tag. Will this be a key stored in one of the sectors and how will you go about reading NDEF? Do you pass the password to read?
originality signature. Will it be a sector as on Mifare where you write key and lock the page(s) to protect.
NTAG21x is (will be) a NFC Forum Type 2 Tag (T2T) device, like NTAG203 (hence the "2" in the names). You can expect accessing functionality will be similar to standard T2T (and MIFARE Ultralight) read/write commands (so no MIFARE Classic sectors). Reading of NDEF shall be according to the T2T spec, so no password required. Write protect could be possible (similar to MIFARE Ultralight C).
Am trying to get the manufacturer serial number (not volume number) of usb external harddrives or disk?
[EDIT]
i don't know or have any code yet on how to do this. the previous method i tried only returned the volume serial number
You can use WMI to retrieve this information. Hard drive serial numbers are in Win32_PhysicalMedia. I'm not going to take the time to write the code here; if you have any experience querying WMI in VB 6, you should be able to do it without much trouble. Otherwise, search for sample code online. You won't find much of anything specifically about hard drive serial numbers, but you'll find lots of WMI examples.
Be weary of the fact that you won't always get the serial number in the format you're expecting. For example, comments to this article indicate you might get something like:
Serial No. : 4a3532544e464137202020202020202020202020
in which case, you will have to decode the serial number:
By converting to hexdecimal bytes, we get the following (0x20 is blank character and is trimmed out):
0x4a, 0x35, 0x32, 0x54, 0x4e, 0x46, 0x41, 0x37
Swapping the odd and even bytes gets the following:
0x35, 0x4a, 0x54, 0x32, 0x46, 0x4e, 0x37, 0x41
The above ASCII codes are equal to the serial number string:
"5JT2FN7A"
I'm also not positive that all external/removable hard drives provide this information. Your mileage may vary, but the suggested method does work fine on internal hard drives.
Alternatively, it appears that you can do this using low-level Windows APIs like DeviceIOControl. You'll need to add declarations for the necessary functions to a module in your VB 6 app. This article on Code Project should help get you started; the code is written in native C++ and it's geared for consumption by .NET languages like C#, but I see no difficulty in adapting the code to VB 6.