New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New command #5

Open
timmeh87 opened this Issue Oct 20, 2017 · 5 comments

Comments

Projects
None yet
2 participants
@timmeh87
Copy link

timmeh87 commented Oct 20, 2017

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

This comment has been minimized.

Copy link
Author

timmeh87 commented Oct 21, 2017

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

This comment has been minimized.

Copy link
Author

timmeh87 commented Oct 21, 2017

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

This comment has been minimized.

Copy link
Owner

quantus commented Oct 22, 2017

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

This comment has been minimized.

Copy link
Author

timmeh87 commented Oct 23, 2017

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

This comment has been minimized.

Copy link
Owner

quantus commented Oct 24, 2017

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:

  • Fork this repo tutorial
  • Make commit (or multiple commits) to your repo. Commits contain the changes to the Readme.mb file. The easiest way of making the changes is to use the Github UI documentation
  • Use Github UI to create Pull request to this repo tutorial
  • I'll merge the Pull Request and your changes become visible in this repository

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment