Wireshark USBトレースの説明


10

私はusb(HID)デバイスをリバースエンジニアリングしようとしていますが、wireshark(Linuxまたはwindowsでのusbmon + wireshark)に表示されるものがusbプロトコルにどのように関係するのか本当に理解できません。私はwww.usb.orgからのusbプロトコルを見てきました。

Wiresharkは何を示していますか?

1)パケットごとに1行ですか?(トークン、データ、ハンドシェイク)

2)トランザクションごとに1行ですか?(トークン+ [データ] +ハンドシェイク)(私の推測)

3)コントロール転送ごとに1行ですか?

トランザクションの方向も非常に奇妙です(フィールドへ/から)。少なくとも、それは私の期待とは一致しません:-) ...そして、列挙、隠しレポートなどのデータ部分は、設定データ(8バイト)で表示されることがあり、時には表示されないようです... URBが本当にわからない...私が見る限り、usbプロトコルではそれについての言及はありません...ワイヤスタック/ usbmonがより高いスタックレベルでトレースし、何になるかを推測しようとしているように見えますその上で...

私が見ることができるものの例を以下に示します、ここで何を見るのですか?

a)仕様にbmtype = 0x20(セットアップのフレームNo = 599)も見つかりませんでした。

b)HIDデバイスを持っているので、これはレポート/機能の構成である可能性があると想定しました(列挙はこの段階で渡されます)。だから私は方向に同意することができました(ホスト->デバイス)。しかし、データはどこにありますか?または、ここにデータフェーズはありませんか?では、フレーム600とは何でしょうか。

c)フレーム600とは データ?

d)フレーム601とは ステータスACK?...しかし、データとACKは同じソースを持っていますか?

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

明らかに何かが欠けています。Wiresharkの表示がプロトコルにどのように関連しているか、および(それに基づいて)上記のトレースの意味に関する一般的な説明を歓迎します!

私はもともとこれをスタックオーバーフローに投稿しましたが、それは直接プログラミングの質問ではないと言われました。ここにうまく収まることを願っています。

回答:


11

USB URBはIPパケットのようなもので、USBエンドポイントはIPポートのようなものです。USBエンドポイント0x00-0x7Fはホスト上にあり、エンドポイント0x80-0xFFはデバイス上にあると思います(私はそう思います)。したがって、エンドポイントは転送の方向をエンコードします。lsusbデバイスがサポートするエンドポイントと転送タイプを表示します。

私は引用符で「パケット」を使用して、wiresharkがキャプチャするアクティビティの単位を意味します。これらは文字通りネットワーク上で送信されているものではありません。たとえば、「パケット」には、転送が開始されたときのタイムスタンプが含まれますが、これはUSBバス経由で送信されません。

USBプロトコルのスニッフィングで最も混乱する点は、USB URBごとに2つのWireshark "パケット"が表示されることです。ホストが転送を開始すると、それがURB_SUBMIT(Wiresharkディスプレイフィルターusb.urb_type == URB_SUBMIT)になります。転送が完了すると、それがURB_COMPLETE(Wireshark表示フィルターusb.urb_type == URB_COMPLETE)になります。

私が知ることができることから、ホストからデバイスへの転送があるとき、SUBMIT「パケット」には送信された実際のUSBデータが含まれています。デバイスからホストへの転送がある場合(いつものようにホストによって開始されます)、COMPLETE「パケット」には送信された実際のUSBデータが含まれます。

プロトコルの分析の観点からは、他のすべての「パケット」は、注意散漫またはURBエラーです。気晴らしを取り除くために、私は次の表示フィルターを使用します !(usb.urb_type == URB_SUBMIT && usb.endpoint_number.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_number.direction == OUT)

USBプロトコルにはいくつかのハンドシェイクとACKおよび再送信が含まれていると思いますが、これはすべてホストコントローラーによって処理され、OSは関与しません。たとえば、OSが確認応答や再送信を追跡しているとは思いません。

ちなみに、次のコマンドを使用してプロトコルを分析しています。上記のフィルタリングに加えて、エンドポイント番号(10進数)とUSBデータのみが表示されます。これは、usbmon1デバイスを使用してスニッフィングするGNU / Linuxマシン上にあり、監視するUSB​​デバイスがバス1にあり、アドレスが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


答えてくれてありがとう、ガス。実際、これは私の質問のすべてに答えるものではありませんが、あなたは最高の(ユニークな)答えを出しました!。私が例として含めたキャプチャ(HIDデバイスから取得)にコメントしていただけませんか。何が見える?トレースのどのフィールドが何を示していますか?再度、感謝します!
user415772 2015

3

WireShark USBログはOSレベルで行われます。Linuxでは、usbmonが生成するデータに基づいています。これは、ここで説明する Linuxの内部URB構造に基づいています。したがって、カーネルとWireSharkのコメントとドキュメントを見ると、それが何であるかについての最良の洞察が得られます。

カーネルのドキュメントからわかったことは、パケットはusbmon構造体であり、その後に送受信されるデータが続くことです。これは構造体です(ここからコピー):

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 */
};
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.