i'm using this open source lib as a ZVT implementation.
I have problems with the reversal of older transactions.
The example shows how to reverse the most recent transaction.
The ZVT Protocol (p.40) says to send the following to the terminal:
image link
tags in this brackets "[ ]" are optional.
I tried sending this:
06 30 06 12 34 5F 87 00 85
06 30 = Reversal
06 = 6 bytes length
12 34 5 = password with F as Filler?
87 = receipt no
00 85 = receipt no. 85
The password is: 12345
I dont know how to fill the empty space (uneven password). 0 and F does not work.
The receipt-no is a 2 byte long.
But the Terminal replies with error code "181" -> reversal not possible
my payment terminal is a iCT220.
Had to send
06 30 06 00 00 00 87 00 85
And watch out that 87 indicates the receipt-no. not the trace-no.
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 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 :)
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")
I try send wap push message. I set datacoding 0xf5 and send submit sm with following message:
GSM Short Message Service User Data
udh length: 6
16-bit address 05 04
Destination port 08b4
Source port 23f0
Wireless Session Protocol, Method: Push (0x06), Content-Type: application/vnd.wap.sic
Transaction Id: 0x25
PDU Type: Push (0x06)
Header length: 1
Content type: application/vnd.wap.sic
WAP Binary XML, Version: 1.2, Public ID: "-//WAPFORUM//DTD SI 1.0//EN (Service Indication 1 .0)"
Version: 1.2 (0x02)
Public Identifier: (known): -//WAPFORUM//DTD SI 1.0//EN (Service Indication 1 .0)
Character Set: utf-8 (0x000006a)
String table: 0 bytes
Data representation:
45 <si>
c6 <indication
0c href='http://'
03 69 2e 69 6d 67 75 72 2e 63 6f 6d 2f 66 6a 49 44 4e 2e 6a 70 67 00 i.imgur.com/fjIDN.jpg'
07 action='signal-medium'
01 >
03 69 6d 67 75 72 00 'imgur'
01 </indication>
01 </si>
Message bytes:
06 05 04 0b 84 23 f0 25 06 01 ae 02 05 6a 00 45
c6 0c 03 69 2e 69 6d 67 75 72 2e 63 6f 6d 2f 66
6a 49 44 4e 2e 6a 70 67 00 07 01 03 69 6d 67 75
72 00 01 01
SMSC return: Submit_sm - resp: "OK".
But the phone did not show nothing. Any ideas?
Sorry for my ugly english :)
I can't fully justify why these changes work, but from extensive testing a few years back the following seemed to work reliably across the UK networks and a range of different handsets. It's in use in production code and we haven't seen any problems since.
06 - UDHL
05 - EI (Send to Ports 16bit addr)
04 - EIDL
0B - src port
84 - src port
23 - dest port
F0 - dest port (End of UDH)
01 - trans id
06 - Push
04 - Header Length
03 - Length
AE - Content type (application/vnd.wap.sic)
81 - Character Set (01 once removed high bit)
EA - UTF 8 (6A once removed high bit)
02 - Binary XML Version 1.2
05 - SI Identifier
6A - UTF-8
00 - End Data
45 - SI Binary XML Tag
C6 - Indication Tag
0B - href
03 - Open Text
(URL bytes go here...)
00 - End Data
0A - Created (date)
C3 - Data Follows
07 - Data Length
20 - date yy (century)
08 - date yy (year)
03 - date mm
26 - date dd
16 - date HH
09 - date MM
12 - date ss
01 - Close Attribute
03 - Open Text (Text Goes in here...)
00 - End Data
01 - Close Indication Tag
01 - Close SI Tag
There are a few differences to your send:
UTF-8 Character set specified on the Wireless Session Protocol header
http:// is written in full as bytes, I don't think this made a difference but it was required by the rest of our application.
No action on the indication tag
Added a created date attribute - This seemed to make a big difference to handset support (I'm not quite sure why).