Skip to content
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

Xbox One Drums #4

Open
artman41 opened this issue Aug 10, 2019 · 1 comment
Open

Xbox One Drums #4

artman41 opened this issue Aug 10, 2019 · 1 comment
Labels
enhancement New feature or request help wanted Extra attention is needed

Comments

@artman41
Copy link
Owner

artman41 commented Aug 10, 2019

Background Info

Why doesn't it just work?

Basically, the ps4 rb4 stuff works off bluetooth; totally insecure and works perfectly without doing anything 9/10 times. Our issue is that the Xbox One stuff uses the Xbox One Wireless Adapter which is a Proprietary 801.1 Wireless Adapter to connect to the pc.

If you look in the Xbox app, you may find that the rb4 Xbox stuff already appears to be supported (this is just a clever bit of work on Microsoft's part).

The rb4 Xbox stuff works by appearing to the system as usb hid devices - they aren't actually recognised as usb devices per say, the best description would be like a tv remote, so they'll navigate menus in supported apps, but that's about it.

So what do we do?

The basic idea is that, at the lowest level, it's a Wireless Adapter - we just can't interface with it like a Wireless Adapter since it's Proprietary.

So, with that in mind, we can see that the Packets must be coming into the system somehow; it's usb right?

There must be a way of seeing the Packets coming in.

This is where Wireshark comes in; we use a combination of WinPCap, the windows binding for the PCap library (Packet Capture), and USBPCap which allows us to capture USB Packets and we 'sniff' the USB Adapter (see here for what sniffing is).

Great, we can see the Packets, now what?

This basically leaves us at a point where we can see the Packets coming in but we have no idea what they map to.

It was at this point that I started triggering all the inputs available to me and logging the Packets I received on both the press & release, resulting a spreadsheet documenting each input and what I thought it mapped to on that byte of the Packet , leading me to understand 3 things;

  1. There is ~20+ bytes on a header
  2. A Packet containing data is 40 bytes long (for the rb4 guitar)
  3. Which parts of the Packet are useable data and what they correlate to

From that, it was to write it in such a way that it was fast to action. I went through 3 stages with this process;

  1. C#
    • This one was too slow though, took at least 200ms to action
  2. Erlang
    • This one was nice and fast but the windows support was lacking and was impossible for people to use portably
  3. Golang
    • This one is perfect; fast, compiles to a single binary, easy to write and read & very good performance wise + allows for C bindings through cgo

Development Requirements

  • Golang
    • a GCC Compiler for the cgo stuff
  • Wireshark
  • WinPCap
  • USBPCap

Basic Idea

This is the basic idea of USB Packet capture & it'll show you the basics of using Wireshark.

All the Packets will be in hex when you use Wireshark and that's how I treat them in golang too since I don't like random bytes (0xFF looks better to me than 255).

First, you'll want to log as many Packets of duplicate actions as you can; you'll want to Packet dump the activation of something, waiting a couple seconds then repeating multiple times to produce a folder of Packets similar to this one.

Second, you will want to filter out Packets that are obviously outliers - (i.e there might be a ping Packet in there that you caught - some will be obvious since the Packet will be a different length).

Thirdly, you'll want to document your findings in a spreadsheet.

NOTE: Some Packets may be duplicated and some may randomly change. Here's some info from my experience that may be the same for when you try;

  • The first X duplicate bytes are the Packet header.
  • Randomly changing bytes that only increment appear to be correlation bytes to guarantee that the Packet comes after the prior one.
  • Any repeated duplicate patterns, (i.e a byte in the Packet is 0x00 & 0x01) typically means that it is that one you want

Eventually you'll be able to build up a spreadsheet like this one.

From here, it's a matter of programming support since you already have knowledge of the correct Packet positions.

Xbox One Drum Devs

@artman41 artman41 added enhancement New feature or request help wanted Extra attention is needed labels Aug 10, 2019
@Dunkalunk
Copy link

Dunkalunk commented Sep 27, 2019

IN DEVELOPMENT

No releases yet, but here is the repo: https://github.com/Dunkalunk/drumsniffer

At the time of writing this post it is just a clone of guitarsniffer. Hoping to make some progress on it this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

2 participants