实例抓包分析USB鼠标枚举数据流.docVIP

USB命令（请求）和USB描述符(2)USB Monitor的高版本太复杂了，都不会用，这里还是使用2.5的老版本.新建session，选择新插入的HID鼠标开始抓包，拔掉鼠标，清空记录，再次插入鼠标，现在就抓到了USB鼠标枚举数据流要看懂这些数据流，需要/deep_pro/blog/item/3f97effa7048f814a9d31115.html/deep_pro/blog/item/0ca086af97ca15f1faed5016.html 里给出的14个表 要注意的是USB数据包通常是先发LSB，再发MSB，所以低字节在前，高字节在后。后面的讲解中2个字节长度以上的数据没有转换回高字节在前，低字节在后的顺序，保留了原始状态。 首先是两个PnP事件 000026: PnP Event: Query ID (UP), 18.10.2009 09:53:28.9218750 +4.2656250Hardware IDs: USB\Vid_15caPid_00c3Rev_0512, USB\Vid_15caPid_00c3 000027: PnP Event: Query ID (UP), 18.10.2009 09:53:28.9218750 +0.0Compatible IDs: USB\Class_03SubClass_01Prot_02, USB\Class_03SubClass_01, USB\Class_03 接着主机发出了第一个包000028 000028: Get Descriptor Request (DOWN), 18.10.2009 09:53:28.9375000 +0.0156250Descriptor Type: DeviceDescriptor Index: 0x0Transfer Buffer Size: 0x12 bytes 在这里没有给出主机包里的具体内容，跟Bus Hound是不一样的。只能看出请求的是设备描述符，要求返回的长度是18个字节，偏移为0 对应的，USB鼠标回答了这个请求 000029: Control Transfer (UP), 18.10.2009 09:53:28.9375000 +0.0Pipe Handle: 012 01 00 02 00 00 00 08 CA 15 C3 00 12 05 00 0200 01 ê.?.. Setup Packet80 06 00 01 00 00 12 00 € Recipient: DeviceRequest Type: StandardDirection: Device-HostRequest: 0x6 (GET_CONFIGURATION)Value: 0x100Index: 0x0Length: 0x12 这里可以看到主机刚才发给来的数据包80 06 00 01 00 00 12 00，结构上面提到的参考表一第一个字节80是位图，没什么大的作用，限制第二个字节的。第二个字节06参照表二表三得知是GET_DESCRIPTOR命令wValue：00 01 参照表5得知是设备描述符 wIndex：00 00 偏移为0wLength：12 00 要求设备端返回18个字节 再看看设备端的回答12 01 00 02 00 00 00 08 CA 15 C3 00 12 05 00 02 00 01，正好18字节设备描述符的结构参照表四，bLength：12 ，此设备描述符的长度是18字节bDecriptorType：01 ,参照表5得知是设备描述符 bcdUSB:00 02 ,代表USB协议的版本号，此处2.0版 bDeviceClass:00bDeviceSubClass:00,表述设备类码由接口文件给出，可能是为了每个接口独立实现不同的功能。bDevicePortocol：00，跟前两个字节紧密联系，这里指还是等待在接口文件里再说明使用的设备协议bMaxPacketSize0：08，指端点0最大可接受的包大小，真是够抠门的，刚刚够用。 idVendor：CA 15 ，VID其实是0x15ca，字节序问题不在赘述idProduct：C3 00 ，PID 0x00c3，在/usb.ids查询得知 ?????????????????? 15ca Textech International Ltd. 00c3 Mini Optical Mouse，实物确实是一个mini鼠标bcdDevice:12 05，这个似乎没什么通用的意义iManufacturer：00，iProduct：02，iSerialNumber：00,bNumCo