NFC ACR122 TgInitAsTarget, initiator releasing target - nfc

I'm trying to get my ACR122 (usb) device to emulate a passive NFC tag, but am having difficulty getting the communication to occur properly. I'm hoping someone can see what I'm doing wrong here and help point me in the correct direction.
The response on this other question ACR122 - Card Emulation pointed to a document at http://code.google.com/p/nfcip-java/source/browse/trunk/nfcip-java/doc/ACR122_PN53x.txt but when we follow this to the letter it doesn't behave as expected.
We're using an Samsung Galaxy S3 Android 4.3 device for testing, and are seeing the below behaviour:
Transmit (TgInitAsTarget)
....'......4V#.. FF 00 00 00 27 D4 8C 00 08 00 12 34 56 40 01 FE
................ A2 A3 A4 A5 A6 A7 C0 C1 C2 C3 C4 C5 C6 C7 FF FF
...wfUD3"... AA 99 88 77 66 55 44 33 22 11 00 00
Receive
..%....7.5<...w. D5 8D 25 1E D4 00 08 37 D9 35 3C BF D5 AE 77 9C
...2Ffm......... 00 00 00 32 46 66 6D 01 01 11 03 02 00 13 04 01
... 96 90 00
Transmit (GetData)
....... FF 00 00 00 02 D4 86
Receive
..).. D5 87 29 90 00
The TgInitAsTarget command appears to be working, returning a mode of 0x25 which we understand means "Active mode, DEP, 424kbps".
But then "GetData" command is immediately failing, returning status code 0x29 "The PN532 configured as target has been released by its initiator".
We've tried altering the TgInitAsTarget command with different modes (instead of the 0x00 "All" mode), trying the following which all still return 0x29 for the following GetData command:
Mode 0x01 "Passive", resulting in response mode of 0x04 "DEP"
Mode 0x02 "DEP", resulting in response mode of 0x25 (same as the "All")
Mode 0x03 "DEP Passive" resulting in response mode of 0x04 "DEP"
It appears in all cases as if the Android is not maintaining the connection, although I am not familiar with the NFC DEP protocols enough to know what I'm doing wrong here. I've read the PN532 chip reference, and it seems to indicate that I'm doing everything correctly.
I've also tried a Windows Phone NFC device, and it encounters the same problem and same error code on GetData.
Any help from anyone who is familiar with NFC would be greatly appreciated.
Dave

For getting the ACR122 (or rather the PN532 NFC controller chip inside it) into card emulation mode, you would do about the following:
ReadRegister:
> FF000000 08 D406 6305 630D 6338
< D507 xx yy zz 9000
Update register values:
xx = xx | 0x004; // CIU_TxAuto |= InitialRFOn
yy = yy & 0x0EF; // CIU_ManualRCV &= ~ParityDisable
zz = zz & 0x0F7; // CIU_Status2 &= ~MFCrypto1On
WriteRegister:
> FF000000 11 D408 6302 80 6303 80 6305 xx 630D yy 6338 zz
< D509 9000
SetParameters:
> FF000000 03 D412 30
< D513 9000
TgInitAsTarget
> FF000000 27 D48C 05 0400 123456 20 000000000000000000000000000000000000 00000000000000000000 00 00
< D58D xx ... 9000
Where xx should be equal to 0x08.
Communicate using a sequence of TgGetData and TgSetData commands:
> FF000000 02 D486
< D587 xx <C-APDU> 9000
Where xx is the status code (should be 0x00 for success) and C-APDU is the command sent from the reader.
> FF000000 yy D48E <R-APDU>
< D587 xx 9000
Where yy is 2 + the length of the R-APDU (response) and xx is the status code (should be 0x00 for success).

Related

Can a raspberry beacon retrieve any data

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.)

Send TgInitAsTarget command to PN532 (ELEHOUSE module),get ACK frame back, but lost the normal information frame

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 .

Emulate NdefMessage on ACS ACR1252U-A1

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 :)

ACR122U Answer D5 41 13 90 00 to mifare's read command

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?

how to access Mi-fare ultralight 1k tag

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.

Resources