Wireshark USB 추적 설명


10

USB (HID) 장치를 리버스 엔지니어링하려고하는데 wireshark (Linux의 usbb + wireshark 또는 Windows)에서 USB 프로토콜과 어떻게 관련이 있는지 알 수 없습니다. www.usb.org에서 USB 프로토콜을 살펴 보았습니다.

wireshark는 무엇을 보여줍니까?

1) 패킷 당 한 줄? (토큰, 데이터, 악수)

2) 거래 당 한 줄? (토큰 + [데이터] + 핸드 셰이크) (내 추측)

3) 제어 전송 당 한 줄?

거래 방향 또한 필드마다 매우 이상합니다. 적어도 내 기대와 일치하지 않습니다 :-) ... 그리고 열거 형의 데이터 부분, 숨겨진 보고서 등은 때때로 설정 데이터 (8 바이트)와 함께 표시되는 것처럼 보이고 때로는 그렇지 않습니다 ... 실제로 URB가 무엇인지 알지 못합니다 ... USB 프로토콜에는 내가 볼 수있는 한 언급이 없습니다 ... Wireshark / usbmon이 더 높은 스택 레벨에서 추적되어 무엇이 될 것인지 추론하려고합니다. 그 철사에서 ...

내가 볼 수있는 것의 예는 다음과 같습니다. 여기서 볼 수 있습니까?.

a) 사양에서 bmtype = 0x20 (설정의 프레임 번호 = 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 디스플레이가 프로토콜과 어떻게 관련되어 있는지에 대한 일반적인 설명과 (이를 기반으로) 위 추적의 의미를 환영합니다!

나는 이것을 Stack Overflow에 게시했지만 직접 프로그래밍 질문이 아니라고 들었습니다. 여기에 더 잘 맞기를 바랍니다.

답변:


11

USB URB는 IP 패킷과 같고 USB 엔드 포인트는 IP 포트와 같습니다. USB 엔드 포인트 0x00-0x7F는 호스트에 있고 엔드 포인트 0x80-0xFF는 장치에 있습니다 (제 생각에는). 따라서 엔드 포인트는 전송 방향을 인코딩합니다. lsusb장치가 지원하는 엔드 포인트 및 전송 유형을 표시합니다.

wireshark가 포착하는 활동 단위를 의미하기 위해 따옴표로 "패킷"을 사용할 것입니다. 이것들은 문자 그대로 유선으로 전송되는 것이 아닙니다. 예를 들어, "패킷"에는 USB 버스를 통해 전송되지 않더라도 전송이 시작된 시간에 대한 타임 스탬프가 있습니다.

USB 프로토콜 스니핑의 가장 혼란스러운 측면은 각 USB URB마다 두 개의 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_address.direction == IN) && !(usb.urb_type == URB_COMPLETE && usb.endpoint_address.direction == OUT)" -Tfields -e usb.endpoint_address -e usb.capdata


답변 주셔서 감사합니다, 거스 실제로 이것은 내 모든 질문에 대답하는 것은 아니지만 가장 독창적 인 답변을 냈습니다!. 예제로 포함시킨 캡처에 대해 언급 해 주시겠습니까 (HID 장치에서 촬영). 우리는 무엇을보고 있습니까? 트레이스의 어떤 필드가 무엇을 알려줍니까? 다시 감사합니다!
user415772

3

WireShark USB 로그는 OS 수준에서 수행됩니다. Linux에서는 여기에 설명 된 Linux의 내부 URB 구조를 기반으로 usbmon이 생성하는 데이터를 기반으로합니다 . 따라서 커널 및 WireShark 주석 및 문서를 보면 그것이 무엇인지에 대한 최상의 통찰력을 제공합니다.

커널 문서에서 찾은 것은 패킷이 usbmon structs 다음에 송수신되는 데이터라는 것입니다. 이것은 구조체입니다 ( 여기 에서 복사 됨 ).

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.