wireshark usb melacak penjelasan

Saya mencoba untuk merekayasa balik perangkat usb (HID) dan tidak dapat benar-benar mengetahui bagaimana apa yang saya lihat di wireshark (usbmon + wireshark di linux, atau windows) terkait dengan protokol usb ?. Saya telah melihat protokol usb dari www.usb.org.

Apa yang ditampilkan wireshark?

1) Satu baris per paket? (token, data, jabat tangan)

2) Satu baris per transaksi? (token + [data] + jabat tangan) (tebakan saya)

3) Satu baris per transfer kendali?

Arah transaksi juga sangat aneh (ke / dari bidang). Setidaknya, itu tidak sesuai dengan harapan saya :-) ... Dan bagian data dari enumerasi, menyembunyikan laporan dll ... tampaknya kadang-kadang ditampilkan dengan data pengaturan (8 byte) dan kadang-kadang tidak ... Saya tidak benar-benar tahu apa itu URB ... tidak ada yang menyebutkan hal itu dalam protokol usb sejauh yang saya lihat ... Tampaknya bagi saya bahwa wireshark / usbmon melacak pada tingkat tumpukan yang lebih tinggi dan mencoba menyimpulkan apa yang akan terjadi pada kabel dari itu ...

Contoh apa yang bisa saya lihat diberikan di bawah ini, apa yang harus kita lihat di sini?

a) Saya bahkan tidak bisa menemukan bmtype = 0x20 (dari pengaturan, frame No = 599) dalam spesifikasi.

b) Karena saya memiliki perangkat HID, saya berasumsi ini bisa berupa konfigurasi laporan / fitur (enumerasi diteruskan pada tahap ini). Jadi saya bisa setuju dengan arah (perangkat host->). tapi dimana datanya? Atau tidak ada fase data di sini? Apa itu frame 600?

c) apa itu bingkai 600? data?

d) apa bingkai 601? status ACK? ... tetapi kemudian data dan ACK memiliki sumber yang sama?

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

Jelas saya kehilangan sesuatu. Penjelasan umum tentang bagaimana tampilan wireshark terkait dengan protokol dan, (berdasarkan itu), makna jejak di atas disambut!

Saya awalnya memposting ini di Stack Overflow, tetapi diberitahu itu bukan langsung pertanyaan pemrograman. Semoga lebih cocok di sini.

URB USB seperti paket IP dan titik akhir USB seperti port IP. Titik akhir USB 0x00-0x7F ada di host, dan titik akhir 0x80-0xFF ada di perangkat (saya pikir). Oleh karena itu, titik akhir mengkodekan arah transfer. lsusbakan menunjukkan titik akhir dan jenis transfer apa yang didukung perangkat.

Saya akan menggunakan "paket" dalam tanda kutip yang berarti unit aktivitas yang ditangkap oleh wireshark. Ini bukan apa yang sedang dikirim. Misalnya, "paket" akan memiliki cap waktu ketika transfer dimulai, meskipun ini tidak dikirim melalui bus USB.

Saya pikir aspek yang paling membingungkan dari mengendus protokol USB adalah Anda melihat dua "paket" Wireshark untuk setiap USB URB. Ketika tuan rumah melakukan beberapa transfer, itu adalah URB_SUBMIT(filter tampilan Wireshark usb.urb_type == URB_SUBMIT). Ketika transfer selesai, itu adalah URB_COMPLETE(tampilan filter Wireshark usb.urb_type == URB_COMPLETE)

Dari apa yang saya tahu, ketika ada transfer dari host ke perangkat, SUBMIT"paket" berisi data USB yang sebenarnya dikirimkan. Ketika ada transfer dari perangkat ke host (diprakarsai oleh host, seperti biasa), COMPLETE"paket" berisi data USB aktual yang dikirim.

Dari sudut pandang menganalisis protokol, semua "paket" lainnya adalah gangguan ATAU kesalahan URB. Untuk menyaring gangguan, saya menggunakan filter tampilan berikut !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

Saya percaya protokol USB memang melibatkan beberapa handshaking dan ACK dan transmisi ulang, tetapi ini semua ditangani oleh pengontrol host, dan OS tidak terlibat. Saya tidak berpikir, misalnya, OS melacak pengakuan atau transmisi ulang.

Omong-omong, saya menggunakan perintah berikut untuk menganalisis protokol. Selain melakukan pemfilteran di atas, itu hanya menampilkan angka titik akhir (dalam desimal) dan data USB. Ini ada di mesin GNU / Linux menggunakan perangkat usbmon1 untuk mengendus, dan dengan asumsi bahwa perangkat USB yang ingin saya monitor ada di bus 1 dan memiliki alamat 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

Log USB WireShark dilakukan pada level OS. Dengan Linux didasarkan pada data yang dihasilkan usbmon yang didasarkan pada struktur URB internal Linux yang dijelaskan di sini . Jadi, melihat komentar dan dokumen kernel dan WireShark memberikan wawasan terbaik tentang apa itu.

Apa yang saya temukan dari kernel docs adalah paketnya adalah usbmon struct diikuti oleh data yang dikirim dan diterima. Ini adalah struct (disalin dari sini ):

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