Re: reverse-engineering a usb device

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Daniel

> Most of your packets are consist of standard MSD query. However, there
> are patterns that I don't recognize. These packets have no CBW/CSW
> signature. Either it's a corrupted command or part of the data from last
> MSD query (but I don't think it is).
>
> down 25.875: 00 00 00 00 7f 20 00 00
> up     25.875: 70 00 02 00 00 00 00 0a
> down 25.891: 00 00 00 00 00 00 00 0a
> up     25.891: 70 00 02 00 00 00 00 0a
> down 25.906: 70 00 02 00 00 00 00 0a
> up     25.906: 70 00 02 00 00 00 00 0a

As you'll see below, these happen quite often. Interesting, this could
be some kind of polling then.

> The only command that's allowed in MSD bulk endpoint is just CBW/CSW.
> Other commands (including MSD class specific command) should be
> delivered through default/control pipe. That is if the device strictly
> following the USB standard (and if my memory about USB standard is still
> intact =D ).

Ok, so I group the commands (by the first 4 bytes):

$ grep -o "    00000000: .. .. .. .." usbsnoop.log | sort | uniq -c
    280     00000000: 00 00 00 00
    132     00000000: 00 80 00 00
      1     00000000: 04 03 09 04
      2     00000000: 09 02 20 00
      1     00000000: 12 01 00 02
      1     00000000: 1c 03 32 00
      4     00000000: 30 00 38 00
      4     00000000: 40 a4 55 80
   1436     00000000: 55 53 42 43
    714     00000000: 55 53 42 53
    176     00000000: 70 00 02 00
      4     00000000: 70 00 05 00
      1     00000000: 80 06 00 01
      2     00000000: 80 06 00 02
      2     00000000: 80 06 00 03
      2     00000000: 80 06 05 03
      4     00000000: 81 07 b9 b7
      1     00000000: a1 fe 00 00

If I understand corrrectly I can now rule out all of the "55 53 42 43"
and "55 53 42 53" commands as they are CBW/CSW commands for the mass
storage class. I'm getting closer.

This doesn't show which pipe the command was sent through though. So I
try to figure out what pipes are being used:

$ grep PipeHandle usbsnoop.log | sort | uniq -c
      1   Interface[0]: Pipes[0] : PipeHandle        = 0x822d380c
      1   Interface[0]: Pipes[1] : PipeHandle        = 0x822d382c
      1   Interface: Pipes[0] : PipeHandle        = 0x82289974
      1   Interface: Pipes[1] : PipeHandle        = 0x82289994
     64   PipeHandle = 82289974 [endpoint 0x00000081]
   2716   PipeHandle           = 82289974 [endpoint 0x00000081]
   1428   PipeHandle           = 82289994 [endpoint 0x00000002]
      8   PipeHandle           = 823a0cb0

$ grep -n "PipeHandle           = 823a0cb0" usbsnoop.log
25:  PipeHandle           = 823a0cb0
48:  PipeHandle           = 823a0cb0
70:  PipeHandle           = 823a0cb0
93:  PipeHandle           = 823a0cb0
115:  PipeHandle           = 823a0cb0
137:  PipeHandle           = 823a0cb0
159:  PipeHandle           = 823a0cb0
276:  PipeHandle           = 823a0cb0

$ wc -l usbsnoop.log
45558 usbsnoop.log

As you can see, the control pipe (endpoint 0) is only used 8 times in
the very beginning. The whole log used here covers about 14s of
communication between host and device. The last command through the
control pipe happens ~400ms after plugging in the device.

Thanks for your valuable input so far and let me know if you recognize
anything interesting in the posted output.

Thanks a lot,
Chris
-- 
echo mailto: NOSPAM !#$.'<*>'|sed 's. ..'|tr "<*> !#:2" org@fr33z3

--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ


[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux