search

quantus / xbox-one-controller-protocol

Xbox One Controller Protocol description
177 stars 17 forks source link

New command #5

Open timmeh87 opened 6 years ago

timmeh87 commented 6 years ago

I wanted to try to control the LED on the xbox controller so I did a little poking around...

The Window Xinput driver sends this command, which makes the LED a little dimmer than the maximum:

0a 20 04 03 00 01 14

Im sure its doing more than just the LED, but anyways I got what I wanted in 4 tries.

0a 20 04 00 00 01 14 - led appears to be max brighness 0a 20 04 02 00 01 14 - a little dimmer, possibly the same as 03, or maybe a little different 0a 20 04 01 00 01 14 - led off

this is on an older controller with no headphone jack. PID: 2d1h VID: 45eh Address (#1) assigned. Manufacturer : Microsoft Product : Controller Serial Number : 7EED8E29D8E9

timmeh87 commented 6 years ago

After more poking around the command format is actually found to be at least this

0a 20 <- led command 04 <- packet length? 03 <- num led values? xx <- zero? xx <- 1? xx <- led brightness 0 - 20

fuzzing of random values accidentally activated several flash patterns too so there is more to be found some bad commands seem totally break the operation of the LED and need a reboot

timmeh87 commented 6 years ago

This is as far as I am going to go, this is how I am using it

0a 20 <- led command 04 <- always 4 03 <- always 3 xx <- always 0 xx <- command xx <- led brightness 0 - 20

       //0000 0000 //00 off? (can also do solid, brightness zero in case this is just broken)
    //0000 0001 //01 solid
    //0000 0010 //02 blink fast on-off
    //0000 0011 //03 blink slow on-off
    //0000 0100 //04 blink painfully slow on-off
    //0000 0101 //05 solid ?
    //0000 0110 //06 solid ?
    //0000 0111 //07 solid ?
    //0000 1000 //08 phase slow
    //0000 1001 //09 phast fast
    //0000 1010 //0a reboot device
    //0000 1011 //0b off
    //0000 1100 //0c flicker (phase insanely fast?)
    //0000 1101 //0d solid?
    //0000 1110 //0e solid?
    //0000 1111 //0f reboot device
quantus commented 6 years ago

Nice job figuring all that out! It's always nice to see people doing something similar I did. If you create a pull request with that information I'll happily merge it.

How did you find out what messages the Xinput driver is sending to the controller? I think some kind of USB sniffer might be able to record those messages, but are there also some software only ways of getting that information?

timmeh87 commented 6 years ago

In order to create a pull request I have to fist check out this github to my own account or something right? Im pretty new to this github thing

I have been using both wireshark+usbpcap and "microsoft message analyzer". Each has pros and cons. I prefer wireshark's interface but MMA provides about 10 times more information. This is all under windows of course. I think wireshark natively supports usb capture under linux.

Also after watching the packets for a while, I would suggest (but im not positive) that the 01 message is either a command, or an ACK/response, or both. The 4th byte is total packet length (as it is for all packets) and the 6th byte is always the first byte of a nearby packet.

For example

01 02 02 09 00 06 20 0e 00 00 00 00 00 
               ^^    ^^
            type     some kind of  length (of prev/next 06 packet)

will always be near a packet that starts with

06 xx xx .....

where 06 is the command byte. Im not positive what 06 is. There is a long stream (maybe 30?) of 06 commands (of 64 bytes each) during handshaking that might be memory reads or something (there seems to be a small amount of text in one ). u there is also 1e. The host sends "1e 30 05 01 00" at the end of handshaking and then the controller replies with its own "1e" and then an "01... 1e". No idea what it is.

The only thing that leaves during init is the 0a command. This command is not replied to and I focused on that.

quantus commented 6 years ago

Thanks for the reply, it's nice to know what tools can be used if I decide to continue reverse-engineering the protocol. I want to test out how those tools work, but don't have the time to do it now.

The Pull Request process goes like this:

Just ask if anything is unclear. Also don't worry too much about even if you are not sure about some packets. Your guess is as good as anyones and we can always improve the information later on.