You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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;
There is ~20+ bytes on a header
A Packet containing data is 40 bytes long (for the rb4 guitar)
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;
C#
This one was too slow though, took at least 200ms to action
Erlang
This one was nice and fast but the windows support was lacking and was impossible for people to use portably
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.
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 aProprietary 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
Packet
s must be coming into the system somehow; it's usb right?There must be a way of seeing the
Packet
s coming in.This is where
Wireshark
comes in; we use a combination ofWinPCap
, the windows binding for thePCap
library (Packet
Capture), andUSBPCap
which allows us to capture USBPacket
s 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
Packet
s I received on both the press & release, resulting a spreadsheet documenting each input and what I thought it mapped to on thatbyte
of thePacket
, leading me to understand 3 things;bytes
on a headerPacket
containing data is 40bytes
long (for the rb4 guitar)Packet
are useable data and what they correlate toFrom that, it was to write it in such a way that it was fast to action. I went through 3 stages with this process;
C#
Erlang
Golang
Development Requirements
Golang
GCC
Compiler for the cgo stuffWireshark
WinPCap
USBPCap
Basic Idea
This is the basic idea of USB
Packet
capture & it'll show you the basics of usingWireshark
.All the
Packets
will be in hex when you useWireshark
and that's how I treat them in golang too since I don't like randombytes
(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 toPacket
dump the activation of something, waiting a couple seconds then repeating multiple times to produce a folder ofPacket
s similar to this one.Second, you will want to filter out
Packet
s that are obviously outliers - (i.e there might be a pingPacket
in there that you caught - some will be obvious since thePacket
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;bytes
are thePacket
header.bytes
that only increment appear to be correlationbytes
to guarantee that thePacket
comes after the prior one.byte
in thePacket
is0x00
&0x01
) typically means that it is that one you wantEventually 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
The text was updated successfully, but these errors were encountered: