| Bug ID |
12559
|
| Summary |
Incorrect decoding of USBHID packets
|
| Product |
Wireshark
|
| Version |
2.0.2
|
| Hardware |
x86
|
| OS |
Ubuntu
|
| Status |
UNCONFIRMED
|
| Severity |
Minor
|
| Priority |
Low
|
| Component |
Dissection engine (libwireshark)
|
| Assignee |
[email protected]
|
| Reporter |
[email protected]
|
Build Information:
Version 2.0.2 (SVN Rev Unknown from unknown)
Copyright 1998-2016 Gerald Combs <[email protected]> and contributors.
License GPLv2+: GNU GPL version 2 or later
<http://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled (64-bit) with Qt 5.5.1, with libpcap, with POSIX capabilities (Linux),
with libnl 3, with libz 1.2.8, with GLib 2.48.0, with SMI 0.4.8, with c-ares
1.10.0, with Lua 5.2, with GnuTLS 3.4.10, with Gcrypt 1.6.5, with MIT Kerberos,
with GeoIP, with QtMultimedia, without AirPcap.
Running on Linux 4.4.0-24-generic, with locale C, with libpcap version 1.7.4,
with libz 1.2.8, with GnuTLS 3.4.10, with Gcrypt 1.6.5.
AMD Athlon(tm) II Dual-Core M300
Built using gcc 5.3.1 20160407.
Wireshark is Open Source Software released under the GNU General Public
License.
Check the man page and http://www.wireshark.org for more information.
--
A USBHID packet with data incorrectly parses the packet for value bRequest.
bRequest is the byte following bRequestType, but the parser instead uses the
first byte of the packet. All subsequent bytes are off by one - i.e. wValue is
contains one byte of the actual wValue, and the other byte is the correct value
of bRequest.
(similar) Packet parsed correctly:
0000 c0 23 bd a8 ff ff ff ff 53 02 00 0e 01 00 00 00
0010 a1 5d 6e 57 00 00 00 00 19 00 01 00 00 00 00 00
0020 08 00 00 00 08 00 00 00 21 09 00 02 00 00 08 00
0030 14 11 1a 10 00 19 45 41
Frame 5752: 56 bytes on wire (448 bits), 56 bytes captured (448 bits) on
interface 0
USB URB
[Source: host]
[Destination: 1.14.0]
URB id: 0xffffffffa8bd23c0
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x00, Direction: OUT
Device: 14
URB bus id: 1
Device setup request: relevant (0)
Data: present (0)
URB sec: 1466850721
URB usec: 65561
URB status: Success (0)
URB length [bytes]: 8
Data length [bytes]: 8
[Response in: 5753]
[bInterfaceClass: Unknown (0xffff)]
URB setup
bmRequestType: 0x21
bRequest: 9
wValue: 0x0200
wIndex: 0 (0x0000)
wLength: 8
Data Fragment: 14111a1000194541
Packet parsed incorrectly:
0000 00 bc b0 35 00 00 00 00 53 02 00 1a 01 00 00 00
0010 b7 81 6e 57 00 00 00 00 bf 76 09 00 00 00 00 00
0020 08 00 00 00 08 00 00 00 21 09 00 02 00 00 08 00
0030 14 11 1a 10 00 19 45 41
Frame 1103: 56 bytes on wire (448 bits), 56 bytes captured (448 bits) on
interface 0
Interface id: 0 (usbmon1)
Encapsulation type: USB packets with Linux header (95)
Arrival Time: Jun 25, 2016 09:05:59.620223000 EDT
[Time shift for this packet: 0.000000000 seconds]
Epoch Time: 1466859959.620223000 seconds
[Time delta from previous captured frame: 0.000020000 seconds]
[Time delta from previous displayed frame: 0.000020000 seconds]
[Time since reference or first frame: 4328.638805000 seconds]
Frame Number: 1103
Frame Length: 56 bytes (448 bits)
Capture Length: 56 bytes (448 bits)
[Frame is marked: False]
[Frame is ignored: False]
[Protocols in frame: usb:usbhid]
USB URB
[Source: host]
[Destination: 1.26.0]
URB id: 0x0000000035b0bc00
URB type: URB_SUBMIT ('S')
URB transfer type: URB_CONTROL (0x02)
Endpoint: 0x00, Direction: OUT
Device: 26
URB bus id: 1
Device setup request: relevant (0)
Data: present (0)
URB sec: 1466859959
URB usec: 620223
URB status: Success (0)
URB length [bytes]: 8
Data length [bytes]: 8
[Response in: 1104]
[bInterfaceClass: HID (0x03)]
URB setup
bmRequestType: 0x21
0... .... = Direction: Host-to-device
.01. .... = Type: Class (0x01)
...0 0001 = Recipient: Interface (0x01)
bRequest: 0
wValue: 0x0009
wIndex: 2 (0x0002)
wLength: 2048
Data Fragment: 14111a1000194541
bRequest: SET_REPORT (0x09)
wValue: 0x0200
wIndex: 0
wLength: 8
You can see near the bottom, the incorrect parse reports both simultaneously:
bRequest: 0
and
bRequest: SET_REPORT (0x09)
The incorrectly parsed packet was sent via pyusb:
dev.ctrl_transfer(0x21, 9,
wValue=0x0200, wIndex=0x00,
data_or_wLength='\x14\x11\x1A\x10\x00\x19\x45\x41', timeout=1000)
It is clear that bRequest really should be 9, and wValue 0x0002 (accounting for
endianness)
William
You are receiving this mail because:
- You are watching all bug changes.