I am coding for a Mac app that sends and receives messages to a Personel Video Recorder using with the IOKit. I need to send messages to change its status and it needs to give me info about the video like resolution or if its recording. I realize that I have to find the right messages to send it, so first I thought I could receive some messages from it first. I have already found the interface for the device. How would I be able to dump the received messages?
Here is a log from USB Probe:
Composite device: "PVR"
Port Information: 0x001d
Captive
Internal Device
Connected
Enabled
Number Of Endpoints (includes EP0):
Total Endpoints for Configuration 1 (current): 7
Device Descriptor
Descriptor Version Number: 0x0200
Device Class: 0 (Composite)
Device Subclass: 0
Device Protocol: 0
Device MaxPacketSize: 64
Device VendorID/ProductID: 0x2040/0xE502 (Hauppauge Computer Works, Inc.)
Device Version Number: 0x0800
Number of Configurations: 1
Manufacturer String: 1 "Hauppauge"
Product String: 2 "WinTV"
Serial Number String: 3 "E502-00-00AA3DEE"
Configuration Descriptor (current config)
Length (and contents): 60
Raw Descriptor (hex) 0000: 09 02 3C 00 01 01 00 C0 00 09 04 00 00 06 FF FF
Raw Descriptor (hex) 0010: FF 00 07 05 81 02 00 02 00 07 05 84 02 00 02 00
Raw Descriptor (hex) 0020: 07 05 88 02 00 02 00 07 05 01 02 00 02 00 07 05
Raw Descriptor (hex) 0030: 02 02 00 02 00 07 05 86 02 00 02 00
Number of Interfaces: 1
Configuration Value: 1
Attributes: 0xC0 (self-powered)
MaxPower: 0 mA
Interface #0 - Vendor-specific
Alternate Setting 0
Number of Endpoints 6
Interface Class: 255 (Vendor-specific)
Interface Subclass; 255 (Vendor-specific)
Interface Protocol: 255
Endpoint 0x81 - Bulk Input
Address: 0x81 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Endpoint 0x84 - Bulk Input
Address: 0x84 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Endpoint 0x88 - Bulk Input
Address: 0x88 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Endpoint 0x01 - Bulk Output
Address: 0x01 (OUT)
Attributes: 0x02 (Bulk)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Endpoint 0x02 - Bulk Output
Address: 0x02 (OUT)
Attributes: 0x02 (Bulk)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Endpoint 0x86 - Bulk Input
Address: 0x86 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 512
Polling Interval: 0 ( Endpoint never NAKs)
Device Qualifier Descriptor
Descriptor Version Number: 0x0200
Device Class 0 (Composite)
Device Subclass 0
Device Protocol 0
Device MaxPacketSize: 64
Number of Configurations: 1
bReserved: 0
Other Speed Configuration Descriptor
Length (and contents): 60
Raw Descriptor (hex) 0000: 09 07 3C 00 01 01 00 C0 00 09 04 00 00 06 FF FF
Raw Descriptor (hex) 0010: FF 00 07 05 81 02 40 00 00 07 05 84 02 40 00 00
Raw Descriptor (hex) 0020: 07 05 88 02 40 00 00 07 05 01 02 40 00 00 07 05
Raw Descriptor (hex) 0030: 02 02 40 00 00 07 05 86 02 40 00 00
Number of Interfaces: 1
Configuration Value: 1
Attributes: 0xC0 (self-powered)
MaxPower: 0 mA
Interface #0 - Vendor-specific
Alternate Setting 0
Number of Endpoints 6
Interface Class: 255 (Vendor-specific)
Interface Subclass; 255 (Vendor-specific)
Interface Protocol: 255
Endpoint 0x81 - Bulk Input
Address: 0x81 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
Endpoint 0x84 - Bulk Input
Address: 0x84 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
Endpoint 0x88 - Bulk Input
Address: 0x88 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
Endpoint 0x01 - Bulk Output
Address: 0x01 (OUT)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
Endpoint 0x02 - Bulk Output
Address: 0x02 (OUT)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
Endpoint 0x86 - Bulk Input
Address: 0x86 (IN)
Attributes: 0x02 (Bulk)
Max Packet Size: 64
Polling Interval: 0 ms
USB is host-driven. This means the device doesn't send any messages except as replies to messages from the host (Mac/PC). So to elicit a message from it, you will first need to send it a valid message.
I assume from your question that you don't actually have any documentation/specification for the device in question? This means you'll need to obtain that information, either by asking the manufacturer for it, or via reverse engineering it.
The easiest way to reverse engineer it is to listen in on the messages generated by an existing driver, e.g. some Windows software that does something similar to what you want to do. Then you need to listen in on the data. In the past, I've had success running the Windows software in a VM on Linux and passing through the USB device in question to the VM, and using Linux' USB debugging features to log the output. You should be able to do the same on OSX using the "USB Prober" application with the "IOUSBFamily Log Release" available from Apple's developer download area.
Related
I am trying to implement a SSL client into my IoT project. I have copied the SSL_Client example I found in STM32Cube_FW_F7_V1.15.0 into my project and was able to compile succesfully. However the SSL handshake fails with -0x7780 MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE. I attach the console debug output:
. Seeding the random number generator... ok
. Loading the CA root certificate ... ok (1 skipped)
. Connecting to tcp/www.google.de/443... ok
. Setting up the SSL/TLS structure... ok
. Performing the SSL/TLS handshake...=> handshake
client state: 0
=> flush output
<= flush output
client state: 1
=> flush output
<= flush output
=> write client hello
client hello, max version: [3:3]
dumping 'client hello, random bytes' (32 bytes)
0000: e2 13 bf 6d 61 b6 fb a6 82 a4 59 f0 0b ef e9 03 ...ma.....Y.....
0010: 44 be de 3c 49 3d 39 56 51 60 3b b6 49 c4 17 50 D..<I=9VQ`;.I..P
client hello, session id len.: 0
dumping 'client hello, session id' (0 bytes)
client hello, add ciphersuite: c02b
client hello, got 1 ciphersuites (excluding SCSVs)
adding EMPTY_RENEGOTIATION_INFO_SCSV
client hello, compress len.: 1
client hello, compress alg.: 0
client hello, adding server name extension: www.google.de
client hello, adding signature_algorithms extension
client hello, adding supported_elliptic_curves extension
client hello, adding supported_point_formats extension
client hello, adding encrypt_then_mac extension
client hello, adding extended_master_secret extension
client hello, adding session ticket extension
client hello, total extension length: 62
=> write handshake message
=> write record
output record: msgtype = 22, version = [3:3], msglen = 111
dumping 'output record sent to network' (116 bytes)
0000: 16 03 03 00 6f 01 00 00 6b 03 03 e2 13 bf 6d 61 ....o...k.....ma
0010: b6 fb a6 82 a4 59 f0 0b ef e9 03 44 be de 3c 49 .....Y.....D..<I
0020: 3d 39 56 51 60 3b b6 49 c4 17 50 00 00 04 c0 2b =9VQ`;.I..P....+
0030: 00 ff 01 00 00 3e 00 00 00 12 00 10 00 00 0d 77 .....>.........w
0040: 77 77 2e 67 6f 6f 67 6c 65 2e 64 65 00 0d 00 0a ww.google.de....
0050: 00 08 04 03 04 01 03 03 03 01 00 0a 00 04 00 02 ................
0060: 00 15 00 0b 00 02 01 00 00 16 00 00 00 17 00 00 ................
0070: 00 23 00 00 .#..
=> flush output
message length: 116, out_left: 116
ssl->f_send() returned 116 (-0xffffff8c)
<= flush output
<= write record
<= write handshake message
<= write client hello
client state: 2
=> flush output
<= flush output
=> parse server hello
=> read record
=> fetch input
in_left: 0, nb_want: 5
in_left: 0, nb_want: 5
ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
<= fetch input
dumping 'input record header' (5 bytes)
0000: 15 03 03 00 02 .....
input record: msgtype = 21, version = [3:3], msglen = 2
=> fetch input
in_left: 5, nb_want: 7
in_left: 5, nb_want: 7
ssl->f_recv(_timeout)() returned 2 (-0xfffffffe)
<= fetch input
dumping 'input record from network' (7 bytes)
0000: 15 03 03 00 02 02 28 ......(
got an alert message, type: [2:40]
is a fatal alert message (msg 40)
mbedtls_ssl_handle_message_type() returned -30592 (-0x7780)
mbedtls_ssl_read_record() returned -30592 (-0x7780)
ERR
<= handshake
failed
! mbedtls_ssl_handshake returned -0x7780
Any help is greatly appreciated!
UPDATE:
The problem was the key exchange method. Only MBEDTLS_KEY_EXCHANGE_ECDHE_ECDSA_ENABLED was active. After i added MBEDTLS_KEY_EXCHANGE_ECDHE_RSA_ENABLED ( along with the needed MBEDTLS_RSA_C, MBEDTLS_PKCS1_V21 and MBEDTLS_PKCS1_V15) the handshake took place. Thanks a lot for pointing me to the right directon Gilles
The connection fails because the server decides to close the connection immediately after receiving the very first TLS message (ClientHello). It's sending the alert 40, which is “handshake failure”. Unfortunately, that's a generic “I don't like what I heard and I can't talk with you”, it doesn't give any information about what precisely it didn't like. Your TLS client is either buggy or, most likely, misconfigured and sent something that Google's server didn't accept.
Wireshark is helpful in diagnosing network protocol issues. Let's see what it says about the data sent by your client. I'm not a Wireshark expert so I did it the manual way, by starting Wireshark, telling it to listen to port 443 && host www.google.de and replaying the connection with
<clienthello.hex xxd -r -p | socket www.google.de 443 | xxd -p
Here's the dump of the ClientHello provided by Wireshark:
TLSv1.2 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.2 (0x0303)
Length: 111
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 107
Version: TLS 1.2 (0x0303)
Random: e213bf6d61b6fba682a459f00befe90344bede3c493d3956…
GMT Unix Time: Mar 11, 2090 20:50:05.000000000 CET
Random Bytes: 61b6fba682a459f00befe90344bede3c493d395651603bb6…
Session ID Length: 0
Cipher Suites Length: 4
Cipher Suites (2 suites)
Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
Compression Methods Length: 1
Compression Methods (1 method)
Compression Method: null (0)
Extensions Length: 62
Extension: server_name (len=18)
Type: server_name (0)
Length: 18
Server Name Indication extension
Server Name list length: 16
Server Name Type: host_name (0)
Server Name length: 13
Server Name: www.google.de
Extension: signature_algorithms (len=10)
Type: signature_algorithms (13)
Length: 10
Signature Hash Algorithms Length: 8
Signature Hash Algorithms (4 algorithms)
Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
Signature Hash Algorithm Hash: SHA256 (4)
Signature Hash Algorithm Signature: RSA (1)
Signature Algorithm: SHA224 ECDSA (0x0303)
Signature Hash Algorithm Hash: SHA224 (3)
Signature Hash Algorithm Signature: ECDSA (3)
Signature Algorithm: SHA224 RSA (0x0301)
Signature Hash Algorithm Hash: SHA224 (3)
Signature Hash Algorithm Signature: RSA (1)
Extension: supported_groups (len=4)
Type: supported_groups (10)
Length: 4
Supported Groups List Length: 2
Supported Groups (1 group)
Supported Group: secp224r1 (0x0015)
Extension: ec_point_formats (len=2)
Type: ec_point_formats (11)
Length: 2
EC point formats Length: 1
Elliptic curves point formats (1)
EC point format: uncompressed (0)
Extension: encrypt_then_mac (len=0)
Type: encrypt_then_mac (22)
Length: 0
Extension: extended_master_secret (len=0)
Type: extended_master_secret (23)
Length: 0
Extension: session_ticket (len=0)
Type: session_ticket (35)
Length: 0
Data (0 bytes)
Looking through this, most of the stuff is unsurprising except this:
Supported Groups (1 group)
Supported Group: secp224r1 (0x0015)
Secp224r1 is a little-used and officially deprecated curve. Very few servers accept it.
Reconfigure Mbed TLS to support secp256r1 instead. That's the de facto standard curve for resource-constrained devices for ECDH+ECDSA (either that, or Curve25519+Ed25519 for ECDH+EdDSA). In mbedtls/config.h, instead of listing MBEDTLS_ECP_DP_SECP224R1_ENABLED, list MBEDTLS_ECP_DP_SECP256R1_ENABLED. If you set MBEDTLS_ECP_MAX_BITS, make sure that it's set to 256 (or more).
I am trying to implement a SSL client into my IoT project. I have copied the SSL_Client example I found in STM32Cube_FW_F7_V1.15.0 into my project and was able to compile succesfully. However the SSL handshake fails with -0x7780 MBEDTLS_ERR_SSL_FATAL_ALERT_MESSAGE. I attach the console debug output:
. Seeding the random number generator... ok
. Loading the CA root certificate ... ok (1 skipped)
. Connecting to tcp/www.google.de/443... ok
. Setting up the SSL/TLS structure... ok
. Performing the SSL/TLS handshake...=> handshake
client state: 0
=> flush output
<= flush output
client state: 1
=> flush output
<= flush output
=> write client hello
client hello, max version: [3:3]
dumping 'client hello, random bytes' (32 bytes)
0000: 88 d9 c4 b1 4f 82 ef a2 74 80 5c 6e 3f c4 29 ca ....O...t.\n?.).
0010: a4 8d 61 2b f6 37 ec 93 39 cb 7d d0 39 5a 67 9b ..a+.7..9.}.9Zg.
client hello, session id len.: 0
dumping 'client hello, session id' (0 bytes)
client hello, add ciphersuite: c02b
client hello, add ciphersuite: c031
client hello, add ciphersuite: c02d
client hello, add ciphersuite: 00a8
client hello, got 4 ciphersuites (excluding SCSVs)
adding EMPTY_RENEGOTIATION_INFO_SCSV
client hello, compress len.: 1
client hello, compress alg.: 0
client hello, adding server name extension: mbed TLS Server 1
client hello, adding signature_algorithms extension
client hello, adding supported_elliptic_curves extension
client hello, adding supported_point_formats extension
client hello, adding encrypt_then_mac extension
client hello, adding extended_master_secret extension
client hello, total extension length: 62
=> write handshake message
=> write record
output record: msgtype = 22, version = [3:3], msglen = 117
dumping 'output record sent to network' (122 bytes)
0000: 16 03 03 00 75 01 00 00 71 03 03 88 d9 c4 b1 4f ....u...q......O
0010: 82 ef a2 74 80 5c 6e 3f c4 29 ca a4 8d 61 2b f6 ...t.\n?.)...a+.
0020: 37 ec 93 39 cb 7d d0 39 5a 67 9b 00 00 0a c0 2b 7..9.}.9Zg.....+
0030: c0 31 c0 2d 00 a8 00 ff 01 00 00 3e 00 00 00 16 .1.-.......>....
0040: 00 14 00 00 11 6d 62 65 64 20 54 4c 53 20 53 65 .....mbed TLS Se
0050: 72 76 65 72 20 31 00 0d 00 0a 00 08 04 03 04 01 rver 1..........
0060: 03 03 03 01 00 0a 00 04 00 02 00 17 00 0b 00 02 ................
0070: 01 00 00 16 00 00 00 17 00 00 ..........
=> flush output
message length: 122, out_left: 122
ssl->f_send() returned 122 (-0xffffff86)
<= flush output
<= write record
<= write handshake message
<= write client hello
client state: 2
=> flush output
<= flush output
=> parse server hello
=> read record
=> fetch input
in_left: 0, nb_want: 5
in_left: 0, nb_want: 5
ssl->f_recv(_timeout)() returned 5 (-0xfffffffb)
<= fetch input
dumping 'input record header' (5 bytes)
0000: 15 03 03 00 02 .....
input record: msgtype = 21, version = [3:3], msglen = 2
=> fetch input
in_left: 5, nb_want: 7
in_left: 5, nb_want: 7
ssl->f_recv(_timeout)() returned 2 (-0xfffffffe)
<= fetch input
dumping 'input record from network' (7 bytes)
0000: 15 03 03 00 02 02 28 ......(
got an alert message, type: [2:40]
is a fatal alert message (msg 40)
mbedtls_ssl_handle_message_type() returned -30592 (-0x7780)
mbedtls_ssl_read_record() returned -30592 (-0x7780)
<= handshake
failed
! mbedtls_ssl_handshake returned -0x7780
I am thankfull for every hint in the right direction.
client hello, adding server name extension: mbed TLS Server 1
The client is using the SNI extension to indicate that it wants to talk to mbed TLS Server 1. The server on port 443 of www.google.de can respond as www.google.de, google.de and a bunch of other names that Google controls, but it does know about mbed TLS Server 1, so it sends a fatal alert indicating that it cannot complete the handshake.
You can use the sample client as is to talk to the sample server whose source code should be next to it. To contact another server, you need to change or remove the call to mbedtls_ssl_set_hostname.
I'm trying to analyze a TLS library for Java (not Bouncy Castle). For some reason, Wireshark refuses to recognize a ClientHello fragment as such. Here is a hex dump of the TCP packet. I have broken it up into it's component parts to make it a bit easier to follow.
TCP stuff
020000004502008a000040004006f9ce0aa5001e5db8d822e28d01bbf3b9a9ab8c64a4fe8018081070fa00000101080a4e4e5d5845aa256f
16 TLS handshake record
0301 TLS v 1.0
0052 Fragment length 82 bytes
01 ClientHello message
00004e Message length 78 bytes
0303 TLS v 1.2
Client random
3c88c697bf2b559cc032faff7caccb17475ae76f36ededf279a9d1b9950e7367
00 Session ID length
0024 Cipher suite length 36 bytes 18 cipher suites
1301 1302 1303 c02b c02f cca9 ccaa c02c c030 c00a c009 c013 c014 009c 009d 002f 0035 000a
01 Compression methods length
00 Compression method null
0000 Extensions length
I'm at a loss to understand why Wireshark and several websites don't recognize this as a valid handshake record. Any help is appreciated.
EDIT:
I re-ran the capture to show how Wireshark interprets the network header.
The raw packet
0000 0c ea c9 75 61 30 3c 22 fb 01 07 f3 08 00 45 00
0010 00 8a 00 00 40 00 40 06 42 23 c0 a8 01 c8 5d b8
0020 d8 22 e9 3b 01 bb ee e9 99 55 53 56 a2 a8 80 18
0030 08 0a dc d0 00 00 01 01 08 0a 4e d6 03 2b db 4f
0040 3f fb 16 03 01 00 52 01 00 00 4e 03 03 8a 80 b9
0050 8c 73 ee 40 30 ef 65 1d 8c 51 d2 39 09 34 17 79
0060 d1 af e1 63 96 1a ac b4 ad 96 03 dd 7a 00 00 24
0070 13 01 13 02 13 03 c0 2b c0 2f cc a9 cc aa c0 2c
0080 c0 30 c0 0a c0 09 c0 13 c0 14 00 9c 00 9d 00 2f
0090 00 35 00 0a 01 00 00 00
The Wireshark interpretation
Frame 3616: 152 bytes on wire (1216 bits), 152 bytes captured (1216 bits) on interface en0, id 0
Interface id: 0 (en0)
Encapsulation type: Ethernet (1)
Arrival Time: Nov 3, 2020 09:03:23.957190000 EST
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1604412203.957190000 seconds
[Time delta from previous captured frame: 0.004793000 seconds]
[Time delta from previous displayed frame: 0.011314000 seconds]
[Time since reference or first frame: 49.409611000 seconds]
Frame Number: 3616
Frame Length: 152 bytes (1216 bits)
Capture Length: 152 bytes (1216 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: eth:ethertype:ip:tcp]
[Coloring Rule Name: TCP]
[Coloring Rule String: tcp]
Ethernet II, Src: Apple_01:07:f3 (3c:22:fb:01:07:f3), Dst: ARRISGro_75:61:30 (0c:ea:c9:75:61:30)
Destination: ARRISGro_75:61:30 (0c:ea:c9:75:61:30)
Source: Apple_01:07:f3 (3c:22:fb:01:07:f3)
Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.1.200, Dst: 93.184.216.34
0100 .... = Version: 4
.... 0101 = Header Length: 20 bytes (5)
Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
0000 00.. = Differentiated Services Codepoint: Default (0)
.... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
Total Length: 138
Identification: 0x0000 (0)
Flags: 0x40, Don't fragment
Fragment Offset: 0
Time to Live: 64
Protocol: TCP (6)
Header Checksum: 0x4223 [validation disabled]
[Header checksum status: Unverified]
Source Address: 192.168.1.200
Destination Address: 93.184.216.34
Transmission Control Protocol, Src Port: 59707, Dst Port: 443, Seq: 1, Ack: 1, Len: 86
Source Port: 59707
Destination Port: 443
[Stream index: 18]
[TCP Segment Len: 86]
Sequence Number: 1 (relative sequence number)
Sequence Number (raw): 4008286549
[Next Sequence Number: 87 (relative sequence number)]
Acknowledgment Number: 1 (relative ack number)
Acknowledgment number (raw): 1398186664
1000 .... = Header Length: 32 bytes (8)
Flags: 0x018 (PSH, ACK)
Window: 2058
[Calculated window size: 131712]
[Window size scaling factor: 64]
Checksum: 0xdcd0 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
Options: (12 bytes), No-Operation (NOP), No-Operation (NOP), Timestamps
[SEQ/ACK analysis]
[Timestamps]
TCP payload (86 bytes)
TCP segment data (86 bytes)
I Have successfully generated a ARQC by fulfilling the PDOL requirements as requested by the ICC (VISA). I would like to force all transactions with online PIN validation, irrespective of floor limits, pin try limits etc.
Do I need to still do another generate AC command or is the below sufficient to submit for online processing ?
Response Message Template Format 2 [77]:
Application Interchange Profile (AIP) [82]:
Data (Binary): 20 00
Bit flags set:
1Bxb8: 0 - RFU
1Bxb7: 0 - Off-line SDA is not supported
1Bxb6: 1 - Off-line DDA is supported
1Bxb5: 0 - Cardholder verification is not supported
1Bxb4: 0 - Terminal risk management not required
1Bxb3: 0 - Issuer Authentication not supported
1Bxb2: 0 - RFU
1Bxb1: 0 - CDA not supported
2Bxb8: 0 - MSD not supported (Contactless value)
2Bxb7: 0 - RFU
2Bxb6: 0 - RFU
2Bxb5: 0 - RFU
2Bxb4: 0 - RFU
2Bxb3: 0 - RFU
2Bxb2: 0 - RFU
2Bxb1: 0 - RFU
Application File Locator (AFL) [94]:
Data (Binary): 10 02 02 00 10 05 06 00 10 03 03 00
Track 2 Equivalent Data [57]:
Data (Binary): pp pp pp pp pp pp pp pp D2 20 72 26 00 00 00 03 43 00 0F
Cardholder Name [5F20]:
Data (Binary): 20 2F
Data (ASCII): /
Issuer Application Data (IAD) [9F10]:
Data (Binary): 06 01 11 03 A0 00 00 0F 83 00 00 00 00 00 00 00 00 00 00 E0 68 76 3A
Application Cryptogram (AC) [9F26]:
Data (Binary): FB 61 6D 9B 3F FC 00 7E
Cryptogram Information Data (CID) [9F27]:
Data (Binary): 80
Application Transaction Counter (ATC) [9F36]:
Data (Binary): cc cc
Card Transaction Qualifiers (CTQ) [9F6C]:
Data (Binary): 3E 40
Bit flags set:
1Bxb8: 0 - Online PIN not Required
1Bxb7: 0 - Signature Not Required
1Bxb6: 1 - Go Online if Offline Data Authentication Fails and Reader is online capable.
1Bxb5: 1 - Switch Interface if Offline Data Authentication fails and Reader supports VIS.
1Bxb4: 1 - Go Online if Application Expired
1Bxb3: 1 - Switch Interface for Cash Transactions
1Bxb2: 1 - Switch Interface for Cashback Transactions
1Bxb1: 0 - RFU
2Bxb8: 0 - Consumer Device CVM not Performed
2Bxb7: 1 - Card supports Issuer Update Processing at the POS
2Bxb6: 0 - RFU
2Bxb5: 0 - RFU
2Bxb4: 0 - RFU
2Bxb3: 0 - RFU
2Bxb2: 0 - RFU
2Bxb1: 0 - RFU
Customer Exclusive Data (CED) [9F7C]:
Data (Binary): 00 00 00 00
Form Factor Indicator (qVSDC) [9F6E]:
Data (Binary): 20 70 00 00
According the provided reply the CTQ Tag 0x9F6C there is no Online PIN, Signature or CDCVM required by card. Card Application expired and require to get final authorisation/approval online.
To force card to request Online PIN for all transactions you may set Floor limit to zero and exclude all other CVMs from Terminal Transaction Qualifiers (TTQ) Tag 0x9F66.
Up to your terminal configuration preferences to support Signature or CDCVM.
I am currently writing USB(EHCI) driver for pendrives in assembly for my OS.
I can successfully get the Device-, String-, Configuration(Interface and Endpoint)-descriptors.
However, the SCSI Inquiry and other commnads fail.
This is what I do (after getMaxLUN):
SetConfiguration(1)
Inquiry
Another way:
SetConfiguration(1)
TestUnitReady
RequestSense
TestUnitReady
I correctly set the EndPt in the QueueHead (BulkIn or BulkOut) and the device-address.
I am implementing the USB-driver by the book "B. D. Lunt - USB: The Universal Serial Bus".
If I send Inquiry, this is what I get (return buffer, 36 bytes, hex):
01 00 00 00 01 00 00 00 80 0D 24 00
40 15 16 00 00 20 16 00 00 30 16 00
00 40 16 00 00 50 16 00 00 00 00 00
the 11th byte is 0x24, the length of the returned data (36).
This looks garbage or an error message.
If I send TestUnitReady, then RequestSense returns (18 bytes, hex):
01 00 00 00 01 00 00 00 80 0D 12 00
C0 16 16 00 00 20
the 11th byte is 0x12, the length of the returned data (18).
The contents of the two returned buffers are similar. The CBW of Inquiry and TestUnitReady look good (I use LUN=0). The SCSI-spec-4 says something about an incorrect logical-unit, if the result is not the expected one, but I have only LUN 0.
I am testing with a Sony 4GB pendrive.
Inquiry should work immediately (return a correct data in the buffer) regardless of the CSW after it and I don't understand what the problem can be.
I am experimenting with BulkReset and Clear_Feature(for BulkIn and BulkOut) but that doesn't seem to fix the Inquiry.
The CSW of the TestUnitReady returns Status=01 but after a BulkReset and ClearFeature it returns Status=0 (success).
What can be the reason for the incorrect data in the buffer(s) ?
Any help is appreciated.
EDIT: I tried it with delays too (100ms before sending CBWs, getting CSWs).
It didn't help.
EDIT2: calling GetConfiguration() right after SetConfiguration(1), correctly returns 1.
EDIT3: This must be due to an incorrect pointer. I consider it solved.