Wireshark USB śledzi wyjaśnienia

Usiłuję dokonać inżynierii wstecznej urządzenia USB (HID) i nie mogę naprawdę zrozumieć, jak to, co widzę w wireshark (usbmon + wireshark w systemie Linux lub Windows) odnosi się do protokołu USB ?. Przejrzałem protokół USB z www.usb.org.

Co pokazuje Wireshark?

1) Jedna linia na pakiet? (token, dane, uścisk dłoni)

2) Jedna linia na transakcję? (token + [dane] + handshake) (moje przypuszczenie)

3) Jedna linia na transfer kontrolny?

Kierunek transakcji jest również bardzo dziwny (do / z pól). Przynajmniej nie spełnia moich oczekiwań :-) ... A część danych wyliczenia, ukryty raport itp ... wydaje się czasem wyświetlać dane konfiguracji (8 bajtów), a czasem nie ... tak naprawdę nie wiem, czym jest URB ... nie ma wzmianki o tym w protokole USB, o ile mogłem zobaczyć ... Wygląda mi na to, że śledzenie wireshark / usbmon na wyższym poziomie stosu i próbuje wydedukować, co by było z drutu z tego ...

Przykład tego, co widzę, znajduje się poniżej, co widzimy tutaj ?.

a) Nie mogłem nawet znaleźć bmtype = 0x20 (ustawienia, ramka nr = 599) w specyfikacjach.

b) Ponieważ mam urządzenie HID, założyłem, że może to być konfiguracja raportu / funkcji (wyliczenie jest przekazywane na tym etapie). Mogę więc zgodzić się z kierunkiem (host-> urządzenie). ale gdzie są dane? Czy nie ma tutaj fazy danych? Co to jest ramka 600?

c) co to jest ramka 600? dane?

d) co to jest ramka 601? status ACK? ... ale czy dane i ACK mają to samo źródło?

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

Oczywiście czegoś mi brakuje. Ogólne wyjaśnienie, w jaki sposób ekran Wireshark odnosi się do protokołu i (na jego podstawie) znaczenie powyższego śladu jest mile widziane!

Oryginalnie opublikowałem to na Stack Overflow, ale powiedziano mi, że nie było to bezpośrednio pytanie programistyczne. Mam nadzieję, że lepiej tutaj pasuje.

USB URB jest jak pakiet IP, a punkt końcowy USB jest jak port IP. Punkty końcowe USB 0x00-0x7F znajdują się na hoście, a punkty końcowe 0x80-0xFF znajdują się na urządzeniu (tak myślę). Dlatego punkt końcowy koduje kierunek transferu. lsusbpokaże, jakie punkty końcowe i jakie typy przesyłania obsługuje urządzenie.

Użyję „pakietów” w cudzysłowach, aby oznaczać jednostkę aktywności, którą przechwytuje Wireshark. To nie jest dosłownie to, co jest wysyłane za pomocą drutu. Na przykład „pakiety” będą miały znaczniki czasu, kiedy inicjowane są transfery, nawet jeśli nie są one przesyłane przez magistralę USB.

Myślę, że najbardziej mylącym aspektem wąchania protokołu USB jest to, że widzisz dwa „pakiety” Wireshark dla każdego USB URB. Gdy host inicjuje transfer, jest to URB_SUBMIT(filtr wyświetlania Wireshark usb.urb_type == URB_SUBMIT). Po zakończeniu przesyłania jest to URB_COMPLETE(filtr wyświetlania Wireshark usb.urb_type == URB_COMPLETE)

Z tego, co mogę powiedzieć, kiedy następuje transfer z hosta na urządzenie, SUBMIT„pakiet” zawiera faktycznie przesłane dane USB. Kiedy następuje transfer z urządzenia do hosta (jak zawsze inicjowany przez hosta), COMPLETE„pakiet” zawiera faktycznie przesłane dane USB.

Z punktu widzenia analizy protokołu wszystkie inne „pakiety” są rozproszeniem LUB błędem URB. Aby odfiltrować zakłócenia, używam następującego filtra wyświetlania !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Uważam, że protokół USB wiąże się z pewnymi uzgadnianiem, ACK-ami i retransmisjami, ale wszystko to jest obsługiwane przez kontroler hosta i system operacyjny nie jest zaangażowany. Nie sądzę, na przykład, że system operacyjny śledzi potwierdzenia lub retransmisje.

Nawiasem mówiąc, używam następującego polecenia do analizy protokołu. Oprócz powyższego filtrowania wyświetla tylko numer punktu końcowego (dziesiętnie) i dane USB. Odbywa się to na komputerze GNU / Linux używającym urządzenia usbmon1 do wąchania i zakładając, że urządzenie USB, które chcę monitorować, znajduje się na magistrali 1 i ma adres 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

Dzienniki USB WireShark są wykonywane na poziomie systemu operacyjnego. W Linuksie jest on oparty na danych generowanych przez usbmon, który jest oparty na opisanej tutaj wewnętrznej strukturze URB Linuksa . Zatem przeglądanie komentarzy i dokumentów do jądra i WireShark zapewnia najlepszy wgląd w to, co to jest.

Z dokumentacji jądra dowiedziałem się, że pakiety to struktury usbmon, po których następują dane wysyłane i odbierane. Oto struktura (skopiowana stąd ):

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 */
};