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
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
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.
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.
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.
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)
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.
> Because of course they will. I mean, it might cost them $10 annually to keep it up?
For large tech companies, it's most likely due to organizational reasons. Someone (likely some team) has to own any component/subsystem and be responsible for its maintenance. This obviously comes at a cost of the teams' other projects (read bonus OKRs), a direct consequence is that it becomes hard to permanently rehome a dead-end project like the Stadia controller, best you can hope is a temporary reprieve from a sympathetic team.
OT1H, I hear you and that was my suspicion too: they tossed the site into some nginx pod on some k8s cluster and those things don't live forever
But, for a discontinued product, isn't the information static and thus the GCS "turn this bucket into a webserver and don't bother me anymore" ( https://cloud.google.com/storage/docs/static-website#example... ) seems like even less than the cited $10/yr. If the next question is "to which Project does the GCS bucket get billed?" then I'm pretty sure GCP gives away tiny storage to anyone with an email
I wonder why companies don’t just donate dead projects “to the community” more often: find a volunteer maintainer willing to take the project on; get them set up with ownership rights over a clone of the project on a non-corp-internal SCM; ensure all branding and IP is stripped from the project; and then just walk away. Link to this “third party” effort when anyone asks for support, mentioning that it is unsupported.
if the update was just an executable, it wouldn't require maintenance, just hosting. They chose to have the update use a webservice. That's on them.
I'm not mad about it. I use Linux, so I was able to update my controller on Chrome/Linux. I expected to need to borrow a Windows computer.
1. Google probably uses IP owned by the chip manufacturer (nxp).
2. Google, famously, uses a “monorepo”. One of the perks of this is that it allows a significant amount of code-reuse. They may not want to commit to sharing all the internal libraries they’ve built.
I think it's more an issue with Bluetooth as a protocol. Even Xbox controllers don't do audio over Bluetooth; you need their custom 2.4ghz adapter for audio. Bluetooth hand-free profile, the one for both input and output audio, is extremely outdated and still downgrades audio to something like mono 16Khz. Even modern Apple Airpods will have this issue. It's fine for voice calls, but with music and all, it's not a good experience.
I did this update on one of my controllers, and the lag most of the time was barely tolerable. The rest of the time was lag spikes that made games unplayable.
I thought maybe it was the fault of my BT chip in my computer, so I turned it off and plugged it in instead, and the lag was most gone, but still worse than my Razer Wolverine.
I just threw mine in a box and gave up on it. I probably won't even bother flashing my other 2.
I haven't noticed any latency issues either, compared to an Xbox One or GuliKit controller.
I have had the issue where the controller will connect but no button / axis events actually are produced. Disconnecting and reconnecting fixes it for me. This seems to be a common issue from other comments I've seen online.
It’s quite possible it’s a problem with the desktop side. I had terrible lag with my Xbox controller and found that it’s a known issue where the controller doesn’t send the ideal connection settings and it ends up with lag but it can be fixed.
I've been having some annoyances which seem to stem from somehow any BT use in this laptop causing it to lag sometimes like it's competing in the latency olympics, and strange interactions like it not allowing me to pair any bluetooth game controller if I have a wireless headset paired (it just errors out every time), but the reverse not being true, so I can pair them if I do it in the right order, but have to unpair both if the game controller disconnects for some reason. :/
Wondering if this is firmware is signed, hoping they removed signing or it was never signed. I've used the controller a bit this week to play games on my android phone and quite like it.
Often times signature checking is fused in during provisioning. That is to say, if they had it enabled before there is a good chance they’re unable to disable it. You’ll probably need to find a vulnerability in the iMX8 bootROM which checks these fuse bits to bypass it.
You’d need to read the iMX8 docs to know for sure, but it does support full secure boot IIRC.
Edit:
Yup this appears to be true.
“The public key is included in the final binary and a hash of the public key is programmed in the SoC, in One-Time Programmable e-fuses, for establishing the root of trust.”
http://en.techinfodepot.shoutwiki.com/wiki/Google_Stadia_(H2...
Broadcom are $#&@ for documentation and licensing, so I'm not super optimistic.
[1] https://www.nxp.com/products/processors-and-microcontrollers...