Bus snooping/sniffing: Difference between revisions
No edit summary |
|||
(12 intermediate revisions by 5 users not shown) | |||
Line 4: | Line 4: | ||
===Snooping Utilities:=== |
===Snooping Utilities:=== |
||
* BTSpy [http://btwincap.sourceforge.net/custom.html] - Windows based snoop for BT8x8 based devices |
* BTSpy [http://btwincap.sourceforge.net/custom.html] - Windows based snoop for BT8x8 based devices |
||
* Dscaler's RegSpy [http://www.dscaler. |
* Dscaler's RegSpy [http://www.dscaler.net/] - Windows based; contains the ability to snoop the registers of [[Interface chipsets|PCI / PCIe interface chipsets]] ... also see [http://marc.info/?l=linux-dvb&m=122823618002379&w=2 this note] |
||
==USB == |
==USB == |
||
Line 10: | Line 10: | ||
* [[usbsnoop]] - a Windows based utility for sniffing/monitoring communications traffic for a USB device. Note: In case usbsnoop/SniffUSB doesn't work for you, here are a few time limited apps that should work under Vista: |
* [[usbsnoop]] - a Windows based utility for sniffing/monitoring communications traffic for a USB device. Note: In case usbsnoop/SniffUSB doesn't work for you, here are a few time limited apps that should work under Vista: |
||
** [http://www.hhdsoftware.com/Family/usb-monitor.html USB Monitor] - 14-day trial period |
** [http://www.hhdsoftware.com/Family/usb-monitor.html USB Monitor] - 14-day trial period |
||
** [http://www.usblyzer.com/ USBlyzer] - fully functional evaluation version for 33 days |
** [http://www.usblyzer.com/ USBlyzer] - fully functional evaluation version for 33 days (only 32 bit) |
||
* SnoopyPro - Windows based snoop for USB device communications traffic |
* SnoopyPro - Windows based snoop for USB device communications traffic |
||
* usbsnoop/SniffUSB - Windows based snoop for USB device communications traffic |
* usbsnoop/SniffUSB - Windows based snoop for USB device communications traffic |
||
* [http://desowin.org/usbpcap/ USBPcap] - open source USB sniffer for Windows XP, Vista, 7 and 8. |
|||
* usbmon - Linux kernel module which can snoop USB device communications traffic |
* usbmon - Linux kernel module which can snoop USB device communications traffic |
||
** [http://git.linuxtv.org/v4l-utils.git?a=blob;f=contrib/parse_tcpdump_log.pl;hb=HEAD parse_tcpdump_log.pl] - a script to directly talk with usbmon, parsing the result into a format feasible for analysis. This is part of the contrib stuff at the [http://git.linuxtv.org/v4l-utils.git v4l-utils tree]. It allows both realtime and offline parsing of usbmon data, and its format output is compatible with other parsers like the [http://git.linuxtv.org/v4l-utils.git?a=blob_plain;f=contrib/em28xx/parse_em28xx.pl;h=master;hb=HEAD em28xx log parser]. |
|||
** Wireshark - logs usbmon output, via libpcap |
** Wireshark - logs usbmon output, via libpcap |
||
** USBMon - logs usbmon output |
** USBMon - logs usbmon output |
||
===Log parsers, format etc=== |
===Log parsers, format etc=== |
||
* [[http://mcentral.de/hg/~mrec/usbreplay/archive/tip.tar.gz parser.pl]] |
|||
* [[usbmon2usbsnoop]] |
* [[usbmon2usbsnoop]] |
||
* |
* [http://git.linuxtv.org/v4l-utils.git?a=blob_plain;f=contrib/parse-usbsnoop.php;h=master;hb=HEAD parse-usbsnoop.php] |
||
* [http://git.linuxtv.org/v4l-utils.git?a=blob_plain;f=contrib/parse-sniffusb2.pl;h=master;hb=HEAD parse-sniffusb2.pl] |
|||
... |
|||
* [http://git.linuxtv.org/v4l-utils.git?a=blob_plain;f=contrib/em28xx/parse_em28xx.pl;h=master;hb=HEAD em28xx log parser] |
|||
===Snooping Procedures:=== |
===Snooping Procedures:=== |
||
* Use a Snopping utility to get the log. |
* Use a Snopping utility to get the log. |
||
* Group URB transactions into a shorter log by using a parser |
* Group URB transactions into a shorter log by using a parser, like [http://git.linuxtv.org/v4l-utils.git?a=blob_plain;f=contrib/parse-usbsnoop.php;h=master;hb=HEAD parse-usbsnoop.php] |
||
* Identify the URB transactions at the control endpoint. URB transactions look like those: |
* Identify the URB transactions at the control endpoint. URB transactions look like those: |
||
Line 53: | Line 56: | ||
|+'''control URB examples ''' |
|+'''control URB examples ''' |
||
|- |
|- |
||
| URB sequence log ( |
| URB sequence log (URB setup + URB IN or OUT) || Byte 1 || Byte 2 || Bytes 3-4 || Bytes 5-6 || Bytes 7-8 || Message |
||
|- |
|- |
||
| 40 00 00 00 08 00 01 00 >>> 3d || USB OUT, Vendor Class || Req = 0x00 || Value = 0x0000 || Index = 0x0008 || Size = 0x0001 || |
| 40 00 00 00 08 00 01 00 >>> 3d || USB OUT, Vendor Class || Req = 0x00 || Value = 0x0000 || Index = 0x0008 || Size = 0x0001 || { 0x3d } |
||
|- |
|- |
||
| 40 02 00 00 ba 00 03 00 >>> 20 11 00 || USB OUT, Vendor Class || Req = 0x02 || Value = 0x0000 || Index = 0x00ba || Size = 0x0003 || |
| 40 02 00 00 ba 00 03 00 >>> 20 11 00 || USB OUT, Vendor Class || Req = 0x02 || Value = 0x0000 || Index = 0x00ba || Size = 0x0003 ||{ 0x20, 0x11, 0x00 } |
||
|- |
|- |
||
| c0 00 00 00 15 00 01 00 <<< 00 || USB IN, Vendor Class || Req = 0x00 || Value = 0x0000 || Index = 0x0015 || Size = 0x0001 || |
| c0 00 00 00 15 00 01 00 <<< 00 || USB IN, Vendor Class || Req = 0x00 || Value = 0x0000 || Index = 0x0015 || Size = 0x0001 || { 0x00 } |
||
|} |
|} |
||
Line 65: | Line 68: | ||
After getting the log, you should analyse and understand the meaning of each of URB fields on your device. |
After getting the log, you should analyse and understand the meaning of each of URB fields on your device. |
||
For example, in the case of [[ |
For example, in the case of [[Em28xx_devices | em28xx]], Req is used to indicate internal registers or I2C, Value is always 0 and Index indicates what device register is being used. |
||
On em28xx, the |
On em28xx, the [http://git.linuxtv.org/v4l-utils.git?a=blob_plain;f=contrib/em28xx/parse_em28xx.pl;h=master;hb=HEAD em28xx log parser] could be used in order to proccess the URBs and the driver dmesg dumps (in the compact format as shown above) and print them into a more human way, generating C like statements that can be added at em28xx source code (with a few adaptations, in the case of i2c messages): |
||
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x3d); |
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x3d); |
||
i2c_master_send(0xba>>1, { 20 11 00 }, 0x03); |
i2c_master_send(0xba>>1, { 20 11 00 }, 0x03); |
||
em28xx_read_reg(dev, EM28XX_R15_RGAIN); /* read 0x00 */ |
em28xx_read_reg(dev, EM28XX_R15_RGAIN); /* read 0x00 */ |
||
If all you want is to check what the em28xx Linux driver is doing, and provided that the usbmon module is loaded (the Kernel should be compiled with CONFIG_USB_MON option), you can just use: |
|||
./parse_tcpdump_log.pl --pcap |./parse_em28xx.pl |
|||
There are some other parsers for some specific devices at the [http://git.linuxtv.org/v4l-utils.git?a=tree;f=contrib;hb=HEAD contrib directory of the v4l-tools git tree]. |
|||
===Command Playback Utilities:=== |
===Command Playback Utilities:=== |
||
Line 81: | Line 90: | ||
* http://en.wikipedia.org/wiki/I2C#Development_Tools |
* http://en.wikipedia.org/wiki/I2C#Development_Tools |
||
* also see [http://www.spinics.net/lists/linux-dvb/msg16845.html this thread] |
* also see [http://www.spinics.net/lists/linux-dvb/msg16845.html this thread] |
||
===Snooping Procedure:=== |
|||
The data transferred by the system over the i2c bus (and smbus) can be snooped using the kernel's FTRACE facility. To use this, the following kernel options need to be enabled: |
|||
* CONFIG_FTRACE |
|||
* CONFIG_ENABLE_DEFAULT_TRACERS |
|||
i2c tracing can then be enabled by: |
|||
echo 1 >/sys/kernel/debug/tracing/events/i2c/enable |
|||
Note that this will, by default, trace the traffic through all i2c adapters on the system. You can be selective about what you trace by something like: |
|||
echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter |
|||
The trace output can be found in prettified text form by: |
|||
cat /sys/kernel/debug/tracing/trace |
|||
This will look something like: |
|||
... i2c_write: i2c-5 #0 a=044 f=0000 l=2 [02-14] |
|||
... i2c_read: i2c-5 #1 a=044 f=0001 l=4 |
|||
... i2c_reply: i2c-5 #1 a=044 f=0001 l=4 [33-00-00-00] |
|||
... i2c_result: i2c-5 n=2 ret=2 |
|||
Where the components are: |
|||
* i2c-<adapter-nr> |
|||
* #<message-array-index> |
|||
* a=<addr> |
|||
* f=<flags> |
|||
* l=<datalen> |
|||
* n=<message-array-size> |
|||
* ret=<result> |
|||
* [<data-transferred>] |
|||
==External Links== |
==External Links== |
||
* [[Wikipedia:Bus sniffing|Wikipedia's Bus sniffing article]]; note that the [[Wikipedia:Cache coherency|Cache coherency]] article is a probably a little less vague or more enlightening |
* [[Wikipedia:Bus sniffing|Wikipedia's Bus sniffing article]]; note that the [[Wikipedia:Cache coherency|Cache coherency]] article is a probably a little less vague or more enlightening |
||
[[Category:Development]] |
Latest revision as of 08:38, 7 October 2014
Purpose and relevance to development work -- description coming soon
PCI / PCIe
Snooping Utilities:
- BTSpy [1] - Windows based snoop for BT8x8 based devices
- Dscaler's RegSpy [2] - Windows based; contains the ability to snoop the registers of PCI / PCIe interface chipsets ... also see this note
USB
Snooping Utilities:
- usbsnoop - a Windows based utility for sniffing/monitoring communications traffic for a USB device. Note: In case usbsnoop/SniffUSB doesn't work for you, here are a few time limited apps that should work under Vista:
- USB Monitor - 14-day trial period
- USBlyzer - fully functional evaluation version for 33 days (only 32 bit)
- SnoopyPro - Windows based snoop for USB device communications traffic
- usbsnoop/SniffUSB - Windows based snoop for USB device communications traffic
- USBPcap - open source USB sniffer for Windows XP, Vista, 7 and 8.
- usbmon - Linux kernel module which can snoop USB device communications traffic
- parse_tcpdump_log.pl - a script to directly talk with usbmon, parsing the result into a format feasible for analysis. This is part of the contrib stuff at the v4l-utils tree. It allows both realtime and offline parsing of usbmon data, and its format output is compatible with other parsers like the em28xx log parser.
- Wireshark - logs usbmon output, via libpcap
- USBMon - logs usbmon output
Log parsers, format etc
Snooping Procedures:
- Use a Snopping utility to get the log.
- Group URB transactions into a shorter log by using a parser, like parse-usbsnoop.php
- Identify the URB transactions at the control endpoint. URB transactions look like those:
40 02 00 00 ba 00 03 00 >>> 20 11 00
Byte | Meaning |
1 | bit 7 = 1 - IN / 0 - OUT
bit 6 = 1 - Vendor Class |
2 | URB Request |
3-4 | URB Value in big endian |
5-6 | URB Index in big endian |
7-8 | URB message size in big endian |
For example, let's analyse the folowing URB's:
URB sequence log (URB setup + URB IN or OUT) | Byte 1 | Byte 2 | Bytes 3-4 | Bytes 5-6 | Bytes 7-8 | Message |
40 00 00 00 08 00 01 00 >>> 3d | USB OUT, Vendor Class | Req = 0x00 | Value = 0x0000 | Index = 0x0008 | Size = 0x0001 | { 0x3d } |
40 02 00 00 ba 00 03 00 >>> 20 11 00 | USB OUT, Vendor Class | Req = 0x02 | Value = 0x0000 | Index = 0x00ba | Size = 0x0003 | { 0x20, 0x11, 0x00 } |
c0 00 00 00 15 00 01 00 <<< 00 | USB IN, Vendor Class | Req = 0x00 | Value = 0x0000 | Index = 0x0015 | Size = 0x0001 | { 0x00 } |
After getting the log, you should analyse and understand the meaning of each of URB fields on your device.
For example, in the case of em28xx, Req is used to indicate internal registers or I2C, Value is always 0 and Index indicates what device register is being used.
On em28xx, the em28xx log parser could be used in order to proccess the URBs and the driver dmesg dumps (in the compact format as shown above) and print them into a more human way, generating C like statements that can be added at em28xx source code (with a few adaptations, in the case of i2c messages):
em28xx_write_reg(dev, EM28XX_R08_GPIO, 0x3d); i2c_master_send(0xba>>1, { 20 11 00 }, 0x03); em28xx_read_reg(dev, EM28XX_R15_RGAIN); /* read 0x00 */
If all you want is to check what the em28xx Linux driver is doing, and provided that the usbmon module is loaded (the Kernel should be compiled with CONFIG_USB_MON option), you can just use:
./parse_tcpdump_log.pl --pcap |./parse_em28xx.pl
There are some other parsers for some specific devices at the contrib directory of the v4l-tools git tree.
Command Playback Utilities:
- usb-robot - plays back USB Snoopy capture logs
- usbreplay - plays back usbsnoop capture logs
i2c
- i2c Tools: see here and here
- http://en.wikipedia.org/wiki/I2C#Development_Tools
- also see this thread
Snooping Procedure:
The data transferred by the system over the i2c bus (and smbus) can be snooped using the kernel's FTRACE facility. To use this, the following kernel options need to be enabled:
- CONFIG_FTRACE
- CONFIG_ENABLE_DEFAULT_TRACERS
i2c tracing can then be enabled by:
echo 1 >/sys/kernel/debug/tracing/events/i2c/enable
Note that this will, by default, trace the traffic through all i2c adapters on the system. You can be selective about what you trace by something like:
echo adapter_nr==1 >/sys/kernel/debug/tracing/events/i2c/filter
The trace output can be found in prettified text form by:
cat /sys/kernel/debug/tracing/trace
This will look something like:
... i2c_write: i2c-5 #0 a=044 f=0000 l=2 [02-14] ... i2c_read: i2c-5 #1 a=044 f=0001 l=4 ... i2c_reply: i2c-5 #1 a=044 f=0001 l=4 [33-00-00-00] ... i2c_result: i2c-5 n=2 ret=2
Where the components are:
- i2c-<adapter-nr>
- #<message-array-index>
- a=<addr>
- f=<flags>
- l=<datalen>
- n=<message-array-size>
- ret=<result>
- [<data-transferred>]
External Links
- Wikipedia's Bus sniffing article; note that the Cache coherency article is a probably a little less vague or more enlightening