search

desowin / usbpcap

USB packet capture for Windows
http://desowin.org/usbpcap
902 stars 170 forks source link

Setup data captured by USBPcap might differ from the Setup Data that was sent to the device #83

Open desowin opened 5 years ago

desowin commented 5 years ago

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.

desowin commented 5 years ago

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.

desowin commented 5 years ago

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.