Reverse-engineering the Kinect is a little easier since we have a known-working system (Xbox 360). Instead of guessing commands, we can just see what commands the Xbox sends and 'replay them'

This requires being able to listen into those commands, however. With protocols such as SPI, Serial, Parallel and i2c, you can listen in with any logic analyzer or oscilloscope. USB is fast/complex enough to require its own kind of logic analyzer. The one we'll be using is called the Beagle480 from TotalPhase. This is the 'high speed' USB analyzer, which we splurged on. (For many devices, Low/Full speed is fast enough, and there's a lower cost analyzer available.)

The USB analyzer acts as a 'tap' that plugs in between the Xbox and the Kinect. A computer is conneted as well. The computer receives all the data being transmitted into memory and logs it.

If you can connect the device to a computer, there are tons of free USB-packet-capture programs that don't require a hardware man-in-the-middle. In our case, the Kinect must connect to an XBox and we can't run software on it, necessitating the Beagle

From left to right there is a DIN connector, USB A connector and USB B connector. The Xbox connects to the USB B and the Kinect connects to the USB A. The DIN connector is for other kinds of data sniffing (like SPI or i2c).

On the other side, a single B connector which goes to the listening computer

The best way we've found to get the right data is to make sure to get even the 'enumeration' (initialization) packets so plug in the listening computer and start up the software. Then plug in the other end to the devices you want to sniff.

Lookin' at Logs

Since you probably don't have a USB analyzer, we have some logs that you can use to follow along with us. Visit the GitHub repository and click the **Downloads** button

Make yourself a sandwich, its a big file!

Also download the Beagle Data Center software (Mac/Win/Linux) and install it

OK now that you've eaten, lets open up the enuminit.tdc file. This is the full enumeration and initialization.

Remember that when we log the data, there's a lot of it that we can then pare down!

Let start by remembering that there are four devices (hub, camera, mic, motor) but we only need to listen to one (motor). Click on the Bus tab on the lower right

We have a few devices. Lets explore each one

If you click on Unconfigured device (0) you'll see that it was not captured. This is probably because I jiggled the cable when inserting it so it started to create a device and then got disconnected. Its not important.

Click on (1) This device is a Class device type USB Hub. That's the internal hub. We can ignore this as well.

Device #4 has a PID of 688, that's in decimal. If we convert it to hex we get 0x02b0 - this is the Motor device!

Now we can filter so that only this device's logs are shown.

Our log screen is much shorter now.

You can see that there's some initialization and then just two repeating motifs: a 1 byte message alternated with a 10 byte message.

For the motor to move according to the xbox's wishes, there must be some command sent from the xbox to the kinect. Lets filter some more to see just commands sent to the device

Go to the LiveFilter and select Host-to-Device.

Now we've really pared it down. There are only four commands sent to the kinect motor, since the motor moves during initialization we can just try each one. Lets look at each command

Command 1 has a bRequest of 0x06 and a wValue of 4, the wLength is 0 which means no data is written, the entire command is the Request and Value.