[kvathupo]

Although I'm unfamiliar with bluetooth drivers, how would you go about making binary files portable?

I'd imagine one would decompile the binaries, and modify the source code for redistribution as some portable library supporting whatever build target a user has. Of course, I assume (1) the decompiler can't detect compile-time macros detecting architecture and (2) you'd be screwed if you need shared libraries.

P.S. Interestingly, the first link when one googles "firmware decompiler" is to CIA code on Wikileaks lol

[rolenthedeep]

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

[heyoni]

I knew people were leaning hard into Ghidra because it was free but are you implying that it’s surpassed IDA in terms of functionality?

[Atlas22]

Have used both professionally (but mostly IDA). Its definitely not surpassed IDA in every category yet but it gets closer every update.

I think IDA still wins in at least: disassembler quality of the popular instruction sets (e.g., some knowledge of undocumented instructions, sometimes control flow inference trips up where IDA's doesn't), function signature detection, decompiler (marginally), plugins available, UX polish (but I have much more experience in IDA than Ghidra so that might just be me).

I think Ghidra wins for architecture availability, scripting API design & documentation, extensibility, and speed of improvement.

Probably many more categories im not thinking of but if Ghidra were to match exceed IDA in the above that would likely convince me to switch over.

[jhart99]

One way in which Ghidra excells is that it comes with a TON of processor definitions. IDA charges extra for those and the quality of the Ghidra definitions tends to be higher IMO. It makes Ghidra a better tool for embedded processors.

[mgk123]

Also, Ghidra's decompiler works with many CPU architectures whereas IDA only supports a few.

[rolenthedeep]

Nah, I don't actually have a use for firmware decompilation. I've used ghidra once just to poke around, but that's it.

My understanding is that IDA does some things a lot better, but at a significant cost. Ghidra has become the de-facto tool for hackers and makers simply because it's free.

[astrange]

Not only a significant cost, but they're not even very happy about you trying to buy it, because you might leak it.

[ghostpepper]

Just to be pedantic, firmware and drivers are not the same thing.

I'm not familiar with Stadia but when I saw 'Dump of controller BT firmware' I assumed that this is the code that runs on the actual bluetooth controller chip inside the controller. Presumably this handles at least the lower layers of comms between the controller and the host PC.

Maybe there's another application processor in the controller that handles higher-level communications or maybe the BT chip has a small general-purpose CPU core inside it, but regardless I don't see why this firmware would need to be modified to make the controller work on a windows PC.

Drivers, on the other hand, would run on the host PC side and would likely need to be rewritten for each platform that you want the controller to work with (although hopefully at least some of the lower-level bluetooth layers are already handled in windows/linux/etc. and the actual code required might not be too extensive)

[kvathupo]

Definitely not pedantry: I admittedly conflated the two!

[pifm_guy]

For any substantial changes, it's probably easier to just rewrite the firmware from scratch.

Nearly every chip that supports Bluetooth has demo code available to make a Bluetooth HID device. All you'd need to do is run that and fix up the button mappings.