wireshark usb izleri açıklamalar


10

Bir usb (HID) cihazını tersine çevirmeye çalışıyorum ve wireshark'ta (linux veya windows üzerinde usbmon + wireshark) gördüğüm şeyin usb protokolü ile nasıl ilişkili olduğunu gerçekten anlayamıyorum ?. Www.usb.org adresinden usb protokolüne baktım.

Wireshark ne gösteriyor?

1) paket başına bir satır? (jeton, veri, el sıkışma)

2) İşlem başına bir satır mı? (jeton + [veri] + el sıkışma) (tahminim)

3) Kontrol transferi başına bir satır mı?

İşlemin yönü de çok gariptir (alanlara / alanlardan). En azından, beklentilerime uymuyor :-) ... Ve numaralandırma, saklanmış rapor vb. Veri kısmı bazen kurulum verileriyle (8 bayt) görüntüleniyor ve bazen değil ... URB'nin ne olduğunu gerçekten bilmiyorum ... görebildiğim kadarıyla usb protokolünde bundan bahsedilmiyor ... Bana daha yüksek bir yığın seviyesinde wireshark / usbmon izlemesi ve ne olacağını çıkarmaya çalışıyor. telin üstünde ...

Aşağıda görebildiğim bir örnek, burada ne görüyoruz?

a) Teknik özelliklerde bmtype = 0x20 (kurulumun, çerçeve No = 599) bile bulunamadı.

b) Bir HID cihazım olduğu için, bunun bir rapor / özellik yapılandırması olabileceğini varsaydım (numaralandırma bu aşamada geçirilir). Böylece yönü kabul edebilirim (host-> device). ama veriler nerede? Yoksa burada veri aşaması yok mu? O halde çerçeve 600 nedir?

c) çerçeve 600 nedir? veri?

d) çerçeve 601 nedir? bir durum ACK? ... sonra veri ve ACK aynı kaynağa sahip?

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

Açıkçası bir şey eksik. Wireshark ekranının protokolle nasıl ilişkili olduğuna dair genel bir açıklama ve (buna dayanarak), yukarıdaki izin anlamı memnuniyetle karşılanmaktadır!

Başlangıçta bunu Stack Overflow'da yayınladım, ancak doğrudan bir programlama sorusu olmadığı söylendi. Umarım buraya daha iyi uyuyor.

Yanıtlar:


12

USB URB bir IP paketi gibidir ve bir USB uç noktası bir IP bağlantı noktası gibidir. USB uç noktaları 0x00-0x7F ana bilgisayarda ve 0x80-0xFF uç noktaları cihazda (sanırım). Bu nedenle, uç nokta aktarım yönünü kodlar. lsusbbir cihazın hangi uç noktaları ve hangi aktarım türlerini desteklediğini gösterir.

Wireshark'ın yakaladığı aktivite birimini belirtmek için tırnak içinde "paketler" kullanacağım. Bunlar kelimenin tam anlamıyla kabloya gönderilen şey değil. Örneğin, "paketler", USB veri yolu üzerinden aktarılmasa bile aktarım başlatıldığında zaman damgalarına sahip olacaktır.

USB protokolünü koklamanın en kafa karıştırıcı yönünün, her USB URB için iki Wireshark "paketi" görmeniz olduğunu düşünüyorum. Ana bilgisayar bir aktarım başlattığında, bu bir URB_SUBMIT(Wireshark ekran filtresi usb.urb_type == URB_SUBMIT) olur. Aktarım tamamlandığında, bu bir URB_COMPLETE(Wireshark ekran filtresi usb.urb_type == URB_COMPLETE)

Anlatabileceğim kadarıyla, ana bilgisayardan cihaza aktarım olduğunda, SUBMIT"paket" iletilen gerçek USB verilerini içerir. Aygıttan ana bilgisayara aktarma olduğunda (her zaman olduğu gibi ana bilgisayar tarafından başlatılır), COMPLETE"paket" iletilen gerçek USB verilerini içerir.

Bir protokol analiz açısından, diğer tüm "paketler" bir oyalama VEYA bir URB hatasıdır. Dikkat dağıtıcı unsurları filtrelemek için aşağıdaki ekran filtresini kullanıyorum !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

USB protokolünün bazı el sıkışmalarını ve ACK'ları ve yeniden iletimleri içerdiğine inanıyorum, ancak bunların hepsi ana bilgisayar denetleyicisi tarafından gerçekleştiriliyor ve işletim sistemi dahil değil. Örneğin, işletim sisteminin alındı ​​bildirimlerini veya yeniden iletimleri izlediğini düşünmüyorum.

Bu arada, bir protokol analiz etmek için aşağıdaki komutu kullanıyorum. Yukarıdaki filtrelemeyi yapmaya ek olarak, yalnızca bitiş noktası numarasını (ondalık olarak) ve USB verilerini görüntüler. Bu, koklamak için usbmon1 cihazını kullanan ve izlemek istediğim USB cihazının veri yolu 1'de ve adres 11'e sahip olduğunu varsayarak bir GNU / Linux makinesinde.

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


Cevabınız için teşekkürler Gus. Aslında bu tüm sorularıma cevap vermiyor, ama en iyi (benzersiz olarak) cevabı verdiniz !. Örnek olarak dahil ettiğim yakalamayı yorumlamak ister misiniz (bir HID cihazından alarak). Ne görüyoruz? izdeki hangi alanlar neyi söyler? Tekrar teşekkürler!
user415772

3

WireShark USB günlükleri işletim sistemi düzeyinde yapılır. Linux ile onun usbmon Linux'un iç URB yapısı tarif üzerine dayandığı oluşturduğu verilere dayalı burada . Bu nedenle, çekirdek ve WireShark yorumlarına ve belgelerine bakmak, ne olduğu hakkında en iyi bilgileri sağlar.

Çekirdek dokümanlardan bulduğum şey, paketlerin gönderilen ve alınan verileri takip eden usbmon yapıları olmasıdır. Bu yapı ( buradan kopyalanır ):

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 */
};
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.