Setup data captured by USBPcap might differ from the Setup Data that was sent to the device #83
Comments
|
I have observed that (atleast) on Windows 10 Enterprise 2016 LTSB (build 1607) the GET DESCRIPTOR functions does not necessarily return as URB_FUNCTION_CONTROL_TRANSFER but instead return the same URB code. This results in the data being captured as unknown URB. This is pretty severe issue as the descriptors are not available in the trace which makes dissection difficult. The string descriptors seems to be captured properly as they do return with URB_FUNCTION_CONTROL_TRANSFER even though they use the same URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE as they configuration/device descriptor requests. This bug affects USBPcap 1.4.1.0 and 1.5.0.0. |
THe official USB 3.0 stack, unlike USB 2.0 stack, does not necessarily change the URB function when the IRP is travelling back from PDO. USBPcap 1.4.1.0 introduced new mechanism for control transfer capture that relied on the (false) assumption that the IRP will have the URB function changed to URB_FUNCTION_CONTROL_TRANSFER when travelling back from PDO. This resulted in DEVICE and CONFIGURATION descriptors not being captured for USB 3.0 devices connected to USB 3.0 host on recent Windows versions. This change restores the old mechanism for control transfer capture if the IRP does not travel back with changed URB function code. As the Setup packet is now manually created it should be checked if it is still affected by the issue #83.
|
USBPcap 1.5.1.0 helps in some cases, but there still are problematic cases. I have just seen an IRP that returned back from PDO with the URB_FUNCTION_CONTROL_TRANSFER that did contain invalid SetupPacket data (it was URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE on its way to PDO). Thus the URB_FUNCTION_CONTROL_TRANSFER SetupPacket cannot be trusted on its way from PDO to FDO. As this is rather serious issue, the whole new approach should be removed even if the IRP travels back as URB_FUNCTION_CONTROL_TRANSFER. |
It turns out that there are specific Windows/USB Root Hub/USB Device combinations for which the initially "unknown URB" that returns from PDO as URB_FUNCTION_CONTROL_TRANSFER *DOES NOT* contain valid SetupPacket data. Thus do not rely on this, and instead revert completely to the old capture method of control packets. See issue #83 for more information.
Observed with HID Report GET DESCRIPTOR requests. The interface in the Setup packet is not necessarily matching. The general approach behind the control transfers capture should be refactored.
The text was updated successfully, but these errors were encountered: