I am getting a strange output when I try to connect my ISO 14443a card to an NFC reader.
0: : 26
0: 0: TAG 04 00
0: : 93 20
0: 0: TAG 47 82 db b3 ad
0: : 93 70 47 82 db b3 ad 3a f4
0: 0: TAG 28 b4 fc
0: : e0 50 bc a5
0: 0: TAG 13 78 80 82 02 80 31 80 66 b0 84 16 01 6e 01 83 00 90 00 03 d1
0: : e0 50 bc a5
0: 0: TAG 13 78 80 82 02 80 31 80 66 b0 84 16 01 6e 01 83 00 90 00 03 d1
0: : c2 e0 b4 <<<< WHAT??
0: 0: TAG 03 6a 82 4f 75
0: : 26
0: 0: TAG 04 00
0: : 78
You can see that the cards is woken up, performs the anti-collision, then sends its ATS when requested (it gets asked twice for some reason?).
After this, the reader sends a strange command (marked above) and the card responds with an 'Operation not supported' response.
The wake-up, anti-collision protocol then restarts, and this goes on and on.
My question is, what does the command (c2 e0 b4) sent from the reader mean?
Thanks in advance.
I do not know if you are still interested in the response, I will just save time for anyone else who might be looking for the solution(like I was).
This is nothing else but S(Deselect) block sent from the reader, consisting of Protcol Contol Byte(PCB) and 2 bytes of CRC_A
C2 E0 B4
The same applies for anyone who might be looking for this command coming from the reader:
B2 67 C7
It is R(NACK) block, consisting of Protcol Contol Byte(PCB) and 2 bytes of CRC_A
They both are a fundamental part of ISO-DEP protocol(Type 4A or Type 4B tags), so read description and how to properly handle them in the "NFC Digital Protocol" spec, chapter "13 ISO-DEP Protocol"
Related
When inspecting a transport stream using tsduck, I can see that some packets contains a PCR value in Hex. I am not sure how to convert these into timestamps.
For example, in the packet below the PCR value is 0x000002014CE
* Packet 179
---- TS Header ----
PID: 481 (0x01E1), header size: 25, sync: 0x47
Error: 0, unit start: 1, priority: 0
Scrambling: 0, continuity counter: 4
Adaptation field: yes (21 bytes), payload: yes (163 bytes)
Discontinuity: 0, random access: 0, ES priority: 0
PCR: 0x000002014CE
---- PES Header ----
Stream id: 0xE0 (Video 0)
PES packet length: 0 (unbounded)
---- Full TS Packet Content ----
47 41 E1 34 14 12 00 00 0D B0 7E 4E 0C 02 0A 22 8E 00 00 D1 2D 03 64 00
29 00 00 01 E0 00 00 84 C0 0A 31 00 07 44 B7 11 00 05 D4 37 00 00 00 01
09 30 00 00 01 06 01 03 03 84 19 80 00 00 01 41 9A 84 93 D1 13 7F F0 28
2C 26 B5 35 90 10 B7 32 8C FF 00 D3 47 BE 4C 9A 83 AE CD B8 9C 09 5A 60
07 BE C4 F2 2C 5D D3 24 6C 7F A0 E1 C4 7B BC FA 37 CA C5 C0 B0 C4 2C 91
96 09 07 22 C4 A8 55 FF C2 BF 0E 7E 10 74 6D 84 F2 08 9D D0 29 52 7F 2B
F6 3E C8 23 1F BC 4E 80 C3 AE FD AC F4 96 08 E5 13 C8 A7 41 20 B4 F6 F8
E1 14 4A 03 4C 8E 98 00 04 73 2D AE 83 31 0B C8 61 03 3A A1
What I tried is looking at the first few instances of packets that had the PCR values in them, then converting them to decimal and subsequently dividing by 90,000 which is the clock rate of the PCR clock (i.e the timebase).
But looking at the last column, it doesn't look right. It would seem that the intervals are too high. I thought that the PCR must insert PCR stamps at least every 100ms or so, but this seems to be too infrequent....
You are not using the correct time base. If you look at the example you posted, tsduck shows the PCR as 0x000002014CE But that hex value does not show up in that packet at all. The reason is the PCR is more than just a time stamp, Its 2 timestamps. The PCR in the hex is actually 00 00 0D B0 7E 4E So how do we get from 0xDB07E4E to 0x2014CE? We extract the 90 kHz component by shifting 0xDB07E4E right by 15 bits, Then extract the 27MHz component by masking off the top 39 bits. Then multiply the 90kHz component by 300 to convert to 27MHz (300=27000000/90000) and add the two values together:
300*(0xDB07E4E>>15) + (0xDB07E4E&0x1ffff) = 0x2014CE
We now have the 27MHz timestamp. To convert that to seconds, divide by 27000000
0x2014CE/27000000=0.0779
Hence:
0x58e54 = 0.0135
0x78707 = 0.0183
TLDR: time base is 27000000, not 90000
I can't finish the authentication phase.
What I am using:
SAM module by NXP
Mifare Desfire PICC
I am following the next steps:
Get PICC SerialNumber (or UID) with GetVersion.
GET VERSION:
Tx: 90 60 00 00 00
Rx: 04 01 01 00 02 18 05 91 AF
GET VERSION 2:
Tx: 90 AF 00 00 00 00
Rx: 04 01 01 00 06 18 05 91 AF
GET VERSION 3:
Tx: 90 AF 00 00 00 00
Rx: 04 65 41 49 65 1B 80 8E 65 58 51 30 46 07 91 00
Get encrypted(RndB) from PICC.
Tx: 90 0A 00 00 01 00 00
Rx: 31 15 1A 19 DB ED CD 5A 91 AF
Send to SAM PICC_SN + ek(RndB).
Tx: 80 41 01 03 0F 80 1B 65 49 41 65 04 31 15 1A 19 DB ED CD 5A
Rx: 61 20
Get from SAM encrypted(RndA + RndB_rotated) + 1st half Session Key
Tx: 00 C0 00 00 20
Rx: F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB E9 F3 51 04 41 8A 4E A5 A2 B5 67 CA FF D8 D2 35 90 00
Send PICC encrypted(RndA + RndB_rotated).
Tx: 90 AF 00 00 10 F3 10 55 B1 D3 18 91 5B 92 48 16 1F E1 58 D5 CB 00
Rx: 91 AE
So, this is a guide I have received from my suplier, and i don't have explanations about the apdus used; some i have found them on the internet, some others i guessed.
What I need to know is what does the next command i use:
to SAM module: 80 41 01 03 Lc Data
I need to know what encryption it deploys, why it needs PICC's UID (is this the IV), how can i know RndB, and what is expecting the PICC to end the authentication.
Thanks
Pd: Sorry for the text's format, it seems I'm unable to use correctly the tools for posting, everything gets in the same line it's disgusting...
I solved the problem and finished authentication.
The error was that i was requesting RndB encrypted with keyNo = 0, while corresponding key from SAM's key encryption should be keyNo = 2.
So:
--> 90 0A 00 00 01 02 00
<-- 91 B6 08 CE 9F B5 34 3B 91 AF
Carrying on, i finnish authentication:
--> 90 AF 00 00 10 0F DC FA B6 37 5F 30 34 D7 93 2D A1 3D D6 11 10 00
<-- E9 C2 F2 69 FE 38 78 28 91 00
But now I have the next problem. I've authenticated and I can read PICC's data but i'm afraid it's encrypted. I suppose it is encrypted with session key, so I need some apdu command to be sent to SAM, with data and session key, in order to decrypt data retrieved from PICC.
Am I right? if that is... which would be that SAM APDU?
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 am working with a Visa CDET contact-less test card. I have successfully selected the Application, which gave me the following result:
<= 6f 29 84 07 a0 00 00 00 03 10 10 a5 1e 50 0b 56 49 53 41 20 43 52 45 44 49 54 5f 2d 02 65 6e 9f 38 09 9f 66 04 9f 02 06 9f 37 04
The result included a PDOL which asked for the following items:
Terminal Transaction Qualifiers
Length: 4 bytes
Authorised Amount
Length: 6 bytes
Unpredictable Number
Length: 4 bytes
When it comes to the GPO command, I do have all the elements needed as shown below:
=> 80 a8 00 00 10 83 0e f3 20 40 00 00 00 00 00 12 00 bc 4b a2 3f 00
But when i run the command, I received a 67 00 error: Wrong Lc length. What could be the issue? Keep in mind the same program works perfectly when working with Visa CDET Contact test cards from the same kit.
EDIT:
About the same problem, I have a test reader that I use to confirm my readings. The reader and its program can get the GPO options and return the result for other cards, but my program is not giving me any results when I try the EXACT same command using the EXACT same card in my custom program. The result is a blank, yet the status words are 90 00 (they are separate from the returned data). Why is that?
Just assume first, that the card is right: If the length of data object 83 is 0x0F (instead of 0x0E) if I counted correctly, then the total length to be supplied in LC has to be 0x11 instead of 0x10 (tag and length to be added). This does not explain, why the contact version works, but possibly it still will work after the adjustment.
I received a 67 00 error: Wrong Lc length.
ok, its because you dont have Lc=0x00 in APDU
just add 0x00 to APDU
I am developing an application which reads NFC card from the reader.
I know the code for reading binary block like this:
FF B0 00 04 10
04 for the block 4 and 10 for 16 bytes data. My card has the data "TEST009996".
I run 5 code for read binary blocks from 4-8 like this:
FF B0 00 04 10
FF B0 00 05 10
FF B0 00 06 10
FF B0 00 07 10
FF B0 00 08 10
I got the following results:
T☻enTEÉ ☺
T☻enTEST00É
T☻enTEST009996É
enTEST009996■ 6É
ST009996■ 6 É
or in hexadecimal:
01 03 A0 10 44 03 11 D1 01 0D 54 02 65 6E 48 43 90 00
44 03 11 D1 01 0D 54 02 65 6E 48 43 49 44 30 30 90 00
01 0D 54 02 65 6E 48 43 49 44 30 30 39 39 39 36 90 00
65 6E 48 43 49 44 30 30 39 39 39 36 FE 00 00 36 90 00
49 44 30 30 39 39 39 36 FE 00 00 36 00 00 00 00 90 00
Should I create an algorithm to cut the result to get the data? Are there any better ways?
Source:
http://downloads.acs.com.hk/drivers/en/API-ACR122U-2.02.pdf
It seems that your tag is an NFC Forum Type 2 Tag (find the NFC Forum Type 2 Tag Operation specification on the NFC Forum website). As you mention MIFARE this could, for instance, be a MIFARE Ultralight, MIFARE Ultralight C or NTAG tag.
A block on a Type 2 Tag consists of 4 bytes. The read command reads 4 blocks at a time. So the read command gives you 4 blocks (4 bytes each) starting at a given block offset plus a status word for the read command (0x9000 for success). In your case you get:
Read(4, 16): 0103A010 440311D1 010D5402 656E4843 9000
Read(5, 16): 440311D1 010D5402 656E4843 49443030 9000
Read(6, 16): 010D5402 656E4843 49443030 39393936 9000
Read(7, 16): 656E4843 49443030 39393936 FE000036 9000
Read(8, 16): 49443030 39393936 FE000036 00000000 9000
Consequently, the memory of your tag looks like this:
0103A010
440311D1
010D5402
656E4843
49443030
39393936
FE000036
00000000
A Type 2 Tag (btw. in order to make sure that this tag actually conforms to the Type 2 Tag Operation Specification you would also need to read the capability container which is located in block 3) contains a series of tag-length-value (TLV) structures:
01 (Tag: Lock Control TLV)
03 (Length: 3 bytes)
A0 10 44 (Value: Information on position and function of lock bytes)
03 (Tag: NDEF Message TLV)
11 (Length: 17 bytes)
D1010D5402656E48434944303039393936 (Value: NDEF message)
FE (Tag: Terminator TLV; has no length field)
So your tag contains the NDEF message
D1010D5402656E48434944303039393936
This translates to
D1 (Header byte of record 1)
- Message begin is set (= first record of an NDEF message)
- Message end is set (= last record of an NDEF message)
- Short record flag is set (= Payload length field consists of 1 byte only)
- Type Name Format = 0x1 (= Type field contains an NFC Forum well-known type)
01 (Type length: 1 byte)
0D (Payload length: 13 bytes)
54 (Type: "T")
02656E48434944303039393936 (Payload field)
The payload field of a NFC Forum Text record decodes like this:
02 (Status byte: Text is UTF-8 encoded, Language code has a length of 2 bytes)
656E (Language code: "en")
48434944303039393936 (Text: "TEST009996")