I have problem with use direct command for mifare 1k via ACR122U. I use original SDK for Windows (including for delphi), and I sent these commands in one session:
FF 00 00 00 means pseudo-apdu. It is used to send direct commands to tag or to device (ACR).
<< FF 00 00 00 02 D4 02 // GET FIRMWARE
>> D5 03 32 01 06 07 90 00
<< FF 00 00 00 03 D4 12 24 // SET PARAMETERS (I want to disable not suported ISO 14443-4)
// (I also tried D2 12 14 without success)
>> D5 13 90 00
<< FF 00 00 00 0F D4 40 01 60 00 FF FF FF FF FF FF xx xx xx xx // auth with key A (tag UID hidden)
>> D5 41 00 90 00 // OK
<< FF 00 00 00 05 D4 40 01 30 00 // direct mifare read (30) block 00
>> D5 41 13 90 00 // ERROR 13 (incorrect value of PCB or PFB, invalid or unexpected received frame, NAD or DID incoherence, bad length of received RF frame).
I cannot read any card (i have three). All cards can be read with command FF B0 00 00 10...
Can you please tell me, what command(s) shall be sent before and after authentification to correctly communicate with the card? Please also send links to specification of commands Read register (D4 06) and write register (D4 08). I don't know what means register "63 05" (D4 06 63 05) for example.
BTW. What mean abbreviations (in context): NAD, DID, PFB, PCB?
Related
I want to write to a mifare classic 4k, using the following APDU command (UPDATE BINARY):
APDU = {FF D6 00 20 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0Fh}
It seems fine as a get a 90 00 result...
but when i read the card back I always got the following (even with different data...):
sector: 8 (block 32), auth OK
032: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
033: D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF
034: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
035: 00 00 00 00 00 00 FF 07 80 69 FF FF FF FF FF FF
where does this string D5 41 00 EA 00 FF 13 3E 86 6A 00 00 00 00 69 FF come from?
Note that i didn't change any setting on the card and was properly authenticated. It was a blank card and i didn't touch the trailer.
I m using a ACR122 reader (this command comes direct from the documentation of the reader...)
Ok i found my problem, i was setting the wrong size for the cbSendLength parameter in SCardTransmit.
Now i set the correct one (the whole size of the APDU command: 21) and it works fine.
Sorry.
I can not reliably get the PN532 to respond to commands, other than the firmware info command. I am using HSU on Windows with a FTDI cable obtained from Adafruit as well as the v1.6 of their dev board.
The black reads are from the ReadFile call timing out, it is set to 20 with all the flow control stuff disabled.
I do not think it is the cable, as the wake up and firmware version stuff is valid and works every single time.
Serial port opening code:
// Open the COM port
HANDLE commHandle = CreateFile(
"\\\\.\\COM5",
GENERIC_READ | GENERIC_WRITE,
0,
null,
OPEN_EXISTING,
0,
null
);
// Get the existing settings
DCB serialSettings;
GetCommState(
commHandle,
&serialSettings
);
// Page 26 of the User Manual specifies these settings
serialSettings.BaudRate = CBR_115200;
serialSettings.ByteSize = 8;
serialSettings.StopBits = ONESTOPBIT;
serialSettings.Parity = NOPARITY;
// These did not make it any better or worse
serialSettings.fParity = false;
serialSettings.fOutxCtsFlow = false;
serialSettings.fOutxDsrFlow = false;
serialSettings.fDtrControl = DTR_CONTROL_DISABLE;
serialSettings.fDsrSensitivity = false;
serialSettings.fTXContinueOnXoff = true;
serialSettings.fOutX = false;
serialSettings.fInX = false;
serialSettings.fErrorChar = false;
serialSettings.fNull = false;
serialSettings.fRtsControl = RTS_CONTROL_DISABLE;
serialSettings.fAbortOnError = false;
// Setup the state
SetCommState(
commHandle,
&serialSettings
);
// Clean out any buffers or flags
PurgeComm(
commHandle,
PURGE_RXCLEAR | PURGE_RXCLEAR | PURGE_TXABORT | PURGE_TXCLEAR
);
Data that is written to and read from the HANDLE, using the sizes that where obtained from the output param.
Write: 55 55 00 00 00 00 00 00 00 00 FF 02 FE D4 02 2A 00
Read: 00 00 FF 00 FF 00 00 00 FF 06 FA D5 03 32 01 06 07 E8 00
Write: 00 00 FF 00 FF 00
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Write: 00 00 FF 05 FB D4 14 01 14 01 02 00
Read:
Read:
Edit:
This appears to only happen on Windows, I tried the same process on Debian and it worked fine. I am using Java for this so I just had to rewrite the natives, so the communications itself seem functional. This is quite strange to me.
I am getting started with a PN532 NFC module recently. I can successfully read/write M1 and S50 cards.
Now I am trying to learn how to use P2P communication. However,
when I send a TgInitAsTarget command to the PN532 (ELEHOUSE module), I receive an ACK frame, but I never receive the normal information frame that should follow afterwards.
Here are my steps:
Get PN532 into target mode by sending TgInitAsTarget command:
TgInitAsTarget:
{ 00 00 ff 0x27 0xd9
d4 8c 04
08 00 12 34 56 40
01 fe a2 a3 a4 a5 a6 a7 c0 c1 c2 c3 c4 c5 c6 c7 ff ff
aa 99 88 77 66 55 44 33 22 11
00
00
fd 00 }
Get a second PN532 into initiator mode by sending InJumpForDEP command:
InJumpForDEP:
{ 00 00 ff 0a f6
d4 56 01 02
01 00 ff ff 00 00
d4 00 }
Put the initiator above the target.
When I read the information received from the target through UART, I get the following:
target->pc:
{ 01
00 00 ff 00 ff 00 }
This seems to be an ACK frame indicating that the TgInitAsTarget command was processed correctly. But afterwards the PN532 does not send the normal information frame containing the result of the TgInitAsTarget command and the target is always in busy state.
What is going wrong here?
Several things seem to be wrong with your commands.
First of all, the InJumpForDEP command seems to be malformed. That command decodes to the following:
d4 56 InJumpForDEP
01 ActPass = Active Mode
02 Baud Rate = 424 kbps
01 Next = NFCID3i
00 ff ff 00 00 NFCID3i ? (HERE is the problem)
The NFCID3i field of that command is not valid. An NFCID3i must consist of 10 bytes (e.g. 11 22 33 44 55 66 77 88 99 AA). The easiest way would be to let the PN532 automatically generate a random NFCID3i by not specifying an NFCID3i field at all:
d4 56 InJumpForDEP
01 ActPass = Active Mode
02 Baud Rate = 424 kbps
00 Next = none
Note that length field and checksum of the command frame need to be adapted accordingly.
The initiator is polling in active mode at baud rate 424 kbps. However, with your TgInitAsTarget command, you instruct the target to listen in PICC mode only:
d4 8c TgInitAsTarget
04 Mode = PICC only ! (HERE is the problem)
08 00 12 34 56 40 MifareParams
01 fe a2 a3 a4 a5 a6 a7 c0 c1 c2 c3 c4 c5 c6 c7 ff ff FelicaParams
aa 99 88 77 66 55 44 33 22 11 NFCID3t
00 no Gt
00 no Tk
Consequently, the target will only operate as ISO/IEC 14443-4 PICC (which is similar to passive mode at 106 kbps). Therefore, the initiator and the target are configured to speak two completely different protocols and, hence, do not understand each other. As a result, the PN532 in target mode will never be invoked by the PN532 in initiator mode and will, consequently, never return from the TgInitAsTarget command.
In order to configure the target in a way that is compatible to your initiator configuration, you could use this:
d4 8c TgInitAsTarget
02 Mode = DEP only
08 00 12 34 56 40 MifareParams (not used in active mode)
01 fe a2 a3 a4 a5 a6 a7 c0 c1 c2 c3 c4 c5 c6 c7 ff ff FelicaParams (not used in active mode)
aa 99 88 77 66 55 44 33 22 11 NFCID3t
00 no Gt
00 no Tk (not used in active mode)
Finally,I solved the problem, it is a hardware problem ,and i buy new PN532 module. The normal information frame return successfully。 Thanks anyway #Michael Roland .
I have problems with writing data to serial port with boost.
I use slightly modified minicom_client class from here:
https://code.google.com/p/vkbrd/source/browse/trunk/src/Dg5Emulator/MiniComClient.h
https://code.google.com/p/vkbrd/source/browse/trunk/src/Dg5Emulator/MiniComClient.cpp
First 17 bytes in message are sent good, but rest is substituted by:
FD FD FD FD AB AB AB AB AB AB AB AB EE FE EE FE 00 00 00 etc
Message length is correct.
When I call
for (int i = 0; i < 128; ++i)
miniComClient.do_write(i);
I receive this on the second side:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F FD FD FD FD AB AB AB AB
AB AB AB AB EE FE EE FE 00 00 00 00 00 00 00 00 2E F1 5C 42 BD 8B 07 18
40 6D C1 03 E8 9E 40 02 00 00 00 00 00 00 00 00 04 00 00 00 01 00 00 00
F4 62 00 00 FD FD FD FD 40 54 40 02 FD FD FD FD AB AB AB AB AB AB AB AB
00 00 00 00 00 00 00 00 2F F1 5C 43 BF 8B 07 18 A0 A3 3B 02 38 A5 3B 02
00 00 00 00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
FD FD FD FD AB AB AB AB AB AB AB AB EE FE EE FE 00 00 00 00 00 00 00 00
2E F1 5C 42 BD 8B 07 18 40 6D C1 03 E8 9E 40 02 00 00 00 00 00 00 00 00
04 00 00 00 01 00 00 00 F4 62 00 00 FD FD FD FD 40 54 40 02 FD FD FD FD
AB AB AB AB AB AB AB AB 00 00 00 00 00 00 00 00 2F F1 5C 43 BF 8B 07 18
A0 A3 3B 02 38 A5 3B 02 00 00 00 00 00 00 00 00
I have triple checked baud rate, stop bits and parity.
Is there some way to change send buffer size? Maybe this is some other problem.
Values like 0xfdfdfdfd, 0xabababab and 0xfeeefeee are magic numbers.
In other words, you are looking at uninitialized memory allocated from the heap. It is a pretty standard bug in serial port programming to assume that you get the entire message with one read. That only ever happens when you debug your program, slowing it down enough. Never when it runs at full speed, serial ports are very slow devices. You must pay attention to bytes_transferred in the read_complete() function and not interpret received data until you received all the bytes. This requires keeping track of the total, buffering partial data and having a good idea when the full response was received.
The byte value where the data turns into garbage is a magic number as well. 0x10 is the ASCII code for the Line Feed control character. Which is very often used as the End-Of-Message indicator. Be sure to configure whatever software you use on the other end of the wire to not check for a line terminator and only display the bytes it actually receives.
The reason of this problem is my "slight" modification to original code.
I wanted to make writing whole byte array simpler (instead of calling do_write() in loop), so I've added method:
void miniComClient::do_write_buffer( QByteArray msg )
bool write_in_progress = !writeMsgs.empty(); // is there anything currently being written?
for(int i = 0; i < msg.size(); ++i)
writeMsgs.push_back(msg[i]); // store in write buffer
if (!write_in_progress) // if nothing is currently being written, then start
write_start();
}
But the worst thing was my try to optimize things, so I've modified write_start() to something like this (send everything in buffer instead of just next byte):
void miniComClient::write_start( void )
{
// Start an asynchronous write and call write_complete when it completes or fails
boost::asio::async_write(serialPort,
boost::asio::buffer(&writeMsgs.front(), writeMsgs.size()),
boost::bind(&miniComClient::write_complete,
this,
boost::asio::placeholders::error));
}
This was a terrible mistake, because writeMsgs is of type std:deque so it is not stored continuously in memory, so it sends some bytes from the point I wanted, and garbage after that.
Please help me how to access Mi-fare ultralight 1k tag.
I tried the commands
ff 82 00 01 06 ff ff ff ff ff ff and ff 82 00 01 06 A1 A2 A3 A4 A5 A6
which load successfully on reader.
But When I try command
ff 88 00 01 60 00
which is use to authentication with tag
status words 63 00 (operation failed)
Log is listed below
[ACS ACR122 0] : Running script
[1] > ff 82 00 01 06 FF FF FF FF FF FF
< 90 00
[2] > ff 88 00 01 60 00
< 63 00
[ACS ACR122 0] : Running script
[1] > ff 82 00 01 06 A1 A2 A3 A4 A5 A6
< 90 00
[2] > ff 88 00 01 60 00
< 63 00
ATR of MIFARE 1K tag Which is I am using
3B 8F 80 01 80 4F 0C A0 00 00 03 06 03 00 01 00 00 00 00 6A
Below give script which is came with ACR122U reader for MIFARE 1K tag.
Which is also unsuccessful
Demo script for MIFARE 1K card and ACR122U PC/SC reader
(c) 2008, Advanced Card Systems Ltd.
[1] Load (Mifare Default) key in reader (key location 0)
FF 82 00 00 06 FF FF FF FF FF FF (9000)
; [2] Authenticate sector 0, Block 0 with key at location 0
FF 86 00 00 05 01 00 00 60 00 (9000)
; [3] Read the full 16 bytes from Sector 0, Block 1
FF B0 00 01 10 [xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx] (9000)
; [4] Update the 16 bytes in Sector 0, block 1
FF D6 00 01 10 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F (9000)
; [5] Read the full 16 bytes from Sector 0, Block 1 again
FF B0 00 01 10 [xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx xx] (9000)
; [6] Authenticate sector 1, Block 5 with key at location 0
FF 86 00 00 05 01 00 05 60 00 (9000)
; [7] Store a value "1" into block 5
FF D7 00 05 05 00 00 00 00 01 (9000)
; [8] Read the value block 5
FF B1 00 05 04 [xx xx xx xx] (9000)
; [9] Copy the value from value block 5 to value block 6
FF D7 00 05 02 03 06 (9000)
; [10] Read the value block 6
FF B1 00 06 04 [xx xx xx xx] (9000)
; [11] Increment the value block 5 by "5"
FF D7 00 05 05 01 00 00 00 05 (9000)
; [12] Read the value block 5
FF B1 00 05 04 [xx xx xx xx] (9000)
The card seems to me like MIFARE Classic 1K.
I think you have mistake in the key number that you are tying to authenticate with. Try this:
ff 82 00 01 06 FF FF FF FF FF FF //Set key with on slot 1
ff 88 00 01 60 01 //Auth with key from slot 1 to block 1
I hope this will help.