working with xbox 360 protocal.

ulao
Site Admin
ulao
Site Admin
Joined: 8:39 AM - Apr 21, 2010

12:46 PM - Jul 11, 2014 #1

ok I found some helpfull info but links of this type seem to die fast... So ill post the text as well.

really helpful info about how the controller works.
http://www.xboxhacker.org/index.php?topic=18083.0
The following text is quoted from the forums from Super_TOB.

I found some information about the controller:

Site fonte: http://euc.jp/periphs/xbox-controller.ja.html

NOTE: this is for the original xbox

Vendor/Product IDs

The vendor ID is 0x045e (Microsoft). Product IDs are as follows:
ID product
0x001c integrated hub
0x0202 gamepad (American)
0x0280 memory unit
0x0284 DVD remote receiver
0x0285 gamepad (Japanese)

It is not recommended to distinguish Xbox gamepads by vendor/product IDs because third-party controllers may have their own vendor/product IDs.
Device Class

The gamepad has interface class 0x58 ('X'), subclass 0x42 ('B'), protocol 0x00. I believe this should be also common to third-party controllers, but I have no evidence. In fact the gamepad conforms to the HID class and behaves like a USB HID gamepad except that it lacks the HID descriptor and the HID report descriptor.

The memory unit has interface class 0x08 (mass storage), subclass 0x42 ('B'=???), protocol 0x50 (bulk-only). It seems to conform to the mass storage device class with bulk-only transport, though the "true" subclass must be revealed to access the unit.
HID Report Format
Input Report

The input report is 20-byte.
offset data
+0 0x00
+1 0x14 (size of the whole report)
+2 digital buttons
bit0 D-pad up
bit1 D-pad down
bit2 D-pad left
bit3 D-pad right
bit4 start button
bit5 back button
bit6 left stick press
bit7 right stick press
+3 0x00 (reserved for more digital buttons?)
+4 A button (*)
+5 B button (*)
+6 X button (*)
+7 Y button (*)
+8 black button (*)
+9 white button (*)
+10 L trigger (*)
+11 R trigger (*)
+12 left stick x (**)
+14 left stick y (**)
+16 right stick x (**)
+18 right stick y (**)

(*) unsigned 8-bit
(**) signed 16-bit, little-endian, north/east positive

Output Report

The output report (rumble control) is 6-byte.
offset data
+0 0x00
+1 0x06 (size of the whole report)
+2 0x00
+3 left actuator (*)
+4 0x00
+5 right actuator (*)

(*) unsigned 8-bit


New more information:

Site: http://www.free60.org/GamePad

NOTE: this is for the 360 xbox


The gamepad HID device

The gamepad is a regular USB HID device, but it has been crippled in a slight way:

The device uses the 0xff DeviceClass ('Vendor Specific') while normal HID devices use 0x03. Therefore normal HID drivers won't attach to it automatically. The device has no USB Report Descriptor, making the operating system unable to determine its device layout. Both problems are not hard to overcome; some operating systems (the BSDs for example) already override the USB Report Descriptors for some devices because they were shipped with broken ones.

A replacement report descriptor is available from the Free60 CVS repository. The layout of this descriptor is the same as the Windows driver, except that the big X button has been mapped to button 11. On Windows, it's unmapped.
Input report

Once in a while, a USB HID device sends back a so-called input report which contains all information about its current state. The length of the input report is the same as the original Xbox gamepad; 20 bytes.

Its button/trigger/pad/stick alignment is as listed below:

Offset Length (bits) Description Windows driver
0x00.0 8 Message type
0x01.0 8 Packet size (20 bytes = 0x14)
0x02.0 1 D-Pad up D-Pad up
0x02.1 1 D-Pad down D-Pad down
0x02.2 1 D-Pad left D-Pad left
0x02.3 1 D-pad right D-Pad right
0x02.4 1 Start button Button 8
0x02.5 1 Back button Button 7
0x02.6 1 Left stick press Button 9
0x02.7 1 Right stick press Button 10
0x03.0 1 Button LB Button 5
0x03.1 1 Button RB Button 6
0x03.2 1 Xbox logo button
0x03.3 1 Unused
0x03.4 1 Button A Button 1
0x03.5 1 Button B Button 2
0x03.6 1 Button X Button 3
0x03.7 1 Button Y Button 4
0x04.0 8 Left trigger Z-axis down
0x05.0 8 Right trigger Z-axis up
0x06.0 16 Left stick X-axis X-axis
0x08.0 16 Left stick Y-axis Y-axis
0x0a.0 16 Right stick X-axis X-turn
0x0c.0 16 Right stick Y-axis Y-turn
0x0e.0 48 Unused

All eight-bit values are unsigned. The 16-bit values are signed little-endian. The first byte (Message type) will be 0x01 for a LED status message and 0x00 for a normal input report message.
Output report
LED Control

Some control over the LEDs surrounding the XBox button is provided, corresponding to the markings 1, 2, 3 and 4. This is controlled using message type 0x01.

To select a new pattern for the LEDs, send a 3-byte packet of the following form:

0103XX

0x01 is the message type, 0x03 is the message length, and 0xXX is the desired pattern:

Pattern Description
0x00 All off
0x01 All blinking
0x02 1 flashes, then on
0x03 2 flashes, then on
0x04 3 flashes, then on
0x05 4 flashes, then on
0x06 1 on
0x07 2 on
0x08 3 on
0x09 4 on
0x0A Rotating (e.g. 1-2-4-3)
0x0B Blinking*
0x0C Slow blinking*
0x0D Alternating (e.g. 1+4-2+3), then back to previous*

The previous setting will be used for any itmes with * (all blinking, or 1, 2, 3 or 4 on).
Rumbler Control

Rumbling is also similar to on the original controller. Rumble commands take the following 8-byte form:

000800bbll000000

Where b is the speed to set the motor with the big weight, and l is the speed to set the small weight (0x00 to 0xFF in both cases).
The headset-port

Headset Port File:Headset port pinout.jpg Pinout for the headset port on the wired and wireless Xbox 360 controller Baud Rate: Unknown, Data 1: RX or TX, Data 2: RX or TX

A chatpad (mini-keyboard) for text entry can be plugged into this port.
The headset data protocol

FreeBSD ships with a driver called ugen(4) which is just a fallback driver for USB devices that do not have a matching driver. It allows you to read and write to the descriptors of the device. Descriptor 3 is used for the microphone. Descriptor 4 is the earpiece.

At this moment there isn't a lot of information available about the transfer protocol. The protocol for the microphone and the earpiece are the same, but the latter one uses half the sample rate of the first one. The following test shows this:

$ cat /dev/ugen0.3 > myvoice
# tell a funny joke to the microphone and press ^C
$ cat myvoice > /dev/ugen0.4
Playback will take twice as long.

The microphone emits 8000 bytes per second of 4 bits signed PCM, thus it's 16 KHz. The earpiece only consumes 4000 bytes, so it can only emit 8 KHz PCM (4 KHz sound at best).
lsusb output

Linux's lsusb utility tells us the following about the gamepad.

Bus 002 Device 003: ID 045e:028e Microsoft Corp.
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 255 Vendor Specific Subclass
bDeviceProtocol 255 Vendor Specific Protocol
bMaxPacketSize0 8
idVendor 0x045e Microsoft Corp.
idProduct 0x028e
bcdDevice 1.10
iManufacturer 1
iProduct 2
iSerial 3
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 153
bNumInterfaces 4
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 93
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 8
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 4
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 93
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 2
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 4
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 64
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 16
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 1
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 93
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0020 1x 32 bytes
bInterval 16
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 0
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 253
bInterfaceProtocol 19
iInterface 4
UNRECOGNIZED: 06 41 00 01 01 03
Quote
Like
Share

ulao
Site Admin
ulao
Site Admin
Joined: 8:39 AM - Apr 21, 2010

12:47 PM - Jul 11, 2014 #2

this guy shows how to crack the dongle but says he didn't try it.
http://brandonw.net/360bridge/doc.php
Xbox 360 Controller Security

The Xbox 360 employs a security mechanism that prevents people from just attaching any USB peripheral they want to it and using it. This means no aftermarket/third-party controllers, no USB keyboards/mice, and no automation of controller functions.
Devices like the XIM3 (Xbox Input Machine) get around this restriction by sitting in the middle of the console<->controller connection; it allows the security handshake to pass freely between console and controller, but sends its own button press events instead of the controller's.

This is an attempt to explain the protocol for that handshake.
Protocol Basics

I used a USB hardware analyzer to log the communication between console and controller from the moment it's plugged in. That log (slightly cleaned up) is available here, in Excel format.

I can't recall exactly which descriptors are necessary to include before the console will attempt to communicate with the device, so to be safe, it's best to duplicate everything from the real controller (as in the USB hardware analyzer log above). Interface descriptor 03 in the configuration descriptor is especially important; it references string descriptor 04, which is essentially "Xbox Security Method 3, Version 1.00, 2005 Microsoft Corporation. All rights reserved." It's critical to include this or the console will not attempt further communication.

The console requests "static data" from the controller, unique to that device and never seems to change. It uses this data to calculate two unique types of challenges, for which the controller must respond properly. If it does not, it's not considered a Microsoft approved peripheral and all communication ceases until the device is reconnected.

I have no clue how this response is supposed to be calculated, or the meaning of the data in any of the requests. That's the strength of this protection -- only a small handful of people have cracked open the security chip to see what it's actually doing with this data. All I know is that passing these requests through to a real controller is enough to fool the console.

After the console requests the static data, it sends "challenge 1", which the controller must calculate the correct response for. The console periodically checks for the status of this response, and when the controller returns that it's ready, the console reads it and validates it.

After "challenge 1", the console sends "challenge 2" -- and then tries sending another "challenge 2", which the controller STALLs on, and the console doesn't seem to care. The console tries sending it again, and the controller responds properly.
Commands

All of the following commands are standard device requests on the control endpoint. See the USB hardware analyzer log above for more details.

(0x81) Request Static Data
This is sent to request the "static data" from the controller, likely used to calculate unique challenges.
(0x82) Send Challenge 1
This sends the data for the first challenge to the controller. It's up to the controller to "calculate" the correct response.
(0x83) Get Response
This gets the challenge response back from the controller.
(0x84) Unknown (Challenge Successful)
I don't know what this is exactly, but it's sent when the response was correct. If the response wasn't correct, the console just stops communicating with the device.
(0x86) Get Response Status
This requests the current status of the response calculations. It's always two bytes; the first is 01 if still busy, and 02 if ready. The second byte is always 00.
(0x87) Send Challenge 2
This sends the data for the second challenge to the controller. It's up to the controller to "calculate" the correct response.

more info here on the security
http://www.mp3car.com/input-devices/108 ... rd-23.html

also this seem to be the host, but does not show the answered just how it sends it (looks like the same code on the link above).
http://brandonw.net/svn/x86stuff/salama ... troller.cs
this project makes the challenges I believe.
https://code.google.com/p/chatpad-super ... p&can=2&q=

a 360 protocol explained no security stuff
https://github.com/Grumbel/xboxdrv/blob/master/PROTOCOL
Quote
Like
Share

ulao
Site Admin
ulao
Site Admin
Joined: 8:39 AM - Apr 21, 2010

12:50 PM - Jul 11, 2014 #3

I also found this page on the wireless pad
http://tattiebogle.net/index.php/Projec ... essUsbInfo
too hard to quote.
Quote
Like
Share

ulao
Site Admin
ulao
Site Admin
Joined: 8:39 AM - Apr 21, 2010

12:51 PM - Jul 11, 2014 #4

Looks like I may be able to get rumble working from the consoles down to the controllers. I see the led controls for the 360 but only the dream cast has out put for that. That could be fun, an LCD representation of the 360 LEDS's.
Quote
Like
Share