I’m capturing USB traffic using Wireshark
on a smart card reader. When I connect to the reader using PyScard
, some packets are sent back and forth using bulk operations before I send any APDU just by establishing the connection.
I have read here that there is an initial handshake between a USB device and the host and I wonder if that is what I see while sniffing.
Using wireshark, I get the following:
- Bulk out (host to device):
- Bulk out (device to host):
- Bulk in (host to device):
- Bulk in (device to host):
These four packets are sent 2-3 times and then I can sniff the messages I send using PyScard.
My goal here is to reproduce the communication between the reader and the host by using only USB communications. So:
Is there an initial handshake in USB communications?
Is that what I’m capturing?
How can I reproduce this USB communications?
Thanks <3
Edit 14/03/2018 – Additional information following David Grayson’s answer
What I am capturing here is not the part of “Get Device Descriptor”, etc. This happens when I try to print the device’s details and Wireshark recognises and labels the packets as so.
I’m aware of the weird operations but it is what I’m getting from wireshark. The interpretation I’ve been doing is that they’re request-response pairs: the host sends something using bulk out endpoint and then asks to read the answer by using bulk in endpoint when it is ready to do so. I have absolutely no idea, it’s just what it looks to me.
>> lsusb -v Bus 001 Device 002: ID 0bda:0165 Realtek Semiconductor Corp. Couldn't open device, some information will be missing Device Descriptor: bLength bDescriptorType 1 bcdUSB 2.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0x0bda Realtek Semiconductor Corp. idProduct 0x0165 bcdDevice 61.23 iManufacturer 1 iProduct 6 iSerial 3 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 93 bNumInterfaces 1 bConfigurationValue 1 iConfiguration 4 bmAttributes 0xa0 (Bus Powered) Remote Wakeup MaxPower 500mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 3 bInterfaceClass 11 Chip/SmartCard bInterfaceSubClass 0 bInterfaceProtocol 0 iInterface 6 ChipCard Interface Descriptor: bLength 54 bDescriptorType 33 bcdCCID 1.10 (Warning: Only accurate for version 1.0) nMaxSlotIndex 0 bVoltageSupport 7 5.0V 3.0V 1.8V dwProtocols 3 T=0 T=1 dwDefaultClock 3750 dwMaxiumumClock 7500 bNumClockSupported 0 dwDataRate 10080 bps dwMaxDataRate 312500 bps bNumDataRatesSupp. 0 dwMaxIFSD 254 dwSyncProtocols 00000000 dwMechanical 00000000 dwFeatures 00010030 Auto clock change Auto baud rate change TPDU level exchange dwMaxCCIDMsgLen 271 bClassGetResponse 00 bClassEnvelope 00 wlcdLayout none bPINSupport 0 bMaxCCIDBusySlots 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0040 1x 64 bytes bInterval 8 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x05 EP 5 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x86 EP 6 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0
(The screenshots are ok, they look alike but they’re not the same)
Advertisement
Answer
The initial handshake consists of controls transfers like “Get Device Descriptor”, “Get Configuration Descriptor” and “Set Address”, which are defined in Chapter 9 of the USB 2.0 specification.
The initial handshake usually does not have any bulk transfers, but it is possible that your device uses a driver which wants to do some bulk transfers when it gets initialized. Since it is a smart card reader, I imagine your operating system has some driver that sends commands to it in order to see if any smart cards are connected, and those commands could very well be implemented with bulk transfers instead of control transfers. To learn more about these commands, you would need to find the documentation of the USB class that your device implements and/or the driver that is sending these commands.
The description of your bulk traffic is confusing. The term “Out” always means “Host to device” so it cannot mean “Device to host” also. The term “In” always means “Device to host” so it cannot mean “Host to device” also. You posted two duplicate screenshots.
To get better responses in the future, I think you should include a dump of your device’s descriptors (lsusb -v
), improve your description of the traffic, say what endpoints the traffic was seen on, and also say what operating system you are using and give any information you have about the drivers that are attached to your device.