15 votes

user415772 avatar

explications sur les traces usb de wireshark

Demandé el 5 de Février, 2015
Quand la question a-t-elle été
21742 affichage
Nombre de visites la question a
2 Réponses
Nombre de réponses aux questions
Résolu
Situation réelle de la question

J'essaie de faire de l'ingénierie inverse sur un dispositif usb (HID) et je n'arrive pas vraiment à comprendre comment ce que je vois sur wireshark (usbmon + wireshark sur linux, ou Windows) se rapporte au protocole usb . J'ai examiné le protocole usb sur www.usb.org.

Que montre Wireshark ?

1)Une ligne par paquet ? (jeton, données, poignée de main)

2)Une ligne par transaction ? (jeton + [données] + poignée de main) (à mon avis)

3)Une ligne par transfert de contrôle ?

Le sens de la transaction est également très étrange (vers/depuis les champs). En tout cas, cela ne correspond pas à mes attentes :-) ... Et la partie données de l'énumération, du rapport caché, etc... semble parfois s'afficher avec les données de configuration (8 octets) et parfois non... Je ne sais pas vraiment ce qu'est URB... il n'y a aucune mention de cela dans le protocole usb pour autant que je puisse voir... Il me semble que wireshark/usbmon trace à un niveau supérieur de la pile et essaie de déduire ce qui serait sur le fil à partir de cela...

Un exemple de ce que je peux voir est donné ci-dessous, qu'est-ce qu'on peut voir ici ?

a)Je n'ai même pas pu trouver bmtype=0x20 (de la configuration, frame No=599)dans les specs.

b)Comme j'ai un périphérique HID, j'ai supposé qu'il pouvait s'agir d'une configuration de rapport/fonction (l'énumération est passée à ce stade). Je suis donc d'accord avec la direction (hôte->appareil). Mais où sont les données ? Ou bien il n'y a pas de phase de données ici ? Qu'est-ce que la trame 600 alors ?

c)qu'est-ce que le cadre 600 ? les données ?

d)qu'est-ce que la trame 601 ? un ACK d'état ?... mais alors les données et l'ACK ont la même source ?

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               ............

Il est évident que quelque chose m'échappe. Une explication générale sur la façon dont l'affichage de Wireshark est lié au protocole et, (sur cette base), la signification de la trace ci-dessus est la bienvenue !

J'ai initialement posté cette question sur Stack Overflow, mais on m'a dit que ce n'était pas directement une question de programmation. J'espère qu'elle trouvera mieux sa place ici.

Demandé el 5 de Février, 2015 par user415772

Réponses

Trop de publicités?

18voto

manuel avatar
manuel Points 11

Un URB USB est comme un paquet IP et un point d'extrémité USB est comme un port IP. Les endpoints USB 0x00-0x7F sont sur l'hôte, et les endpoints 0x80-0xFF sont sur le dispositif (je pense). Par conséquent, le point de terminaison encode la direction du transfert. lsusb vous montrera quels sont les points de terminaison et les types de transfert pris en charge par un périphérique.

J'utiliserai le terme "paquets" entre guillemets pour désigner l'unité d'activité capturée par Wireshark. Ce n'est pas littéralement ce qui est envoyé sur le fil. Par exemple, les "paquets" auront des horodatages pour le moment où les transferts ont été initiés, même si cela n'est pas transmis sur le bus USB.

Je pense que l'aspect le plus déroutant du reniflage du protocole USB est que vous voyez deux "paquets" Wireshark pour chaque URB USB. Lorsque l'hôte initie un transfert, il s'agit d'un URB_SUBMIT (Filtre d'affichage Wireshark usb.urb_type == URB_SUBMIT ) . Lorsque le transfert est terminé, c'est un URB_COMPLETE (Filtre d'affichage Wireshark usb.urb_type == URB_COMPLETE )

D'après ce que je peux dire, lorsqu'il y a un transfert de l'hôte vers le périphérique, la SUBMIT Le "paquet" contient les données USB réellement transmises. Lorsqu'il y a un transfert du dispositif vers l'hôte (initié par l'hôte, comme toujours), le "paquet" de données de l COMPLETE Le "paquet" contient les données USB réellement transmises.

Du point de vue de l'analyse d'un protocole, tous les autres "paquets" sont une distraction OU une erreur URB. Pour filtrer les distractions, j'utilise le filtre d'affichage suivant !(usb.urb_type == URB_SUBMIT && usb.endpoint_address.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_address.direction == OUT)

Je crois que le protocole USB implique un certain nombre de prises de contact, d'ACK et de retransmissions, mais tout cela est géré par le contrôleur hôte et le système d'exploitation n'est pas impliqué. Je ne pense pas, par exemple, que le système d'exploitation garde la trace des accusés de réception ou des retransmissions.

Au fait, j'utilise la commande suivante pour analyser un protocole. En plus d'effectuer le filtrage ci-dessus, elle n'affiche que le numéro du point de terminaison (en décimal) et les données USB. Ceci sur une machine GNU/Linux utilisant le périphérique usbmon1 pour renifler, et en supposant que le périphérique USB que je veux surveiller est sur le bus 1 et a l'adresse 11.

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

EDIT : le champ endpoint_address a été précédemment endpoint_number

Répondu el 11 de Février, 2015 par manuel (11 Points )

6voto

spicy avatar
spicy Points 1

Les logs USB de WireShark sont effectués au niveau du système d'exploitation. Avec Linux, il est basé sur les données que usbmon génère et qui sont basées sur la structure interne URB de Linux décrite. aquí . Donc, regarder les commentaires et la documentation du noyau et de WireShark fournit le meilleur aperçu de ce que c'est.

Ce que j'ai trouvé dans la documentation du noyau, c'est que les paquets sont des structs usbmon suivis des données envoyées et reçues. Voici la structure (copiée 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 */
};
Répondu el 13 de Octobre, 2017 par spicy (1 Points )

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

Yandex
X