wirehark usb rastrea explicaciones

Estoy tratando de realizar ingeniería inversa en un dispositivo usb (HID) y realmente no puedo entender cómo lo que veo en wireshark (usbmon + wireshark en linux o windows) se relaciona con el protocolo usb. He mirado el protocolo usb de www.usb.org.

¿Qué muestra wireshark?

1) ¿Una línea por paquete? (token, datos, apretón de manos)

2) ¿Una línea por transacción? (ficha + [datos] + apretón de manos) (supongo)

3) ¿Una línea por transferencia de control?

La dirección de la transacción también es muy extraña (hacia / desde los campos). Al menos, no coincide con mis expectativas :-) ... Y la parte de datos de la enumeración, el informe oculto, etc. ... a veces parece mostrarse con los datos de configuración (8 bytes) y en ocasiones no ... No Realmente no sé qué es URB ... no hay mención de eso en el protocolo usb por lo que pude ver ... Me parece que cableshark / usbmon rastrean en un nivel de pila más alto e intenta deducir lo que sería en el cable de eso ...

Un ejemplo de lo que puedo ver se da a continuación, ¿qué vemos aquí?

a) Ni siquiera pude encontrar bmtype = 0x20 (de la configuración, frame No = 599) en las especificaciones.

b) Debido a que tengo un dispositivo HID, supuse que podría ser una configuración de informe / función (la enumeración se pasa en esta etapa). Entonces podría estar de acuerdo con la dirección (host-> dispositivo). ¿Pero dónde están los datos? ¿O no hay fase de datos aquí? ¿Qué es el cuadro 600 entonces?

c) ¿Qué es el marco 600? ¿los datos?

d) ¿Qué es el cuadro 601? un estado ACK? ... pero entonces los datos y ACK tienen la misma fuente?

No.     Time        Source                Destination           Protocol Length Info
    599 67.996889   host                  2.0                   USB      36     URB_CONTROL out

Frame 599: 36 bytes on wire (288 bits), 36 bytes captured (288 bits)
USB URB
    USBPcap pseudoheader length: 28
    IRP ID: 0xfffffa800a1e2610
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_CLASS_DEVICE (0x001a)
    IRP information: 0x00, Direction: FDO -> PDO
    URB bus id: 1
    Device address: 2
    Endpoint: 0x00, Direction: OUT
    URB transfer type: URB_CONTROL (0x02)
    Packet Data Length: 8
    Control transfer stage: Setup (0)
    [Response in: 601]
    [bInterfaceClass: Unknown (0xffff)]
URB setup
    bmRequestType: 0x20
        0... .... = Direction: Host-to-device
        .01. .... = Type: Class (0x01)
        ...0 0000 = Recipient: Device (0x00)
    bRequest: 0
    wValue: 0x0000
    wIndex: 0
    wLength: 16

0000  1c 00 10 26 1e 0a 80 fa ff ff 00 00 00 00 1a 00   ...&............
0010  00 01 00 02 00 00 02 08 00 00 00 00 20 00 00 00   ............ ...
0020  00 00 10 00                                       ....

No.     Time        Source                Destination           Protocol Length Info
    600 67.997889   2.0                   host                  USB      44     URB_CONTROL out

Frame 600: 44 bytes on wire (352 bits), 44 bytes captured (352 bits)
USB URB
    USBPcap pseudoheader length: 28
    IRP ID: 0xfffffa800a1e2610
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008)
    IRP information: 0x01, Direction: PDO -> FDO
    URB bus id: 1
    Device address: 2
    Endpoint: 0x00, Direction: OUT
    URB transfer type: URB_CONTROL (0x02)
    Packet Data Length: 16
    Control transfer stage: Data (1)
    [Request in: 599]
    [Time from request: 0.001000000 seconds]
    [bInterfaceClass: Unknown (0xffff)]
CONTROL response data

0000  1c 00 10 26 1e 0a 80 fa ff ff 00 00 00 00 08 00   ...&............
0010  01 01 00 02 00 00 02 10 00 00 00 01 05 04 0d 56   ...............V
0020  fb 82 c0 1d 10 18 cc 02 00 00 00 01               ............

No.     Time        Source                Destination           Protocol Length Info
    601 67.997889   2.0                   host                  USB      28     GET STATUS Status

Frame 601: 28 bytes on wire (224 bits), 28 bytes captured (224 bits)
USB URB
    USBPcap pseudoheader length: 28
    IRP ID: 0xfffffa800a1e2610
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_CONTROL_TRANSFER (0x0008)
    IRP information: 0x01, Direction: PDO -> FDO
    URB bus id: 1
    Device address: 2
    Endpoint: 0x00, Direction: OUT
    URB transfer type: URB_CONTROL (0x02)
    Packet Data Length: 0
    Control transfer stage: Status (2)
    [Request in: 599]
    [Time from request: 0.001000000 seconds]

0000  1c 00 10 26 1e 0a 80 fa ff ff 00 00 00 00 08 00   ...&............
0010  01 01 00 02 00 00 02 00 00 00 00 02               ............

Obviamente me estoy perdiendo algo. ¡Una explicación general sobre cómo la pantalla de Wirehark se relaciona con el protocolo y, (basado en él), el significado de la traza anterior es bienvenida!

Originalmente publiqué esto en Stack Overflow, pero me dijeron que no era directamente una pregunta de programación. Espero que encaje mejor aquí.

Un USB URB es como un paquete IP y un punto final USB es como un puerto IP. Los puntos finales USB 0x00-0x7F están en el host, y los puntos finales 0x80-0xFF están en el dispositivo (creo). Por lo tanto, el punto final codifica la dirección de la transferencia. lsusble mostrará qué puntos finales y qué tipos de transferencia admite un dispositivo.

Usaré "paquetes" entre comillas para referirme a la unidad de actividad que captura Wirehark. Estos no son literalmente lo que se envía por cable. Por ejemplo, los "paquetes" tendrán marcas de tiempo para cuando se iniciaron las transferencias, aunque esto no se transmita a través del bus USB.

Creo que el aspecto más confuso de oler el protocolo USB es que ves dos "paquetes" de Wireshark para cada USB URB. Cuando el host inicia una transferencia, es un URB_SUBMIT(filtro de pantalla Wireshark usb.urb_type == URB_SUBMIT). Cuando se completa la transferencia, es un URB_COMPLETE(filtro de pantalla Wireshark usb.urb_type == URB_COMPLETE)

Por lo que puedo decir, cuando hay una transferencia del host al dispositivo, el SUBMIT"paquete" contiene los datos USB reales transmitidos. Cuando hay una transferencia del dispositivo al host (iniciado por el host, como siempre), el COMPLETE"paquete" contiene los datos USB reales transmitidos.

Desde el punto de vista de analizar un protocolo, todos los demás "paquetes" son una distracción O un error URB. Para filtrar las distracciones, utilizo el siguiente filtro de pantalla !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Creo que el protocolo USB implica algunos apretones de manos y ACK y retransmisiones, pero todo esto lo maneja el controlador host y el sistema operativo no está involucrado. No creo, por ejemplo, que el sistema operativo haga un seguimiento de los reconocimientos o retransmisiones.

Por cierto, estoy usando el siguiente comando para analizar un protocolo. Además de realizar el filtrado anterior, solo muestra el número de punto final (en decimal) y los datos USB. Esto está en una máquina GNU / Linux que usa el dispositivo usbmon1 para olfatear, y suponiendo que el dispositivo USB que quiero monitorear está en el bus 1 y tiene la dirección 11.

tshark -i usbmon1 -Y "usb.device_address == 11 && !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)" -Tfields -e usb.endpoint_number -e usb.capdata

Los registros USB de WireShark se realizan a nivel del sistema operativo. Con Linux se basa en los datos que genera usbmon, que se basa en la estructura interna URB de Linux que se describe aquí . Entonces, mirar los comentarios y documentos de kernel y WireShark proporciona la mejor idea de lo que es.

Lo que he encontrado en los documentos del kernel es que los paquetes son estructuras usbmon seguidas de los datos enviados y recibidos. Esta es la estructura (copiada de aquí ):

struct usbmon_packet {
    u64 id;         /*  0: URB ID - from submission to callback */
    unsigned char type; /*  8: Same as text; extensible. */
    unsigned char xfer_type; /*    ISO (0), Intr, Control, Bulk (3) */
    unsigned char epnum;    /*     Endpoint number and transfer direction */
    unsigned char devnum;   /*     Device address */
    u16 busnum;     /* 12: Bus number */
    char flag_setup;    /* 14: Same as text */
    char flag_data;     /* 15: Same as text; Binary zero is OK. */
    s64 ts_sec;     /* 16: gettimeofday */
    s32 ts_usec;        /* 24: gettimeofday */
    int status;     /* 28: */
    unsigned int length;    /* 32: Length of data (submitted or actual) */
    unsigned int len_cap;   /* 36: Delivered length */
    union {         /* 40: */
        unsigned char setup[SETUP_LEN]; /* Only for Control S-type */
        struct iso_rec {        /* Only for ISO */
            int error_count;
            int numdesc;
        } iso;
    } s;
    int interval;       /* 48: Only for Interrupt and ISO */
    int start_frame;    /* 52: For ISO */
    unsigned int xfer_flags; /* 56: copy of URB's transfer_flags */
    unsigned int ndesc; /* 60: Actual number of ISO descriptors */
};