wireshark usb traça explicações

Question

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

O que o wireshark mostra?

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

2) Uma linha por transação? (token + [data] + handshake) (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, ele não corresponde às minhas expectativas :-) ... E a parte de dados da enumeração, relatório hid etc ... parece algumas vezes ser exibida com os dados de setup (8 bytes) e as vezes não ... eu não realmente não sei o que é URB ... não há nenhuma menção de que no protocolo usb, tanto quanto pude ver ... Parece-me que wireshark / usbmon rastrear em um nível de pilha mais alto e tenta deduzir o que seria no fio de que ...

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

a) Eu nem encontrei o bmtype = 0x20 (da configuração, frame No = 599) nas especificações.

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

c) o que é o quadro 600? os dados?

d) o que é o quadro 601? um status ACK? ... mas depois os dados e o 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 sentindo falta de algo. Uma explicação geral sobre como o display wireshark se relaciona com o protocolo e, (com base nisso), o significado do traço acima é bem-vindo!

Eu originalmente postei isso no Stack Overflow, mas me disseram que não era diretamente uma questão de programação. Espero que caiba melhor aqui.

    

Answer 1

Um USB URB é como um pacote IP e um ponto final 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 endpoint codifica a direção da transferência. lsusb mostrará a você quais endpoints e quais tipos de transferência um dispositivo suporta.

Usarei "pacotes" entre aspas para indicar a unidade de atividade que o wireshark captura. Estes não são literalmente o que está sendo enviado no 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 farejar o protocolo USB é que você vê dois "pacotes" do Wireshark para cada USB URB. Quando o host inicia alguma transferência, isso é um URB_SUBMIT (filtro de exibição do Wireshark usb.urb_type == URB_SUBMIT ). Quando a transferência for concluída, isso é um URB_COMPLETE (filtro de exibição do Wireshark usb.urb_type == URB_COMPLETE )

Pelo que posso dizer, 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 (iniciada 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 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)

Eu acredito que o protocolo USB envolve alguns handshaking e ACKs e retransmissões, mas isso é tudo tratado pelo controlador host, e o sistema operacional não está envolvido. Eu não acho, por exemplo, que o SO monitore 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 do USB. Isso é em uma máquina GNU / Linux usando o dispositivo usbmon1 para farejar, e assumindo que o dispositivo USB que eu quero monitorar está no barramento 1 e tem 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

    

Answer 2

Os registros USB do WireShark são feitos no nível do sistema operacional. Com o Linux, ele é baseado nos dados gerados pelo usbmon, que é baseado na estrutura URB interna do Linux, descrita aqui . Então, olhando para o kernel e WireShark comentários e documentos fornece a melhor visão sobre o que é.

O que eu encontrei na documentação do kernel é que os pacotes são usbmon structs seguidos pelos dados enviados e recebidos. Esta é a estrutura (copiada de aqui ):

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