wireshark usb traços explicações

Estou tentando fazer engenharia reversa de um dispositivo usb (HID) e não consigo descobrir como o que vejo no wireshark (usbmon + wireshark no linux ou windows) se relaciona com o protocolo usb ?. Eu olhei para o protocolo usb em www.usb.org.

O que mostra o wireshark?

1) Uma linha por pacote? (token, dados, aperto de mão)

2) Uma linha por transação? (token + [dados] + aperto de mão) (meu palpite)

3) Uma linha por transferência de controle?

A direção da transação também é muito estranha (para / de campos). Pelo menos, não corresponde às minhas expectativas :-) ... E a parte dos dados da enumeração, relatório oculto etc. ... às vezes parece ser exibida com os dados de configuração (8 bytes) e às vezes não ... realmente sei o que é URB ... não há menção disso no protocolo usb, tanto quanto pude ver ... Parece-me que o wireshark / usbmon rastreia em um nível de pilha mais alto e tenta deduzir o que seria no fio disso ...

Um exemplo do que eu posso ver é dado abaixo, o que vemos aqui?

a) Não consegui encontrar bmtype = 0x20 (da configuração, quadro No = 599) nas especificações.

b) Como eu tenho um dispositivo HID, assumi que isso poderia ser uma configuração de relatório / recurso (a enumeração é passada neste estágio). Então eu poderia concordar com a direção (host-> dispositivo). mas onde estão os dados? Ou não há fase de dados aqui? O que é o quadro 600 então?

c) qual é o quadro 600? os dados?

d) qual é o quadro 601? um status ACK? ... mas os dados e ACK têm a mesma fonte?

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, estou perdendo alguma coisa. Uma explicação geral sobre como a tela do wireshark se relaciona com o protocolo e (com base nele) é bem-vindo o significado do rastreamento acima!

Originalmente, eu postei isso no Stack Overflow, mas me disseram que não era diretamente uma questão de programação. Espero que se encaixe melhor aqui.

Um URB USB é como um pacote IP e um terminal USB é como uma porta IP. Os pontos de extremidade USB 0x00-0x7F estão no host e os pontos de extremidade 0x80-0xFF estão no dispositivo (eu acho). Portanto, o terminal codifica a direção da transferência. lsusbmostrará quais pontos de extremidade e quais tipos de transferência são suportados por um dispositivo.

Usarei "pacotes" entre aspas para significar a unidade de atividade que o wireshark captura. Estes não são literalmente o que está sendo enviado por fio. Por exemplo, os "pacotes" terão registros de data e hora para quando as transferências foram iniciadas, mesmo que isso não seja transmitido pelo barramento USB.

Acho que o aspecto mais confuso de cheirar o protocolo USB é que você vê dois "pacotes" do Wireshark para cada URB USB. Quando o host inicia alguma transferência, é um URB_SUBMIT(filtro de exibição do Wireshark usb.urb_type == URB_SUBMIT). Quando a transferência é concluída, é um URB_COMPLETE(filtro de exibição do Wireshark usb.urb_type == URB_COMPLETE)

Pelo que sei, quando há uma transferência do host para o dispositivo, o SUBMIT"pacote" contém os dados USB reais transmitidos. Quando há uma transferência do dispositivo para o host (iniciado pelo host, como sempre), o COMPLETE"pacote" contém os dados USB reais transmitidos.

Do ponto de vista da análise de um protocolo, todos os outros "pacotes" são uma distração OU um erro de URB. Para filtrar as distrações, eu uso o seguinte filtro de exibição !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Acredito que o protocolo USB envolva alguns handshaking, ACKs e retransmissões, mas tudo isso é tratado pelo controlador host e o sistema operacional não está envolvido. Não acho que, por exemplo, o sistema operacional acompanhe os reconhecimentos ou retransmissões.

A propósito, estou usando o seguinte comando para analisar um protocolo. Além de fazer a filtragem acima, ele exibe apenas o número do terminal (em decimal) e os dados USB. Isso está em uma máquina GNU / Linux usando o dispositivo usbmon1 para detectar e assumindo que o dispositivo USB que eu quero monitorar esteja no barramento 1 e tenha o endereço 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

Os logs USB do WireShark são feitos no nível do SO. O Linux é baseado nos dados que o usbmon gera, com base na estrutura URB interna do Linux descrita aqui . Portanto, analisar os comentários e documentos do kernel e do WireShark fornece a melhor visão sobre o que é.

O que eu descobri nos documentos do kernel é que os pacotes são estruturas usbmon seguidas pelos dados enviados e recebidos. Esta é a estrutura (copiada daqui ):

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