linux usb 驅動開發 抓包工具

smilestone322發表於2017-09-30
Linux

轉自：

http://blog.csdn.net/xiaojsj111/article/details/14127607

linux下的usb抓包方法

1 linux下的usb抓包方法

1、配置核心使能usb monitor：

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


3、啟動核心後執行
                   #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=01Dev#=  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
                   

4、儲存 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 asURB 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 s20 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 04 = 8d2b0000
又如下：
edda2b80 3500272851 S Ii:1:006:1 -115:116 <
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://blog.csdn.net/faithzzf/article/details/60958858

ubuntu下usb抓包方法步驟--usbmon



相關文章