Thread: xbox360 chatpad, awsome backlit mini keyboard

Got some Questions who helps a little if answered:

Does the X360 controller operate like a HID device when it's connected to a X360 video game? or it's have a "closed-source" way of communicate?

Can the controller see the difference between a Computer and a Video-game USB connection? Does the video-game send some "extra info" that is unsent when it is controlled by Windows' Microsoft drivers?

Maybe the key to get the Chatpad working is to see the controller -> "Host Device" communication, not the Chatpad -> controller one.

redCl0ud posted some drivers for Xbox and X360 controllers, maybe we can mod his work to load the Chatpad.

Originally Posted by CiA121

Does the X360 controller operate like a HID device when it's connected to a X360 video game? or it's have a "closed-source" way of communicate?

It's own protocol

Maybe the key to get the Chatpad working is to see the controller -> "Host Device" communication, not the Chatpad -> controller one.

If I'm reading you right, no it piggy-backs on the controller's protocol.

can someone tried else to use the controller with "XBCD drivers"?
there is a debug version lying around, maybe it will be useful to get some more info about "Controller -> Host" communication.

maybe if we find RedCl0ud, he can help. he coded this driver.

EDIT: i just noticed he coded a driver for the original xBox headset too.

So, someone hacked the Chatpad to work on the PSP. Anyone see this: http://www.acidmods.com/forum/index....1501#msg171501

He's using a custom firmware for chatpad.

Here is the PS2Dev thread:
http://forums.ps2dev.org/viewtopic.p...hlight=chatpad

they have the source and a driver (maybe for psp)

Originally Posted by Grumbel

Finding somebody who has a USB protocol analyzer and can snoop the communication between Xbox360 and gamepad would be helpful.

Some good news, I have found somebody who has a USB protocol analyzer and who send me a trace of the initialization of the controller with a Xbox360. The data shows pluggin in the controller and then typing qqqwwweeerrrtttyyy, its available at the url below, software to view it in the second link:

http://pingus.seul.org/~grumbel/tmp/...r_with_pad.zip
http://www.ellisys.com/products/usbex200/download.php

I haven't yet figured out how to get the controller to send data, but I have managed to turn the controller backlight on. Sending:

usb_control_msg(handle, 0x41, 0x0, 0x1f, 0x02, 0, 0, 0);
usb_control_msg(handle, 0x41 0x0 0x1b 0x02, 0, 0, 0);

And then pressing a key turns the backlight on.

From the output its also clear that the chatpad data comes out of endpoint 6 and it seems easy enough to decode, how to get the chatpad to start sending that data is still unsolved, any help welcome.

I found somebody with a USB protocol analyzer who managed to send me USB caputure data. So far I figured out how to light the backlight on the chatpad along with the LEDs under capslock, square, circle, etc. Below is a list of USB messages that one can send to the controller, messages are in the form:

ctrl REQUESTTYPE REQUEST VALUE INDEX

The most important message seems to be:

ctrl 0x41 0x0 0x1f 0x02 # Init (without this, no led wil work)

Without that, most other won't work. Some messages trigger a response on Endpoint 6, not sure what exactly they are good for, sending them multiple times causes the controller to 'crash'. I havn't managed to get keypresses so far, which according to the USB trace should also come in on Endpoint 6.

ctrl 0x41 0x0 0x8 0x02 # capslock
ctrl 0x41 0x0 0x9 0x02 # square
ctrl 0x41 0x0 0xa 0x02 # circle
ctrl 0x41 0x0 0xb 0x02 # people
ctrl 0x41 0x0 0xc 0x02 # backlight
ctrl 0x41 0x0 0x11 0x02 # capslock
ctrl 0x41 0x0 0x12 0x02 # square
ctrl 0x41 0x0 0x13 0x02 # square and capslock
ctrl 0x41 0x0 0x14 0x02 # circle
ctrl 0x41 0x0 0x15 0x02 # capslock and circle
ctrl 0x41 0x0 0x16 0x02 # circle, square
ctrl 0x41 0x0 0x17 0x02 # circle, square, capslock
ctrl 0x41 0x0 0x1b 0x02 # makes led go on on keypress
ctrl 0x41 0x0 0x1e 0x02 # Init2 >>> Ep6: [5] { 0xf0, 0x03, 0x00, 0x01, 0x01 }
ctrl 0x41 0x0 0x1f 0x02 # Init (without this, no led wil work)
ctrl 0x41 0x0 0x3a 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0x3b 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0x3c 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0x3d 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0x3e 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0x3f 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0x48 0x02 # capslock
ctrl 0x41 0x0 0x49 0x02 # square
ctrl 0x41 0x0 0x4a 0x02 # circle
ctrl 0x41 0x0 0x4b 0x02 # people
ctrl 0x41 0x0 0x4c 0x02 # backlight
ctrl 0x41 0x0 0x51 0x02 # capslock
ctrl 0x41 0x0 0x52 0x02 # square
ctrl 0x41 0x0 0x53 0x02 # capslock & square
ctrl 0x41 0x0 0x54 0x02 # circle
ctrl 0x41 0x0 0x55 0x02 # capslock & circle
ctrl 0x41 0x0 0x56 0x02 # square & circle
ctrl 0x41 0x0 0x57 0x02 # capslock & circle & square
ctrl 0x41 0x0 0x58 0x02 >>> Ep6: [5] { 0x01, 0x01, 0x01, 0x10, 0x01 }
ctrl 0x41 0x0 0x5b 0x02 >>> Ep6: [5] { 0x00, 0x00, 0x33, 0x34, 0x00 }
ctrl 0x41 0x0 0x75 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x00 }
ctrl 0x41 0x0 0x76 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x00 }
ctrl 0x41 0x0 0x77 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x9a }
ctrl 0x41 0x0 0x78 0x02 # kill
ctrl 0x41 0x0 0x79 0x02 # kill
ctrl 0x41 0x0 0x9f 0x02 >>> Ep6: [5] { 0xf0, 0x03, 0x00, 0x01, 0x01 } >>> Ep1: [3] { 0x08, 0x03, 0x01 }
ctrl 0x41 0x0 0xb0 0x02 >>> Ep6: [5] { 0x04, 0x20, 0x01, 0x01, 0x10 }
ctrl 0x41 0x0 0xb1 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x00 }
ctrl 0x41 0x0 0xb2 0x02 >>> Ep6: [5] { 0x04, 0x01, 0x0a, 0x7f, 0x7f }
ctrl 0x41 0x0 0xb3 0x02 >>> Ep6: [5] { 0x04, 0x04, 0x02, 0x23, 0x02 }
ctrl 0x41 0x0 0xb4 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x00 }
ctrl 0x41 0x0 0xb5 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x00 }
ctrl 0x41 0x0 0xb6 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x00 }
ctrl 0x41 0x0 0xb7 0x02 >>> Ep6: [5] { 0x04, 0x00, 0x00, 0x00, 0x9a }
ctrl 0x41 0x0 0xb8 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0xb9 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0xba 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0xbb 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0xbc 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0xc8 0x02 # capslock
ctrl 0x41 0x0 0xc9 0x02 # square
ctrl 0x41 0x0 0xca 0x02 # circle
ctrl 0x41 0x0 0xcb 0x02 # people & circle
ctrl 0x41 0x0 0xcc 0x02 # backlight
ctrl 0x41 0x0 0xd1 0x02 # capslock
ctrl 0x41 0x0 0xd2 0x02 # square
ctrl 0x41 0x0 0xd3 0x02 # square & capslock
ctrl 0x41 0x0 0xd4 0x02 # circle
ctrl 0x41 0x0 0xd5 0x02 # circle capslock
ctrl 0x41 0x0 0xd6 0x02 # square & circle
ctrl 0x41 0x0 0xd7 0x02 # square & ctrl & capslock
ctrl 0x41 0x0 0xd8 0x02 >>> Ep6: [5] { 0x01, 0x01, 0x01, 0x10, 0x01 }
ctrl 0x41 0x0 0xfe 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }
ctrl 0x41 0x0 0xff 0x02 >>> Ep6: [5] { 0xff, 0x01, 0x00, 0x10, 0x00 }

Grumbel: Awesome, nice to get the chatpad todo something atleast. Any chance you can get your hands on some more logs? Maybe with another controller? Anyways my guess to get the chatpad to work the initial message sequences must be done. And probably what enables it is the 0xA1 request. But it's too early to tell really, need more data.

Edit: Have you been able to receive any other data than { 0xf0, 0x03, 0x00, 0x01, 0x01 } from EP 6? I've seen Ep6: [5] { 0xf0, 0x03, 0x00, 0x02, 0x02 } but I havn't been able to reproduce it.

I've been trying a straight forward replication of the log.
It produces unexpected result at the 4th 0x86 request and third 0xA1 and fails on the 2nd 0x83.

This will all be pretty confusing for someone who hasn't studied the log but maybe it will help someone...

Concerning 0x81, 0x82, 0x83 and 0x87 requests I've been able to figure out some minor stuff, they go like this:
4 bytes - unknown but it's constant, could be id or something
1 byte - length
XX bytes - data
1 byte - crc check (XOR of all the bytes in 'data')
I'll call this structure a "packet".

- Vendor Request IN 0x81:
Log:
49 4B 00 00 17 E7 D9 1D 50 02 20 85 55 21 01 33
00 00 80 02 5E 04 8E 02 03 00 01 01 C5

My pad:
49 4B 00 00 17 77 66 1E 54 11 0B B0 27 02 03 20
00 00 80 02 5E 04 8E 02 03 00 01 01 A0

xx xx xx xx ll ?? ?? ?? ?? ?? ?? ?? ?? ?? ?? ??
xx xx xx xx xx xx xx xx xx xx xx xx cc

xx = the same on both
?? = not the same..
ll = length of bytes to follow
cc = crc byte

This message is always the same, doesn't matter if chatpad is plugged in or not.

- Vendor request OUT 0x82:
Log:
09 40 00 00 1C DC A6 B3 EF 84 3A 2C 8C B6 57 CC
09 C7 5E 2F 1B 64 58 19 C6 48 ED 45 37 B7 B5 61
AA 4C

Not much to say about this one, sending it seems to produce the wanted result from 0x86. Might be something that identifies the host.

- Vendor request IN 0x83:
Log 1:
49 4C 00 00 28 BD 38 66 10 B1 3A 9F CD EB 36 15
65 0E 01 F7 7E B1 31 AA 80 AD FA 71 3B D1 3D DD
37 80 9B E7 38 67 1F 10 DA 9C 76 52 4B 35
Log 2:
49 4C 00 00 10 C8 1A 5C D1 A3 17 E9 B2 5C B1 F9
20 1D 14 E6 4E 25

I'll explain this more further down but the first one seems to be 40 random bytes and the 2nd one seems to be 16 bytes result, maybe MD5 hash?

- Vendor request OUT 0x84:
Doesn't have any data other than Value=0x03 and Index=0x0103 in the request


- Vendor request IN 0x86:
Log:
First and third: 01 00
2nd and 4th: 02 00

Seen: 03 00 and 00 00

This seems to be a status/result message for 0x82 and 0x87. 01 00 seems to mean "not ready", 02 00; success, 03 00; failed, after 03 00 is received you will get 00 00 if you try it again, i guess it means you are now blocked from authenticating.


- Vendor request OUT 0x87
Log:
09 41 00 00 10 BB 4D 42 A3 40 63 24 26 D8 10 06
54 47 B2 2F F7 81

This message is sent after the first 0x83 and has 16 bytes of data like the 2nd 0x83, again might be some hash, maybe MD5.

--------------------------------------------
After the configuration is done and the "xbox security method 3" string is retrieved there are 2 sequences of authentication/handshakes

The first sequence:
IN 0x81
OUT 0x82
IN 0x86
Sleep 300ms
IN 0x86

I believe this sequence is a handshake and setup for the next sequence.
In the log it shows 100ms delay between the two 0x86 requests but it would give me 01 00 both times with anything less than 300, adding the 300ms delay produced the expected 02 00 result on the 2nd 0x86.


The second sequence:
IN 0x83
OUT 0x84
OUT 0x87
IN 0x86
(Again Sleep 300ms makes this get other results than 01 00)
IN 0x86 (here is where i get 03 00 instead of 02 00)

This sequence seems to be the "proof" sequence of the authentication. Proving that the host is an Xbox360. 0x83 containing a packet with 40 random bytes and 0x87 containing a packet with 16 bytes which probably is a hash.

After the proof sequence another IN 0x83 request is made which returns a packet structure with 16 bytes of data, I'm assuming this is the device's proof.

I havn't been able to get this second 0x83 to work so that's why I've drawn these conclusions about the messages and the OUT 0x82, OUT 0x84, OUT 0x87 requests all have the "value" part set to 0x03 which I'm guessing refers to security method 3, the only other value i've found that they work with is 0x00.


After these 2 sequences a 0x01 request is made which returns 4 bytes that is always the same but different on my controller.

Then 3 OUT 0xA9 requests are attempted with different 'value' and 'index' values that fails and it starts to receive data from endpoint 1 and initializing the led etc.

After that an IN 0xA1 request is made which returns 01 00
then OUT 0xA1 with 01 02
then IN 0xA1 which returns 01 02, this could be what enables the chatpad to send keystrokes.

For me when i send OUT 0xA1 01 02 then IN 0xA1 i get back 01 00, I havn't investigated this much and I've kinda stopped working on it atm.

Edit: Forgot to mention that most of these requests must be done in the right order to get them to work, for example 0x83 won't work unless you successfully complete the first sequence.

Well this became a long *** post...
Personally I don't think it will be possible to figure this out on logs alone and this "Xbox security method" is probably the reason why Microsoft hasn't released chatpad drivers for Windows.

Originally Posted by dwomac

Any chance you can get your hands on some more logs?

I received some more logs (not just chatpad, but also other stuff):

1. File with real gameplay for some time. So rumble voice etc. (large)
2. One with just one key (right trigger) and rumble.
3. keyboard attached "live" and qwerty written and then detached.
4. Headset attached to chatpad and test sound recorded and played. Then
detached.
5. Headset attached to controller and test sound recorded and played. Then
detached.

http://pingus.seul.org/~grumbel/tmp/...2008-09-30.zip