28C3: Reverse engineering USB devices

In this talk from the recent 28C3 conference in Berlin, Drew Fisher discusses the process of reverse engineering the Kinect audio protocol. He shows how the USB standard can help a reverse engineer out and proceeds to analyze a set of USB logs, finding patterns, building understanding, developing hypotheses of message structure, and eventually implementing a userspace driver.

You can download the PDF of the presentation slides from the 28C3 conference site.

Join the Conversation


  1. this is pure awesomeness, I am wondering whats the purpose of the HW USB sniffer, if software does the job?

    1. Hardware sniffers would be invaluable if you are working on the bus transceivers or link-level code and therefore might be sending malformed packets that would be dropped by the error checking in a standards compliant receiver.

    2. Hardware sniffers are also necessary if you can’t reasonably run both sniffing software and the working driver on the USB host, as was the case when the Kinect first came out – the only host that would speak the Kinect protocol was the Xbox360, so we pretty much had to have a hardware sniffer.

      The Kinect remains impossible to log on Windows with a USB filter driver, since Win7 appears to treat it as a separate class of device entirely – it doesn’t appear in the list of USB devices available to trace with BusDog.

      So some devices will require the hardware approach, and as shuckc noted, if you’re debugging a USB implementation on a device, it’s really helpful to see whatever was on the line, valid or no.

Leave a comment

Your email address will not be published. Required fields are marked *

Notify me of followup comments via e-mail. You can also subscribe without commenting.