I am trying to perform Apple pay transaction. The card edded to apple pay wallet is MasterCard. If I perform a contactless transaction using a physical card, my code works. But when I try to do the same with ApplePay, I get SW 6700 (wrong length) status after the GENERATE AC command.
Here you can see how I construct data for GAC request:
9f02 06 000000000100 Amount, Authorised (Numeric)
9f03 06 000000000000 Amount, Other (Numeric)
9f1a 02 0804 Terminal Country Code
95 05 0000000000 Terminal Verification Results
5f2a 02 0980 Transaction Currency Code
9a 03 210511 Transaction Date
9c 01 00 Transaction Type
9f37 04 3357A30A Unpredictable Number
9f35 01 21 Terminal Type
9f45 02 0000 Data Authentication Code
9f4c 08 0000000000000000 ICC Dynamic Number
9f34 03 1F0302 Cardholder Verification Method (CVM) Results
9f21 03 131340 Transaction Time HHMMSS
9f7c 14(20 dec) 0000000000000000000000000000000000000000 Customer Exclusive Data (CED)
So, my final data is:
80 AE 8000 42 000000000030 000000000000 0804 0000008001 0980 210511 00 3357A30A 21 0000 0000000000000000 1F0302 133040 0000000000000000000000000000000000000000 00
Le byte is 42 (66 dec) and it is correct if physical card is used.
What is wrong with Apple Pay?
The problem is that CDOL1 differs when using ApplePay with the same card.
Thus tag 0x8C (CDOL1) using ApplePay is:
9f02069f03069f1a0295055f2a029a039c019f37049f35019f45029f4c089f34039f1d089f15029f4e14
And using physical contactless card (MasterCard):
9f02069f03069f1a0295055f2a029a039c019f37049f35019f45029f4c089f34039f21039f7c14
So, they are not equal, and deconstruction gives us such a data items:
9f02 06 000000000100
9f03 06 000000000000
9f1a 02 0804
95 05 0000000000
5f2a 02 0980
9a 03 210511
9c 01 00
9f37 04 3357A30A
9f35 01 21
9f45 02 0000
9f4c 08 0000000000000000
9f34 03 1F0302
9f1d 08 6CF8000000000000
9f15 02 0000
9f4e 14 0000000000000000000000000000000000000000
So, the final data for GENERATE AC command should be:
80 AE 8000 49 000000000030 000000000000 0804 0000008001 0980 210511 00 3357A30A 21 0000 0000000000000000 1F0302 6CF8000000000000 0000 0000000000000000000000000000000000000000 00
Le = 73 dec / 0x49 hex.
This works fine.
Related
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.)
We are developing a project based on Chrome (old USB API now migrating to WEBUSB) and a webcam. The USB Webcam has a button used for taking picture. In MAC and Linux I can show the live video of the webcam using getUserMedia () and on the same time I can use Web USB API to communicate with the device for detecting button press.
The problem is windows. On Windows Chorme can see the USB device as a Webcam accessible from getUserMedia (if I install the usb device original driver) or as USB device accessible form WebUSB (if I replace the original driver with WINUSB) but we are unable to use the two API toghether. This is a problem only on WINDOWS, in Mac or Linux all is working. How can we solve this?
N.B.
To make the javascript USB commands work on linux and OSX I had to replace "interface" with "endpoint" in transfer commands.
Linux lsusb dump:
Bus 001 Device 008: ID a168:0872 AnMo Electronics Corporation
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
idVendor 0xa168 AnMo Electronics Corporation
idProduct 0x0872
bcdDevice 20.01
iManufacturer 1 ANMO Electronics Corporation
iProduct 2 Dino-Lite Premier
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 509
bNumInterfaces 2
bConfigurationValue 1
iConfiguration 0
bmAttributes 0x80
(Bus Powered)
MaxPower 500mA
Interface Association:
bLength 8
bDescriptorType 11
bFirstInterface 0
bInterfaceCount 2
bFunctionClass 14 Video
bFunctionSubClass 3 Video Interface Collection
bFunctionProtocol 0
iFunction 2 Dino-Lite Premier
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 1 Video Control
bInterfaceProtocol 0
iInterface 2 Dino-Lite Premier
VideoControl Interface Descriptor:
bLength 13
bDescriptorType 36
bDescriptorSubtype 1 (HEADER)
bcdUVC 1.00
wTotalLength 80
dwClockFrequency 6.000000MHz
bInCollection 1
baInterfaceNr( 0) 1
VideoControl Interface Descriptor:
bLength 18
bDescriptorType 36
bDescriptorSubtype 2 (INPUT_TERMINAL)
bTerminalID 1
wTerminalType 0x0201 Camera Sensor
bAssocTerminal 0
iTerminal 0
wObjectiveFocalLengthMin 0
wObjectiveFocalLengthMax 0
wOcularFocalLength 0
bControlSize 3
bmControls 0x000200a2
Auto-Exposure Mode
Focus (Absolute)
Iris (Absolute)
Focus, Auto
VideoControl Interface Descriptor:
bLength 11
bDescriptorType 36
bDescriptorSubtype 5 (PROCESSING_UNIT)
Warning: Descriptor too short
bUnitID 3
bSourceID 1
wMaxMultiplier 0
bControlSize 2
bmControls 0x0000147f
Brightness
Contrast
Hue
Saturation
Sharpness
Gamma
White Balance Temperature
Power Line Frequency
White Balance Temperature, Auto
iProcessing 0
bmVideoStandards 0x1d
None
PAL - 625/50
SECAM - 625/50
NTSC - 625/50
VideoControl Interface Descriptor:
bLength 29
bDescriptorType 36
bDescriptorSubtype 6 (EXTENSION_UNIT)
bUnitID 4
guidExtensionCode {2652215a-8932-5641-894a-5c557cdf9664}
bNumControl 16
bNrPins 1
baSourceID( 0) 3
bControlSize 4
bmControls( 0) 0xff
bmControls( 1) 0xff
bmControls( 2) 0xff
bmControls( 3) 0xff
iExtension 0
VideoControl Interface Descriptor:
bLength 9
bDescriptorType 36
bDescriptorSubtype 3 (OUTPUT_TERMINAL)
bTerminalID 2
wTerminalType 0x0101 USB Streaming
bAssocTerminal 0
bSourceID 4
iTerminal 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0008 1x 8 bytes
bInterval 9
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x0000 1x 0 bytes
bInterval 1
INTERFACE CLASS: 0f 24 01 02 67 01 82 00 02 01 01 00 01 00 00
INTERFACE CLASS: 0b 24 06 01 05 00 01 00 00 00 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 02 00 40 01 f0 00 80 00 02 32 80 00 02 32 00 58 02 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 03 00 a0 00 78 00 a0 00 00 8c a0 00 00 8c 00 96 00 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 07 04 00 00 05 00 04 00 00 19 00 00 00 19 00 00 00 28 00 20 a1 07 00 01 20 a1 07 00
INTERFACE CLASS: 1e 24 07 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1b 24 04 02 05 59 55 59 32 00 00 10 00 80 00 00 aa 00 38 9b 71 10 01 00 00 00 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 02 00 40 01 f0 00 80 00 02 32 80 00 02 32 00 58 02 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 03 00 a0 00 78 00 a0 00 00 8c a0 00 00 8c 00 96 00 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 1e 24 05 04 00 00 05 00 04 00 00 19 00 00 00 19 00 00 00 28 00 20 a1 07 00 01 20 a1 07 00
INTERFACE CLASS: 1e 24 05 01 00 80 02 e0 01 00 00 08 ca 00 00 08 ca 00 60 09 00 15 16 05 00 01 15 16 05 00
INTERFACE CLASS: 06 24 0d 00 00 00
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 1
bNumEndpoints 1
bInterfaceClass 14 Video
bInterfaceSubClass 2 Video Streaming
bInterfaceProtocol 0
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 5
Transfer Type Isochronous
Synch Type Asynchronous
Usage Type Data
wMaxPacketSize 0x13fc 3x 1020 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 239 Miscellaneous Device
bDeviceSubClass 2
bDeviceProtocol 1 Interface Association
bMaxPacketSize0 64
bNumConfigurations 1
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0000
(Bus Powered)
Based on the output from lsusb -v above I can see that this device has a single function comprised of two USB interfaces. The Interface Association Descriptor (IAD) signals to the host operating system that these two interfaces are related and operating systems like Windows will treat them as a single interface for the purposes of driver binding.
My guess is that on Linux and macOS you are able to communicate with the EP 1 IN endpoint because only interface 1 is claimed by the USB video class (UVC) driver. On Windows, since it considers both interfaces a single entity "function 0", you are unable to claim interface 0 because interface 1 is already claimed as part of function 0.
I've successfully been able to retrieve the card number and expiry date from a contactless debit/credit card. However, the cardholder name is not being returned in the READ RECORD command response. Am I missing a something?
- Select Application
# IN_DATA_EXCHANGE
>> D4 40 01 00 A4 04 00 07 A0 00 00 00 03 10 10 00
<< D5 41 00 6F 43 84 07 A0 00 00 00 03 10 10 A5 38 50 10 56 69 73 61 20 20 20 20 20 20 20 20 20 20 20 20 9F 38 18 9F 66 04 9F 02 06 9F 03 06 9F 1A 02 95 05 5F 2A 02 9A 03 9C 01 9F 37 04 BF 0C 08 9F 5A 05 31 08 26 08 26 90 00
- Read the card
# IN_DATA_EXCHANGE
>> D4 40 01 00 B2 01 0C 00
<< D5 41 00 70 12 57 10 XX XX XX XX XX XX XX XX D1 50 52 01 00 00 00 01 90 00
It's not uncommon for an EMV payment card to not reveal the cardholder name over the contactless interface. In fact, all major brands have introduced this as a privacy feature. On many cards the cardholder name field (tag 5F20) is present but filled with a string like " /" to indicate that the cardholder name is not to be revealed. At least for Visa cards (like the one you have above) the cardholder name field is not mandatory (and if its not present, its value should be assumed as " /"). You might want to also check other records/files on the card. Some cards also provide this field in response to the GET PROCESSING OPTIONS command only.
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 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).