Blog

In this post you can find how to hack kinect by using USB.Just you have to follow along at home guide to reverse engineer USB.Kinet is now hack bounty and the USB logs used by the bounty winner…..

USB is a very complex protocol, must more complicated than Serial or Parallel, SPI and even I2C. USB uses only two wires but they are not used as ‘receive’ and ‘transmit’ like serial. Rather, data is bidirectional and differential – that is the data sent depends on the difference in voltage between the two data lines D+ and D.USB is also very structured. This is good for reverse engineering because it means that at least the format of packets is agreed upon and you won’t have to deal with check-sums. The bad news is it means you have to have software assistance to decode the complex packet structure. The good news is that every computer now made has a USB host core, that does a lot of the tough work for you, and there are many software libraries to assist.

Steps To Hack Kinect :

The first place to start is to see what devices and “interfaces” or “configurations” are available for the USB device. The nicest way to do this is to use lsusb (Linux) or system_profiler (Mac) which is a “list usb” program available for Linux and mac. Sadly, it does not exist for windows, so find a mac or linux computer or friend, you’ll only need it for a minute!For linux, run lsusb -vv (ultra verbose) for Mac, run system_profiler SPUSBDataType.There’s a bunch more stuff like USB keys and such installed but this is a good starting point. Note that the Kinect is actually 4 USB devices – a hub, a camera, a microphone (audio) and a motor. The hub is just an easy way for the device to combine three separate chips into a single cable. We’ll be investigating the Xbox NUI Motor since its the simplest. Note the Vendor ID = 0x045e and Product ID = 0x2b0. Every type USB device must have a unique VID and PID. The VID is the manufacturer. In this case, 0x045e is the VID for Microsoft. All Microsoft products will have that VID. Each product has a different PID, so all Kinect Motors use PID 0x02b0 this doesn’t differ between two Kinects, they’ll both have the same PID. The VID/PID are used as a way to have the proper driver find the product. Its a lot better than serial COM ports because COM ports change names but VID/PID are burned into the device firmware.

The next best thing to do after you’ve determined the VID/PID is to identify the descriptor of the device. A descriptor is a sort of ‘menu’ of what the device can do and how it likes to transfer data. In general, each device has one descriptor. Sometimes a device has more than one descriptor and you can choose which one you want but its not terribly common so we’re just going to ignore it.A fantastic way to get the descriptor without having to write any software is to run lsusb -vv on a linux computer. We haven’t found an equivalent for Windows or Mac, so find a friend with a Linux computer.You can see the VID and PID up there. Next we’ll look at bNumConfigurations (how many different descriptors we have) and lucky for us the number is 1. Next, look at the Interface Descriptor in particular, bNumEndpoints which is 0. This means there are no Endpoints.

Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x045e Microsoft Corp.
  idProduct          0x02ae
  bcdDevice            1.0b
  iManufacturer           2 Microsoft
  iProduct                1 Xbox NUI Camera
  iSerial                 3 A00366A08793039A
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           32
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower               16mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass       255 Vendor Specific Class
      bInterfaceSubClass    255 Vendor Specific Subclass
      bInterfaceProtocol    255 Vendor Specific Protocol
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0bc0  2x 960 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            1
          Transfer Type            Isochronous
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0bc0  2x 960 bytes
        bInterval               1
Device Qualifier (for other device speed):
  bLength                10
  bDescriptorType         6
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0        64
  bNumConfigurations      1
Device Status:     0x0001
  Self Powered

This device has two Isochronous endpoints both of which are IN type (data going INto the computer). This makes sense: the Kinect has a IR depth camera and a normal VGA camera. Two cameras, two Endpoints. Of course, there is also a Control endpoint not mentioned here, the Control endpoint could be used to set stuff like aperture, gamma correction, any sort of built-in filter, etc.

For windows, however, there must be some sort of driver to ‘grab’ the device for us. Usually drivers are complex and have like, interfaces that plug into the operating system. Like the cameras would show up as a camera device, the microphones as an audio device. We’re not quite ready for a detailed driver, what we’ll do is make a ‘shell driver’ which has no operating system capabilities but does let us send commands to it from software.Again, Mac/Linux people have this built into the OS kernel so skip this part if you don’t use windows.Use libusb a USB library for this,which is available for windows as libusb-win32 go there and download it.

The important part is entering in the matching VID and PID we found before

Now when you plug in the Kinect, it will attach itself the the LibUSB-win32 device driver

he fastest and easiest way we know to do this is to use LibUSB with a scripting language such as Python. There are LibUSB bindings for C and C++ and Perl but I happen to like Python so follow along!install PyUSB by downloading it and running python setup.py install in the expanded directory.

Attaching to the device:

import usb.core
import usb.util
import sys

# find our device
dev = usb.core.find(idVendor=0x045e, idProduct=0x02B0)

# was it found?
if dev is None:
    raise ValueError('Device not found')

# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()

print "all done"

Use Python + LibUSB to send Control Endpoint packets with the command “ctrl_transfer( bmRequestType, bmRequest, wValue, wIndex, nBytes)”.This command can do both sending and receiving depending on what bmRequestType says (input or output). Still, there is a lot of options here. To send the right command you need to know the RequestType and the right Request and ther right Value as well as the Index and how many bytes to read or write.

For bmRequestType the value passed :

• Bits 2, 3 and 4 are reserves so set them to 0.
• The direction is set by bit #7, 0 is a ‘write’ out to the device, 1 is a ‘read’ from the device
• The ‘type’ of message is two bits, 0 = Standard, 1 = Class, 2 = Vendor, 3 = Reserved. For many devices that are non-standard, you’ll probably want 2 for vendor type. If its a more standard type of device, like a camera or mic, try 0 or 1. 3 Is unused
• The last two bits are usd to determine the recipient for the message 0 = Device, 1 = Interface, 2 = Endpoint, 3 = Other. Go with 0 to start, you can try 2 if there are other endpoints

The safest thing to do is read data (no way to overwrite anything or configure) you can do that by sending packets with 0b11000000(Read Vendor data from Device) = 0xC0.start by setting Index to 0 and iterating through all the byte values (255 different values) of bmRequestand the first few hundred wValues. Its pretty safe to just read random data to a USB device. Start by reading one byte to see if anything shows up, then increase the value.

import usb.core
import usb.util
import sys

# find our device
dev = usb.core.find(idVendor=0x045e, idProduct=0x02B0)

# was it found?
if dev is None:
    raise ValueError('Device not found')

# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()

# Let's fuzz around! 

# Lets start by Reading 1 byte from the Device using different Requests
# bRequest is a byte so there are 255 different values
for bRequest in range(255):
    try:
        ret = dev.ctrl_transfer(0xC0, bRequest, 0, 0, 1)
        print "bRequest ",bRequest
        print ret
    except:
        # failed to get data for this request
        pass

Looks like Request values 0, 5, 16, 50, 54, 64, 80 and 112 all return some sort of data. The rest had nothing to read

OK lots of data, but what does it mean? This is where some guessing based on the device itself would come in handy. I’m terribly lazy though and if given an option to avoid a lot of guesswork, I’ll take it!

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.

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

Lookin’ at logs

Command #1 & 2 – LED blinky!

import usb.core
import usb.util
import sys

# find our device
dev = usb.core.find(idVendor=0x045e, idProduct=0x02B0)

# was it found?
if dev is None:
    raise ValueError('Device not found')

# set the active configuration. With no arguments, the first
# configuration will be the active one
dev.set_configuration()

ret = dev.ctrl_transfer(0x40, 0x6, 0x1, 0, [])
print ret

Command #3 & 4 – Let’s move!

import usb.core
import usb.util
import sys
import time

# find our device
dev = usb.core.find(idVendor=0x045e, idProduct=0x02B0)

# was it found?
if dev is None:
    raise ValueError('Device not found')

dev.set_configuration()

while True:
    # Get data from brequest 0x32
    ret = dev.ctrl_transfer(0xC0, 0x32, 0x0, 0x0, 10)
    print map(hex, ret)

import usb.core
import usb.util
import sys
import time
 

# find our device
dev = usb.core.find(idVendor=0x045e, idProduct=0x02B0)

# was it found?
if dev is None:
    raise ValueError('Device not found')

dev.set_configuration()

while True:
    # Get data from brequest 0x32
    ret = dev.ctrl_transfer(0xC0, 0x32, 0x0, 0x0, 10)
    #print map(hex, ret)

    x = (ret[2] << 8) | ret[3]
    x = (x + 2 ** 15) % 2**16 - 2**15     # convert to signed 16b
    y = (ret[4] << 8) | ret[5]
    y = (y + 2 ** 15) % 2**16 - 2**15     # convert to signed 16b
    z = (ret[6] << 8) | ret[7]
    z = (z + 2 ** 15) % 2**16 - 2**15     # convert to signed 16b

    print x, "\t", y, "\t", z

Via