Remap buttons to keyboard keys

[EternalMark]

I would like to help you with your research. I have an 8BitDo Wireless Bluetooth USB Adapter v1 and I am thinking of buying the 2, and even going for the 8BitDo Ultimate Mobile Gaming Controller. I'm looking to remap any gamepad buttons to keyboard keys via firmware, and with a little more ambition, map button combinations to key combinations. Based on what you have seen, do you think this is possible? I am currently in the part of generating my own Ultimate Software with the decompiled code.

[TheJayMann]

If the controller is compatible with the generic Ultimate Software that is designed to work on multiple different controllers, then I do believe so. However, if it is a later model Pro 2 or a model that came out after the Pro 2, you would have to make sure the CRC is calculated on each host message packet. Given that the controllers I have are the SN30 Pro Plus and an early model Pro 2, the CRC section instead remains zeroed.

If you want information about how I went about creating this documentation, it is a combination of decompiling the Windows 8bitdo ultimate software (it is a .NET framework application, so something like dnSpy can do this), using a disassembling debugger for the native dll file (I found cutter to be the easiest to use of the ones I was able get, though x86dbg was useful as well), and making use of a utility that can monitor raw usb hid traffic. Given the similarity in hidraw device access for both usb and bluetooth, I assume you can try to monitor bluetooth hid traffic as well. The software I used to monitor the hid traffic was busdog.

[TheJayMann]

Reading your request more carefully, unless the device already has keyboard mapping functionality, I do not believe it to be possible to map to keyboard keys. In order to do this, the device would have to register an HID keyboard device in addition to an HID gamepad device, and, at least with the devices I have, this doesn't happen. The only solution I can see for this would be to use an application that does this mapping, something like antimicrox.

Also, each different device has a potentially different configuration file format, except that the Pro 2 does appear to have the same configuration file format as most of the Ultimate controllers. Thus, if the device is not the SN30 Pro Plus, Pro 2, or Ultimate controller, you may have to figure out what the configuration file format is, though usually this can be found easily by finding the corresponding struct in the decompiled ultimate software.

[EternalMark]

I already have the US source, and it works correctly when I compile it again. Although I removed the code that uses the J2i.Net.XInputWrapper reference because I couldn't find it. I wish the 8BitDo people would share the source so that the community could modify all their products.

The gamepad I want to use is the DS4 connected to the 8BitDo Wireless USB Adapter (8WUA) and then connected to the PC (or an Android device). I think the PC could detect that I am connecting a keyboard instead of a gamepad, only changing the HID on the 8WUA, as you say. Don't you think? For now I just need to “transform” it into a keyboard.

I'm still working on that. My next step is to understand the US source code and how it does the magic. I will take your recommendations.

[TheJayMann]

It has been some time since I'd ran the recompiled ultimate software, but, from what I remember, early on when the software first runs, it starts a series of tasks, each one scanning usb devices that are connecting, each task looking for specific vendor and device ids. When it finds a matching one, it either notifies the main application immediately (in the case the vendor id is an 8bitdo id), or it attempts to send a special custom packet to see if it responds with an 8bitdo response and version information (in case the controller is spoofing a vendor id and device id, such as a Switch or XBox controller), and, then, if the internal version information matches, it typically sends a special command that causes the device to disconnect and reconnect with an 8bitdo vendor id.

Once you know the real device id of the device, you can usually look for it in the source code, and see what other places use this device id, and find correlating data structures, which can be mapped to the binary data format used to configure the devices. At some point, the sync devices process is going to take whatever current in memory version of this structure present, and pass it to a native function defined in a dll file (which I believe is 8bitdoadvance.dll). This is where a disassembler such as cutter, x86dbg, or ghidra is helpful, as well as a knowledge of x86 assembler, or, at the very least, the knowledge of how to look up and understand the op codes as they are disassembled. The disassembly will often take the entire memory buffer passed in from the configuration file, as well as possibly look up the device id to set up different code processes (such as actually performing CRC on later model Pro 2 controllers and Ultimate controllers), split up the memory into chunks prefixed with HID metadata, then call WriteFile for each chunk on the file handle from opening the device. This process is essentially what the various write scripts are doing for the example bash scripts I have, instead using the linux equivalent which is available to a shell.

Since I've completely replaced my Windows install with a Linux install, I no longer have a setup which would allow me to jump right back in to this immediately, though I could probably get back up to speed a bit should I have some extra free time to do so.