【转载】linux下的usb抓包方法

1 linux下的usb抓包方法

一、配置内核使能usb monitor：

make menuconfig
                   Device Drivers -->
                            USB Support -->
                                     USB Monitor --> Select * not M
二、build kernel
    sudo insmod /lib/modules/3.2.1/kernel/drivers/usb/mon/usbmon.ko

三、启动内核后执行
                   #mount -t debugfs none_debugs /sys/kernel/debug
                   
                   检查是否存在目录 /sys/kernel/debug/usb/usbmon
                   #ls /sys/kernel/debug/usb/usbmon

                   0s  0u  1s  1t  1u  2s  2t  2u  3s  3t  3u
                 
                  # cat /sys/kernel/debug/usb/devices 肯定你要监视的usb设备所在总线号和设备号
                   #       选择包含有 : Vendor=148f ProdID=5370 Rev= 1.01 的段落
                   #       as follows:
                   #                T:  Bus=01Lev=01 Prnt=01 Port=00 Cnt=01 Dev#=  2 Spd=480  MxCh= 0
                   #                D:  Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs=  1
                   #                P:  Vendor=148f ProdID=5370 Rev= 1.01
                   #                S:  Manufacturer=Ralink
                   #                S:  Product=802.11 n WLAN
                   #                S:  SerialNumber=1.0
                   #                C:* #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=450mA
                   #                I:* If#= 0 Alt= 0 #EPs= 5 Cls=ff(vend.) Sub=ff Prot=ff Driver=rtusbSTA
                   #                E:  Ad=81(I) Atr=02(Bulk) MxPS= 512 Ivl=0ms
                   #                E:  Ad=01(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
                   #                E:  Ad=02(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
                   #                E:  Ad=03(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
                  #                E:  Ad=04(O) Atr=02(Bulk) MxPS= 512 Ivl=0ms
                   #       能够从第一行看到 Bus= 01,设备号是2
                   

四、保存 usb raw packet ，若是总线号是1，则是1u，若是总线号是2，则是2u，依次类推。特殊状况是0u表示监听全部总线
                   if (Bus == 01)
                            sudo cat /sys/kernel/debug/usb/usbmon/1u > ./rt5370-UsbMon.txt
                   else if (Bus == 02)
                            sudo cat /sys/kernel/debug/usb/usbmon/2u > ./rt5370-UsbMon.txt

2 抓的usb包的格式解析

The usbmon reports requests made by peripheral-specific drivers to Host
Controller Drivers (HCD). So, if HCD is buggy, the traces reported by
usbmon may not correspond to bus transactions precisely. This is the same
situation as with tcpdump.

上面的基本说明了usbmon主要的工做原理，他会把usb host drivers发送到hcd的全部请求（usb_submit_urb）和请求的回调内容（即改请求对应的回调函数：urb->complete）都报告出来。

Any text format data consists of a stream of events, such as URB submission（S）,
URB callback（C）,  submission error（E）. Every event is a text line, which consists
of whitespace separated words. The number or position of words may depend
on the event type, but there is a set of words, common for all types.

因此这里的URB submission便是对应usb host drivers中的usb_submit_urb(urb, mem_flags)

而URB callback即便对应urb的回掉函数：urb->complete

因此咱们会看到even type为S的和紧邻的event type为C的事件，他们对应的URB tag都是同样的

由于他们都是针对同一个URB而言的。

先给出三个列子：

eea76f80 3474782286 S Ii:1:003:3 -115:128 16 <
edda2b80 3474786256 C Ii:1:006:1 0:1 16 = 2fff0180 d6ef206e 1401020c 015aab73
e11c9280 3500399358 S Co:1:006:0 s 20 00 0000 0000 0007 7 = 370c0447 00401f
e11c9280 3500399866 C Co:1:006:0 0 7 >

Here is the list of words, from left to right:


-  URB Tag. This is used to identify URBs, and is normally an in-kernel address
  of the URB structure in hexadecimal, but can be a sequence number or any
  other unique string, within reason.

通常就是在usb host driver中分配的urb的内核地址，通常经过以下函数来分配：

urb = usb_alloc_urb(0, mem_flags);

因为一个urb对应一个端口，因此同一个端口他们的urb tag都是同样的。
002e2002999116296 C Ci:1:008:0 0 4 = 8d2b0000

 Timestampin microseconds, a decimal number. The timestamp's resolution
  depends on available clock, and so it can be much worse than a microsecond
  (if the implementation uses jiffies, for example).
e002e200 2999116296Ci:1:008:0 0 4 = 8d2b0000

注意单位是微秒。

- Event Type. This type refers to the format of the event, not URB type.
  Available types are:S - submission, C - callback, E - submission error.
e002e200 2999116296 C Ci:1:008:0 0 4 = 8d2b0000

表示的意思是：usb host drivers经过usb_submit_urb函数向linuxusb core提交了一个urb传输请求，咱们知道全部的usb传输，都是host端主动发起的，因此必需要有host drivers主动发出submit urb的动做

- "Address" word (formerly a "pipe"). It consists of four fields, separated by
  colons: URB type and direction, Bus number, Device address, Endpoint number.
  Type and direction are encoded with two bytes in the following manner:
    Ci Co   Control input and output
    Zi Zo   Isochronous input and output
    Ii Io   Interrupt input and output
    Bi Bo   Bulk input and output
  Bus number, Device address, and Endpoint are decimal numbers, but they may
  have leading zeros, for the sake of human readers.

因此地址字段的格式是以下：

URB type and direction：Bus number：Device address：Endpoint number

以下列子：
e002e200 2999116296 C Ci:1:008:0 0 4 = 8d2b0000

意思是：控制传输输入，总线号为1，设备地址为008，因为全部的控制传输都是在endpoint 0上的，因此最后的端口天然也是0了。

这里须要注意，因为咱们的这个抓包命令，只能指定是抓哪一个总线上，但同一个总线一般会有不少usb设备的，若是咱们只是关注特定的某个usb设备的话，我本身就须要留意设备地址字段，经过这个字段，咱们就能够区分这个传输是否是咱们要监听的设备发送出来的。

例以下面一段usb sniffer log：

edda2b80 3500379613 C Ii:1:006:1 0:1 8 = 0e06010d 08004700
edda2b80 3500394156 S Ii:1:006:1-115:1 16 <
eea76f80 3500394226 C Ii:1:003:3 0:128 16 = a12a0000 01000800 00e1f505 00e1f505
eea76f80 3500394236 S Ii:1:003:3 -115:128 16 <

一样都是usb总线1下面的，因为一个usb总线就对应一个usb host controller，但一个设备地址是006，另外一个则是003，前者对应的是usb bluetooth dongle的中断传输，然后者则是usb鼠标的中断传输，他们接在同一个总线的usb hub下面。咱们真正须要监听只是usb bluetooth dongle，因此就能够不受usb鼠标的干扰。

- URB Status word. This is either a letter, or several numbers separated
  by colons: URB status, interval, start frame, and error count. Unlike the
  "address" word, all fields save the status are optional. Interval is printed
  only for interrupt and isochronous URBs. Start frame is printed only for
  isochronous URBs. Error count is printed only for isochronous callback
  events.
这里的意思就是，urb的状态字，有两种可能，一种是“字母”；一种是“数字”，若是是前者则通常就是字母“s”，表示一个控制传输，而若是是数字，他们的格式则分两种状况：

若是是中断传输，格式以下：   URB status：interval，注意状态字段只对C类型的事件有意义，对S类型的事件没有意思。

若是是同步传输,格式以下：URB status：interval：{start frame}：{error count}

The status field is a decimal number, sometimes negative, which represents
  a "status" field of the URB. This field makes no sense for submissions, but
  is present anyway to help scripts with parsing. When an error occurs, the
  field contains the error code.
e002e200 2999116296 C Ci:1:008:0 0 4 = 8d2b0000

状态域：status就是struct urb结构体中的status字段，该字段直接说明当前的usb请求是否成功执行。因此只有在回调的时候才有意思。

In case of a submission of a Control packet, this field contains a Setup Tag
  instead of an group of numbers. It is easy to tell whether the Setup Tag is
  present because it is never a number. Thus if scripts find a set of numbers
  in this word, they proceed to read Data Length (except for isochronous URBs).
  If they find something else, like a letter, they read the setup packet before
  reading the Data Length or isochronous descriptors.
e002e200 2999116113 S Ci:1:008:0 s c0 07 0000 1134 0004 4 <

字母“s”是控制传输的标志

- Setup packet, if present, consists of 5 words: one of each for bmRequestType,
  bRequest, wValue, wIndex, wLength, as specified by the USB Specification 2.0.
  These words are safe to decode if Setup Tag was 's'. Otherwise, the setup
  packet was present, but not captured, and the fields contain filler.

即控制传输包的格式以下：

bmRequestType（请求类型）：bRequest（请求号）：wValue：wIndex（下标）：wLength（数据字段的长度，若是为0，说明没有数据段）

e11c9280 3500399358 S Co:1:006:0 s 20 00 0000 0000 0007 7 = 370c0447 00401f

e11c9280 3500399866 C Co:1:006:0 0 7 > //表示上面的控制传输请求成功，而且实际传输了7个btye的数据，仅表示状态，不对应具体的控制传输阶段

20 00 0000 0000 0007对应控制传输的setup阶段， 370c0447 00401f对应控制传输的数据阶段（OUT传输），数据长度是7个字节

- Number of isochronous frame descriptors and descriptors themselves.
  If an Isochronous transfer event has a set of descriptors, a total number
  of them in an URB is printed first, then a word per descriptor, up to a
  total of 5. The word consists of 3 colon-separated decimal numbers for
  status, offset, and length respectively. For submissions, initial length
  is reported. For callbacks, actual length is reported.


-  Data Length. For submissions, this is the requested length. For callbacks,
  this is the actual length.
e002e200 2999116296 C Ci:1:008:0 0 4 = 8d2b0000

又以下：

edda2b80 3500272851 S Ii:1:006:1 -115:1 16 <
edda2b80 3500273622 C Ii:1:006:1 0:1  7 = 13050147 000100

第一句是发起一个请求长度为16字节的usb中断传输请求，该字段通常在端点描述符中会说明该管道所支持的最大数据包大小

第二句是该中断传输请求实际返回的数据则只有7个字节，即对应urb->actual_length字段

以上两句对应一个 中断IN传输

-  Data tag. The usbmon may not always capture data, even if length is nonzero.
  The data words are present only if this tag is '='.
e002e200 2999116296 C Ci:1:008:0 0 4 =8d2b0000

data tag就是“=”，表示有数据段，“=”号后面就是具体的数据内容

-  Data words follow, in big endian hexadecimal format. Notice that they are
  not machine words, but really just a byte stream split into words to make
  it easier to read. Thus, the last word may contain from one to four bytes.
  The length of collected data is limited and can be less than the data length
  reported in the Data Length word. In the case of an Isochronous input (Zi)
  completion where the received data is sparse in the buffer, the length of
  the collected data can be greater than the Data Length value (because Data
  Length counts only the bytes that were received whereas the Data words
  contain the entire transfer buffer).
e002e200 2999116296 C Ci:1:008:0 0 4 =  8d2b0000

Examples:
An input control transfer to get a port status.
d5ea89a0 3575914555 S Ci:1:001:0 s  a3 00 0000 0003 00044<

“ a3 00 0000 0003 0004”对应控制传输的setup阶段，“4”对应控制传输的数据阶段长度
5ea89a0 3575914560 C Ci:1:001:0 0 4 =  01050000
对应控制传输的数据阶段的data IN传输，” 01050000“即为数据 ，为4byte长度

An output bulk transfer to send a SCSI command 0x28 (READ_10) in a 31-byte
Bulk wrapper to a storage device at address 5:

dd65f0e8 4128379752 S Bo:1:005:2 -115 31 = 55534243 ad000000 00800000 80010a28 20000000 20000040 00000000 000000
dd65f0e8 4128379808 C Bo:1:005:2 0 31 > //指示这个bulk传输请求时成功的，而且实际也传输了31个byte的数据。

3 USB Sniffing with tcpdump

usbmon is a facility in kernel which is used to collect traces of I/O on the USB bus. usbmon collects raw text/binary which are not easily human-readable. Here, the idea is to use Wireshark as frontend to produces a human-readable representation of these data. However Wireshark does not support usbmon raw data as is, so we have to parse these data in the pcap format. tcpdump is a good candidate to capture USB data from usbmon and generate pcap traces

前提条件，是须要最新的tcpdump工具才行，有编译好的，能够直接download下来push到板子上就可使用。也有能够本身手动来编译的。这里就不详细来讲了。

步骤：

• mount -t debugfs none_debugs /sys/kernel/debug
•  cat /sys/kernel/debug/usb/devices 肯定usb的总线号
• tcpdump -D

1.eth0
2.usbmon1 (USB bus number 1)
3.usbmon2 (USB bus number 2)
4.usbmon3 (USB bus number 3)
5.any (Pseudo-device that captures on all interfaces)
6.lo

有以上红色部分输出，说明你的tcpdump已经安装下，能够正常使用

• tcpdump -i usbmon1 -w /data/usblog.pcap &
• killall tcpdump
• wireshark usblog.pcap //最好使用wireshark工具查看就能够了

上个图参考下，打开后是什么样子：

参考文档：

W:\wm8880\android\ANDROID_3.4.5\trunk\Documentation\usb\usbmon.txt

http://omappedia.org/wiki/USB_Sniffing_with_tcpdump