| As a person who develops Bluetooth game controllers, there's nothing particularly interesting or valuable here. There's a few layers of firmware in a device like this, and none of them are interesting. The device itself has firmware which reads button presses, talks to the wireless chipset, and drives the vibration motors. The wireless chipset has firmware, too, but most of it is code provided by the chip manufacturer for free (this is actually the driver). There's a layer on top of the driver that acts to handle things like setting the device name, choosing wifi vs Bluetooth, managing connections. The controller takes button presses and puts that data on a serial port over Bluetooth. Or in this case, feeds it to some web api over wifi. As to the rest of your question, these images are not and really can't be very portable. Firmware is highly dependent on hardware. For example, a chip might have four SPI ports that can talk to the Bluetooth chipset. If this controller uses port 0, and another uses port 2, it will just fundamentally not work. Firmware images just aren't really that useful outside of their target hardware. Decompiling won't tell you very much. If you're interested in the wireless chipset, the thing to do is get a device and open it up to see what chip is there. Then you can just download the SDK from the manufacturer. On the developer side, you can build a firmware to target multiple devices. As you said, preprocessor directives can select code based on hardware at compile time. That's pretty much how you do it. And yeah, the main tool for decompiling firmware is Ghidra, which was developed by the US government. IDA is another one to look at, but I'm not sure if it's relevant anymore |