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
Related
I'm trying to read a smartcard information by android pay application. So I send the following SELECT PPSE command:
00 A4 04 00 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 00
I get the following response:
That is, I need to get an ADF <A0 00 00 06 58 10 10>, but when I try to get it by SELECT:
00 A4 04 00 07 A0 00 00 06 58 10 10
I get the following response:
SW1SW2 = 6A82: File not found.
The tag 9F2A in PPSE means that I need to use Kernel specification (Kernel 1 for me).
But the documentation talks about actions from the moment when there is already a PDOL.
How do I get the PDOL if the ADF in which it is located is not found?
I want to build a BLE Beacon with Raspberry Pi Zero W and with an iOS and Android app (which I'll develop) I'll list the beacons and select one to send 4-6bytes of data to trigger some action on the Pi. Is that possible with Beacons or should I use something else. I am writing in Go and I don't want to pair the devices.
Yes, it is possible to make a Raspberry Pi Zero W scan for beacons and take action which identifier it saw. (Although please note that this must be a Zero W. The base Raspberry Pi Zero does not have wireless functionality.)
You won't find beacon detection code in Go on the Raspberry Pi, so your best bet is to use a native C program to do the beacon scanning part, and call it as a shell script from your Go program. The following C program is one I use on a Raspberry Pi to scan for beacons:
https://gist.github.com/davidgyoung/0a18028b4338ff6cb201fba274502662
That program must be compiled on the Raspberry Pi with cc scanner.c -lbluetooth -o scanner, after which you can start the scanner with just scanner. The output of the program will be something like this:
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
71:5C:23:9D:BC:7F -68 02 01 1A 02 0A 0C 0B FF 4C 00 10 06 03 1A 3B D4 B2 EB
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
4A:53:7F:64:71:EC -91 03 03 9F FE 17 16 9F FE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
69:0D:FF:7B:75:65 -73 02 01 1A 02 0A 0C 0A FF 4C 00 10 05 03 1C 27 BB 63
61:39:71:E9:1D:C9 -93 02 01 1A 02 0A 18 0A FF 4C 00 10 05 01 18 3B 24 12
B8:27:EB:1F:93:4D -68 02 01 06 11 06 82 75 25 D9 37 9D D7 8F 5F 4A F4 20 00 00 75 30
Each line above shows the MAC address of the detected bluetooth device, followed by the signal strength RSSI, then the hex bytes of the advertisement.
Your Go program will need to read each line of the output of scanner then parse the bytes of the advertisement to look for beacon patterns to perform various functions when it sees a packet with a certain byte pattern (indicating that a mobile phone sent out that packet.)
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 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")