CiA121

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)

MP3Car.com

 

Grumbel

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.

Grumbel

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 }

dwomac

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.

Grumbel

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

dwomac

Grumbel: Nice with some more logs. Couple with your chatpad attach log and recent discoveries I think this could be more of a USB related problem than a protocol problem...

I've been able to receive 1 key press then it's dead. This is the first USB device I'm coding for so I might be missing something. I'm gonna try to code a kernel mode driver this weekend and see if I can track down the problem better there.

EP 6 <0x00 XX XX XX XX>:

2nd byte flags:
shift/capslock = 0x01
square = 0x02
circle = 0x04
people = 0x08


3rd byte keycodes:
1 = 0x17
2 = 0x16
3 = 0x15
4 = 0x14
5 = 0x13
6 = 0x12
7 = 0x11
8 = 0x67
9 = 0x66
0 = 0x65

q = 0x27
w = 0x26
e = 0x25
r = 0x24
t = 0x23
y = 0x22
u = 0x21
i = 0x76
o = 0x75
p = 0x64

a = 0x37
s = 0x36
d = 0x35
f = 0x34
g = 0x33
h = 0x32
j = 0x31
k = 0x77
l = 0x72
, = 0x62

z = 0x46
x = 0x45
c = 0x44
v = 0x43
b = 0x42
n = 0x41
m = 0x52
. = 0x53
enter = 0x63

left arrow = 0x55
space = 0x54
right arrow = 0x51
backspace = 0x71

4th byte: 2nd key down?
5th byte: 3rd key down?


The keycodes are a bit wierd I guess but it seems to be confirmed by the qqwweerrttyy logs.


EP6 <0xF0 XX XX XX XX>:
3rd byte is a flag/status byte for which keys are lit:
people = 0x01
square = 0x08
circle = 0x10
capslock = 0x20
backlight on = 0x80

I have to go to bed now.. damn work! But seems like hope is still alive to get the chatpad to work

Grumbel

Same here. Do you do it via this?

ctrl 0x41 0x0 0x1f 0x02
ctrl 0x41 0x0 0x5b 0x02

Another thing I noticed is that normally the pad will completly die (LED goes out) when sending:

ctrl 0x41 0x0 0x1e 0x02;wait 1.0 # 2
ctrl 0x41 0x0 0x1f 0x02;wait 1.0 # 3
ctrl 0x41 0x0 0x1e 0x02;wait 1.0 # 4
ctrl 0x41 0x0 0x1f 0x02;wait 1.0 # 5
...

like seen in the logs. But when I init the pad with the above it will continue to live, it won't send any more keys then the first, but buttons events are still answered and the LED continues to be lit.

dwomac

Yeah, seems about the same way. I was gonna post how I did it but then I noticed there's several ways todo it.

But basicly from a newly connected controller you need to send 0x1F and 0x1B, order doesn't matter it seems. After that you can reset the controller from software and only send 0x1B to get the keypress. You can also use 0x1E instead of 0x1F i think.

Edit: Removed for function stuff for now, the other bits does something

Other stuff I've noticed about EP6 0xF0 is that if you reset the controller the 4th and 5th byte changes. Don't understand why, it seems pretty random and once in a blue moon i get the 2nd byte to be 0x04. Where in the log it's time to send ctrl 0x00/0x18. I think this might be related to why a keypress can get through, it's just a matter of what you send after resetting the device.

Edit: EP6 0xF0's 4th and 5th byte is incrementing each time you send 1F or 1E, and resets back to 0 after 0x0F. Sometimes sending multiple 0x1F and 0x1E without reading from EP6 doesn't increment it though. Not sure how that works... maybe if you read from ep6 once it will continue to increment it even though you don't read anymore after that.


I'm still clinging onto libusb, I have VMWare Workstation so kernel mode development isn't that much of a pita but still pretty annoying turn around time while testing (on Windows). But if I want to get any further to make sure it isn't an USB related problem I guess I have to go there.

MP3Car.com

 

jeduars

hey guys just wondering if there's still interest in this... i found a software only usb analyzer that has a fully functional trial I've been poking around and seems it could be useful for debugging as it also has the information from the system controller etc.. anyway hope it's useful in some kind as i still haven't lost hope of finding or coding a driver for this thing!


http://www.usblyzer.com/

Grumbel

The trouble is that Microsoft doesn't support the Chatpad on Windows, so you can't really find out much with it.

jeduars

well i know it's not supported but i was thinking there might be a way to kinda hack the protocol out of traffic being sent on chatpad key presses and then recode a HID driver with the keys accesible to the OS...... so far i hooked it to windows with the microsoft drivers and I apparently DO get some packets sent whenever i press something on the keyboard... unfortunately I haven't had the chance to look more into that and make sure i'm not seeing at something else...

xrs

Hi, I haven't followed the whole post, so please don't shoot me.
From my understanding within my own research, is that the firmware within the chatpad is the main issue. The chatpad state is dictated via commands sent from the xbox. So its state needs to be changed before it will properly send outputs, but even then I don’t think it’s really outputs, but interrupts?
Really I think someone needs the USB protocol analyser and the XBOX360 XNA Kit.

Send the KeyboardState GetState command from the Xbox360 to the controller, log that.

Send (newState.IsKeyDown(Keys.Space)) //---- change Keys.Space to the keys listed above.

Again I really do apologies if I’m just repeating what has already been discovered or discussed. I hate to make extra noise.
I myself am just really eager to find a solution.

http://a3w.ivory.ne.jp/softwares/xpcc_en.html
http://msdn.microsoft.com/en-us/library/bb975640.aspx
http://msdn.microsoft.com/en-us/library/bb203902.aspx

Happy Hunting

Grumbel

No, the main issue right now is simply that the chatpad stops sending stuff after the first two responses. We can get the chatpad inited, change its LEDs and read a single keypress from it, but after that its dead (see a few posts above for init code).

This is archived in Linux with libusb, it might very well be just a fluke in libusb or my lack of USB knowledge that is causing this and nothing related to the chatpad itself. So it would be helpful if somebody tries to send data on a different OS or via a kernel driver on Linux to see if that changes anything.

mystkrh

Hey Grumbel any chance i can get a copy of that code from you? I just picked up one of these chatpads and I'de really like to get it to work on the Pc. I've looked over the ubs captures and have a few ideas, but i want to see what you have done.

Grumbel

I haven't written anything for the chatpad itself, I did use a little Linux tool I wrote called usbdebug that is part of xboxdrv, available via git with:

git clone http://pingus.seul.org/~grumbel/xboxdrv.git

With that tool I can send messages to usb devices, to read a keyboard its then just a matter of:

% ./usbdebug 045e:028e
usb> claim 0 1 2 3
usb> listen 5 6 1
usb> ctrl 0x41 0x0 0x1f 0x02
>>> Ep1: [3] { 0x08, 0x03, 0x01 }
usb> ctrl 0x41 0x0 0x5b 0x02
usb> ctrl 0x41 0x0 0x5b 0x02
>>> Ep6: [5] { 0x00, 0x00, 0x33, 0x00, 0x00 } // thats the keypress

After that last line of course the chatpad refuses to send anything more, which is where I am stuck at.

All the LED codes are listed in one of my previous posts.

MP3Car.com