xpad
xpad copied to clipboard
xone: Wireless Adapter - wifi protocol
@dodslaser
Bought an adapter yesterday and just hooked it up to my win10 laptop. The adapter loads three drivers; FW_ACC_00U.bin
(firmware I assume), xboxgip.sys
(no clue) and mt7612US.sys
(driver for the mediatek mt7612 wireless chip). So the controller must be communicating over 802.11b/g/n/ac right? And the controllers connect to the adapter like a hotspot? I don't have a linux box handy right now, but maybe sniffing the authentication with normal wifi tools, like aircrack-ng, might tell us something.
Edit: Searching FCC database for the FCC-ID (C3K 1713) yeilds a lot of information (Internal photos etc.). It is listed as capable of using the 5.2, 5.8 and 2.4 GHz bands. LINK
Edit 2: The test reports seem to confirm that the adapter is in fact just a WiFi adapter. Maybe we could even use other adapters if we are able to come up with a Linux driver?
Edit 3: This document claims that the wireless platform is proprietary, dual band and uses 5GHz (So 5.2 and 5.8 I assume) for communication. TDS_XboxOneControllerPlusWDAforWindows_1510A.pdf
@Almamu Looks like xboxgip.sys is the driver of the xbox controllers: http://batcmd.com/windows/10/services/xboxgip/
Remember that XBOX pads use wireless communication and not bluetooth so it makes sense to have that driver loaded for the wireless adapter.
I don't think we could use different adapters for this but it's worth trying, although i'm not knowledged in wifi adapters and linux drivers at all... I'm still trying to figure out how to interpret the usbcap captures with wireshark to understand the way windows and the adapter talk to each other and adding support for it on this driver...
@xdarklight mt76 is the open source driver for the MT76x2 family (which includes the MT7612). It's firmware looks suspiciously similar to what FW_ACC_00U.bin contains: https://github.com/openwrt/mt76/tree/master/firmware (I've compared it with mt7662_firmware_e3_v1.9.bin)
I'm not sure about the PHY layer details for the adapter, but the packets themselves seem pretty standard and not particularly difficult to map (though I haven't really begun in earnest, so who knows). I can write the code to do that mapping but I'm not familiar with the existing driver code and I'm a little confused. I understand the packet/input system, but am I reading it right that the 360 wireless input didn't need to be translated into the wired version's input? It seems like they both just pick up the packets and send them along with minimal changes, which I wouldn't expect -- but I've also only done this kind of thing for networking protocols where you do a lot of parsing.
+1 I just tried wiresharking the wireless packets between Xbox one controller and windows adapter, part of the protocols seem pretty straightforward though some other parts are not understood yet.
I've been working with this more and things are more complicated than I might have hoped.
- Windows recognizes the adapter and the controller as two distinct devices. It would assign a USB port registry to the adapter itself, and then when the controller linked in Windows created another device number for it. Fortunately it doesn't seem that Windows interacts very much with the adapter itself and the communication between the adapter and the controller seems to be transparent to the OS; all the OS sees are packets coming directly from the new controller device.
- The initial handshake between the controller and the OS seems to be very elaborate.
- Almost all communication between the controller and the OS happens in URB_BULK packets.
- From what I can tell, there is a LOT of polling taking place happening on the order of .1 second increments. The annoying thing is that there seems to be some kind of sequence number/timestamp included in the "nothing happening" packets (probably the "action" packets too) both to and from the controller, and the pattern is not immediately obvious to me. I'd assume that the exchange of these packets are needed to keep the link alive, however.
- There seem to be a few different types of "no action" packets, each with different lengths. I'm seeing 59 byte, 43 byte, and 51 byte packets most commonly, but the order/pattern is not obvious to me. Actions seem to be transmitted in packets around 110 bytes. There are occasional 1059 byte packets initiated by the OS that are mysterious to me.
I'll chime in on this: The wireless adapter really just seems to be a 5 GHz Wifi Dongle. With the dongle connected, I see traffic on 5 GHz channels, it seems to be hopping: first I saw traffic at channel 44, then at channel 48. So, if it really contains the mt7612 chip, I could simply force-bind the driver to the USB device. (I need to get and compile the driver first, it seems like it's somewhere in OpenWrt's repo).
After I paired the dongle and the controller, I observed the following:
- Packets were sent as long as the controller was connected to the dongle (i.e. power on and the X LED being on).
- Beacons were always sent. (as long as the dongle was plugged in)
In fact, the "pairing" could possibly be in WPS style. I'll go through the airodump-ng recordings and dump there here in a while.
Here are the Wifi dumps for any actions on the controller: http://dl.devkid.net/uNqiOXi32H2Ul-_pEZtUHw/xbone-wireless.tgz (including powering on the controller (connecting to the dongle), any button presses (I forgot analog stick presses), and powering off the controller (disconnecting from the dongle)).
During this second testing, the devices didn't hop channels, they stayed on channel 36. airodump-ng displayed WEP as encryption, but that might be a bug (it displayed also "-1" as channel number although I configured it to use channel 36).
Hex representation of packets sent for button A:
- pressed:
8811-a000-6245b4f44151-7eed801f6d53-6245b4f44151-1000-0000 --- 2000-02-0e-1000-0000-0000-4f039c02-b4ff26ff
- released:
8811-a000-6245b4f44151-7eed801f6d53-6245b4f44151-2000-0000 --- 2000-03-0e-0000-0000-0000-4f039c02-b4ff26ff
Taking apart the Wifi headers:
-
8811
is the "Frame Control Field" (0x88 QoS Data, 0x11 flags: Station (Controller) to DS (Dongle), Station (Controller) will go to sleep) -
a000
is the transmit duration ID -
6245b4f44151
is the MAC address of my dongle (that's probably the changing part people keep seeing in the USB dumps) -
7eed801f6d53
is the the MAC address of my controller -
1000
and2000
is the Wifi fragment / sequence number (in this case: fragment always 0x0 (last 4 bits), sequence number counting (the first 12 bits) in Little Endian) -
0000
is the Wifi QoS status flags
Taking apart the actual data part:
- bytes 0-1: constant
0x2000
- byte 2: 8-bit counter, equals the LSBs of the sequence number+1
- byte 3: constant
0x0e
- bytes 4-5: button map, where the bits equal: (counted from MSB to LSB; 1 = pressed, 0 = released)
- 0: Y
- 1: X
- 2: B
- 3: A
- 4: left buton
- 5: right button
- 7-8: unknown
- 8: right analog stick pressing
- 9: left analog stick pressing
- 10: RB
- 11: LB
- 12: DPAD right
- 13: DPAD left
- 14: DPAD down
- 15: DPAD up
- bytes 6-7: LT position
- bytes 8-9: RT position
- bytes 10-13: left analog stick position
- bytes 14-17: right analog stick position
The XBox button produces another pattern for the part after the fragment / sequence number:
- pressed:
0100-0720-03-02-01-5b
- released:
0100-0720-04-02-00-5b
- QoS: (little endian) LSB is set -> "background"
- constant
0x0720
- same 8-bit counter as above
- constant
0x02
- state byte:
- bits 0-6: seem to be constant zero
- bit 7: state of the button (0 = released, 1 = pressed)
- constant
0x5b
Apart from those messages for the actions, the dongle is constantly sending out beacons (like every WiFi access point does). I didn't see any difference when pressing the pairing button on the dongle, so I think it actually just allows one new device to connect when you enable the pairing mode by pressing the button.
For the connecting process, there seems to be a standard association request / response (with the response having a non-standard status code (0x0110
)). Every single frame is acknowledged by a standard ACK packet. After connecting, there are probe requests / responses with a M$ vendor specific tag parameter.
When connected, the controller and the dongle exchange further packets continously ("QoS null function"), with the following frame control field:
- dongle to controller:
c802
(0x02 flags: DS (Dongle) to Station (Controller)) - controller to dongle:
c815
(0x15 flags: Station (Controller) to DS (Dongle), Station (Controller) will go to sleep, more fragmens to follow (which doesn't make sense as there don't follow any fragments))
Guys, please stop me here, if someone has already deciphered this :)
On Windows, the driver seems to write out raw 802.11 MAC frames over the USB connection. That means that it should indeed be possible to use any 5 GHz module that has SoftMAC. I'm on it.
I managed to get this driver to compile on a Ubuntu 12.10 with Linux 3.5. I changed the first entry in rtusb_dev_id[]
at common/rtusb_dev_id.c
to the USB vendor and product ID of the original dongle (045e:02e6) and got a wlan1
interfaces when I plugged in the dongle, but I couldn't get it up with ip link set wlan1 up
(Operation not permitted) and when I unplugged it, the kernel paniced.
I think using this driver directly wouldn't be of much use as it doesn't seem to implement mac80211 anyways. But maybe some initialization steps could be used from the code.
@devkid it's probably a lot of work but one could try adding USB support to Felix' mt76 driver. not sure how many differences there are between USB and PCIe devices, but Felix is a nice guy and will probably share his thoughts if you ask him about adding MT7612 USB support to mt76.
@xdarklight Thanks for the link! Who is Felix? nbd186?
FYI: I have now finally managed to output some 802.11 frames on 5240 MHz on my ThinkPad laptop after fiddling around for hours (after I actually got it working on 2.4 GHz! – but no errors on 5 GHz, just nothing going over the air). This laptop has an Intel Wireless 7260 card (but this may as well affect other wireless devices, too). If you have a look at the output of iw phy
, there might be a flag "no IR" (no Initiating Radiation) for all 5 GHz frequencies. That means that you cannot send beacon frames (amongst other frame types) on those frequency. Even changing the regulation domain with iw reg set DE|US
didn't help. The solution was to recompile the iwlwifi
driver and remove every line which set the IEEE80211_CHAN_NO_IR
flag for the channels; this might even help for other drivers that implement mac80211.
I'm now going to implement the protocol for the pairing, connecting and data exchange in userland. This will probably make for an ok'ish driver until we get to figure out the MT7612U driver.
I have pasted the analysis of everything I've figured out about the protocol here. Maybe someone has enough muse to decipher those mysterious reserved frames or status messages :)
Hello everyone.
I want to work on this issue. Recently, I purchased Xbox One Elite controller and I'm planning to do my research using some ath9k USB dongles.
My question is: is there any available information(i.e. 802.11 packet capture) about pairing stage?
If anyone just wants to use this controller wirelessly on Linux in any way possible, I've found the ConsoleTuner Titan 2 device supports this. The device acts as an input translator and has its own firmware to use the wireless adapter.
With all you guys’ amazing research and work here and elsewhere on the «XBox wireless» protocol on the XBox adapter and controllers, did you ever find out how to monitor and inject a wifi device with the controller’s sequence to power on the XBox One from energy-saving mode? (PSU is really loud and draining 15W in instant-on mode...).
If so, would it be possible to get a peek? If not, do you think it would be possible to achieve with
https://github.com/seemoo-lab/nexmon on the Raspberry Pi, with internal or a capable USB wifi adapter?
Is it possible for the xbox one controller to be forced to connect to win10 via the home WiFi as opposed to using the dongle?
someone can try this dongle and use xbox wireless adapter drivers? maybe it can be work https://edup.en.alibaba.com/product/60623990718-803973115/MT7612_wireless_usb_wifi_adapter_1200mbps_usb_wifi_dongle.html