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")
Related
I am trying to emulate an NFC Forum Type 2 tag (Mifare Ultralight) containing an NDEF message with the ACR1252U and then read it out with an Android device.
To archive this, I enter the card emulation mode for Mifare Ultralight with:
E0 00 00 40 03 01 00 00
response: E1 03 01 01 01
The Android app "Nfc Tools" is identifying it as Mifare Ultralight now.
Then I write an NDEF message to the emulated card using the command:
e0 00 00 60 13 01 01 00 0f 03 0c d1 01 08 54 05 64 65 2d 44 45 68 69 fe
response: e1 00 00 00 03 0f 90 00
Unfortunately an Android device (Sony Xperia Z1 Compact) is unable to read the NDEF message.
So is the ACR1252U able to emulate a Type 2 tag with an NDEF message or am I just missing something?
I found a solution:
My NDEF format was wrong. This is a working NDEF message withLock Control TLV + NDEF Message TLV (with NDEF message) + Terminator TLV:
0103a010440318d10114540564652d444548656c6c6f20576f726c64203a29fe
The NDEF message contains one Text record (LANG = "de-DE", TEXT = "Hello World :)")
The write command of the ACR1252U also needs to be passed the Capability Container (CC), so one need to add the CC bytes to the message:
e1 10 06 00
So a complete command for the ACR1252U to emulate an NFC Forum Type 2 tag with the NDEF text record "Hello World :)" would look like this:
e0 00 00 60 28 01 01 00 24 e1 10 06 00 01 03 a0 10 44 03 18 d1 01 14 54 05 64 65 2d 44 45 48 65 6c 6c 6f 20 57 6f 72 6c 64 20 3a 29 fe
To read out the emulator you can use the app "NFC TagInfo by NXP".
have fun :)
This is the hexdump of a black 1x1 PNG made in Gimp and exported with minimal information:
89 50 4E 47 0D 0A 1A 0A 00 00 00 0D 49 48 44 52
00 00 00 01 00 00 00 01 08 02 00 00 00 90 77 53
DE 00 00 00 0C 49 44 41 54 08 D7 63 60 60 60 00
00 00 04 00 01 27 34 27 0A 00 00 00 00 49 45 4E
44 AE 42 60 82
Now after reading the specification I am quite sure what most of them mean, except for bytes 30-34 between the IHDR and IDAT chunk: 90 77 53 DE
Can someone enlighten me?
Those numbers are the CRC checksum for the previous chunk. See in the official specification: 5 Datastream structure for a general overview, and in particular 5.3 Chunk layout.
A CRC is calculated for, and appended to each separate chunk:
A four-byte CRC (Cyclic Redundancy Code) calculated on the preceding bytes in the chunk, including the chunk type field and chunk data fields, but not including the length field. The CRC can be used to check for corruption of the data. The CRC is always present, even for chunks containing no data.
Here is your 1x1 pixel image, annotated byte for byte. Right after the data of each of the chunks IHDR, IDAT, and IEND is a CRC for the preceding data.
File: test.png
89 50 4E 47 0D 0A 1A 0A
Header 0x89 "PNG" CR LF ^Z LF checks out okay
===========
00 00 00 0D
49 48 44 52
00 00 00 01 00 00 00 01 08 02 00 00 00
90 77 53 DE
block: "IHDR", 13 bytes [49484452]
Width: 1
Height: 1
Bit depth: 8
Color type: 2 = Color
(Bits per pixel: 8)
(Bytes per pixel: 3)
Compression method: 0
Filter method: 0
Interlace method: 0 (none)
CRC: 907753DE
===========
00 00 00 0C
49 44 41 54
08 D7 63 60 60 60 00 00 00 04 00 01
27 34 27 0A
block: "IDAT", 12 bytes [49444154]
expanded result: 4 (as expected)
(Row 0 Filter:0)
decompresses into
00 00 00 00
CRC: 2734270A
===========
00 00 00 00
49 45 4E 44
AE 42 60 82
block: "IEND", 0 bytes [49454E44]
CRC: AE426082
The IDAT data decompresses into four 0's: the first one is the row filter (0, meaning 'none') and the next 3 bytes are Red, Green, Blue values for the one single pixel.
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 writing a code to parse MFT of NTFS. I`m trying analyse Data Run of non residental $INDEX_ALLOCATION attrib:
11 01 2C 11 02 FE 11 00
9F 0B 21 01 DB 00 21 01
D9 00 21 01 E0 00 21 01
F6 00 21 01 10 01 00 F1
After regroup I see problem in Data Run No 3:
DataRun 1: 11 01 2C
DataRun 2: 11 02 FE
DataRun 3: 11 00 9F <- what does mean "00" ?
I tried analyse it using Active Disk Editor 3 and this software decompose it to:
DataRun 3: 11 00 9F 0B
In my opinion header of DataRun 3 ("11") mean 1 length and 1 offset so there should be 2 bytes after header, but there are 3 bytes.
Any idea?
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"