How a Software USB Protocol Analyzer Works
Part 2 - Monitor USB Traffic, analyze USB Device activity
USB Communication Layers Overview
Most software-based USB Protocol Analyzers work in about the same way. The analyzer runs on a host system as a kernel-mode driver and a user-mode protocol analyzer software. When you start the analyzer, the helper kernel-mode driver intercepts and captures all the traffic that routes through the system. The captured data is passed to the user-mode analyzer software, which decodes and displays the information to the user.
To understand how a software USB Protocol Analyzer works, one needs to learn the I/O model which operating system uses to manage USB communications.
The figure provides an overview of the layers taking part in the USB control and data communications.
At the highest layer, the user-mode Client Software handles requests to a USB device from end users and other applications by calling the appropriate kernel-mode clients and/or support routines that the underlying system software layer provides. -
At the middle layer, the kernel-mode System Software performs all device-specific operations required for handling devices connectivity, enumeration, configuration and managing the data transfer to and from peripheral devices.
USB system software layer is the layer at which a software USB protocol analyzer operates.
-
At the lowest layer, USB Host Controller and Root Hub provide a bus interface that allows USB devices to be attached to a host and an interface for transferring streams of data between the host and the USB devices.
Software USB protocol analyzers can't capture these data streams. To actually see the data transferring on the USB cable one needs a hardware USB protocol analyzer (USB bus analyzer). This type of protocol analyzers are hardware stand-alone unit connected between a host computer and a peripheral device under test. They usually require additional computer for controlling the data capture.
USB Physical Device on the end of a USB cable that performs some useful end user function.
Since a hardware USB bus analyzer is completely unaware about what is going on at the system software layer, a software USB protocol analyzer is indispensable tool for viewing USB activity from the host perspective.
Viewing Layered Driver Architecture
Lets take a more detailed look at a layer where software USB protocol analyzer may be successfully used for monitoring USB devices activity and applications working with them.
At a system software level Windows operating system supports a layered driver architecture in which drivers and their devices are represented as objects. Every hardware device is serviced by a chain of drivers, which create device objects chained in a device stack. The following figure shows the device objects that are created by a possible set of drivers for USB-related hardware.
| Example of USB System Device Object Layers |
Starting at the bottom of the figure, the device objects in the device stacks include:
-
A PDO and an FDO for the USB host controller.
The PCI driver enumerates the devices on its bus, finds a USB host controller and creates a PDO for that device. The USB host controller driver creates and attaches an FDO for the host controller.
-
A PDO and an FDO for the USB hub.
The USB host controller enumerates its bus, locates the root hub, and creates a PDO for it. The USB hub driver creates and attaches an FDO for the hub.
-
A PDO, an FDO, and filter DO for the USB device.
The USB hub driver enumerates its bus, locates a USB device, and creates a device stack for the device.
There are might be possible filter drivers for the host controller, hub and device which will create additional filter DOs.
The software USB protocol analyzer attaches to all these device objects and monitors the I/O requests they receive.
With USBlyzer you can view all USB devices plugged into your system in hierarchical tree view along with detailed information about each device object that is involved in handling I/O activity.
Monitoring USB Device Communication
The Windows operating system and drivers communicate with devices issuing I/O requests. All I/O requests are sent as data structures called I/O request packets (IRPs) that contain all the information required to process the request.
There are a number of different IRP types:
PnP IRPs are sent during device enumeration, resource rebalancing, and any other time Plug and Play activity occurs on the system. Power IRPs are used to notify the device of changes in the system power state. I/O control codes (IOCTLs) are used for communication between user-mode applications and drivers, or for communication internally among drivers in a device stack.
USB drivers communicate with their devices by submitting IOCTL requests that are delivered to the device by means of IRP of type IRP_MJ_INTERNAL_DEVICE_CONTROL. This device control code provides an I/O interface that USB drivers use to manage their devices. The most important of the IOCTLs is IOCTL_INTERNAL_USB_SUBMIT_URB. USB drivers use this IOCTL type to deliver a variable-length data structure called a USB Request Block (URB) to the devices their manage. By means of URBs drivers perform all device-specific operations, including data transfers.
As all these I/O requests travel down and up through each device stack, the software USB protocol analyzer captures each request and eventually decodes and analyzes its content according to its type.
| IRP Flow Through Driver Stack |
USBlyzer is a software-based USB protocol analyzer. With USBlyzer you can view the detailed information about all USB devices and drivers, capture, decode and display data going through USB device stacks, trace and analyze USB requests that the user-mode applications and USB device drivers use to communicate with the USB devices.
| 
October 07, 2008
