A Dump of the Raw Stadia Controller BT Firmware
github.comThe Stadia controller runs on a NXP i.MX RT1061 MCU [1], and a Broadcom BCM43458 wireless chip.
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...
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
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?
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.
Also, Ghidra's decompiler works with many CPU architectures whereas IDA only supports a few.
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.
Not only a significant cost, but they're not even very happy about you trying to buy it, because you might leak it.
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)
Definitely not pedantry: I admittedly conflated the two!
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.
This is also good for the future because Google will take down the update site on December 31
Because of course they will. I mean, it might cost them $10 annually to keep it up?
There’s also something awfully meta about Google discontinuing a support-page for their discontinued product…
> 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
Are Google teams even allowed to use GCS?
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.
Licensing. Especially when hardware is concerned. Google, big as they are, don't own the rights to NXP or especially Broadcom's IP, and so they can't.
Google (in theory) isn't making any more of these controllers, nor updating the firmware anymore
Surely there's no clause that says they have to perpetually license old firmware binaries?
If they want to perpetually distribute old firmware binaries they have to perpetually license them
Because they are risk averse and there is no possible upside so they eliminate it completely to avoid any possible downside.
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.
It costs money and doesn't gain you any (when you don't consider the probably significant good will).
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.
They just fired 12,000 people, you think they kept the person in charge of running support pages for dead projects?
I mean, are we surprised? Google's product expertise is in discontinuing products after all.
They’ve taken down the discontinuation pages for talk.google.com and reader.google.com. Reader redirects to a 404 page, but Talk is NXDOMAIN entirely.
Stadia controller is by far my favorite. Glad they kept mine alive.
Have they renabled the controller mic yet?
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.
Not sure why this is downvoted, the stadia controller does indeed contain a microphone.
https://support.google.com/stadia/answer/9565956?hl=en&ref_t...
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.
Really? Are you in a particularly noisy 2.4GHz environment? I've only updated one of mine so far but it's been perfectly serviceable after.
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.
I don't think so. I just bought a new XBox Elite Series 2 and it's perfectly fine via Bluetooth under the exact same conditions.
And the Stadia controller was very slightly laggy even when just using the USB cable.
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.
Got a pointer?
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. :/
Wanna sell one to me?
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.”
See https://www.variscite.com/blog/i-mx8-secure-boot-made-easy-c...
I love it when e-waste is created through this type of security theater.
They may not be able to disable signature checking, but they can and should publish the private key.
They could potentially develop a shim bootloader, unless the ROM bootloader validates the entire flash range.
How is i.MX8 related to these controllers?
(typing it from a i.MX8 phone right now - putting it into a gaming controller sounds hilariously ridiculous)
from what I've read (sorry, can't find the link again right now) they didn't change the update mechanism at all, still requiring signatures.
Would love to know why mine needs to be forgotten and re-paired to my Nvidia Shield every time I use it now.