[HN Gopher] A Dump of the Raw Stadia Controller BT Firmware
___________________________________________________________________
A Dump of the Raw Stadia Controller BT Firmware
Author : bmaupin
Score : 125 points
Date : 2023-01-21 14:46 UTC (8 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| hanniabu wrote:
| Have they renabled the controller mic yet?
| vageli wrote:
| 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...
| haunter wrote:
| This is also good for the future because Google will take down
| the update site on December 31
| josteink wrote:
| 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...
| arglebargle123 wrote:
| I mean, are we surprised? Google's product expertise is in
| discontinuing products after all.
| sangnoir wrote:
| > 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.
| mdaniel wrote:
| 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
| derefr wrote:
| 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.
| fragmede wrote:
| 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.
| awill wrote:
| 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.
| solarkraft wrote:
| It costs money and doesn't gain you any (when you don't
| consider the probably significant good will).
| kvathupo wrote:
| 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
| ghostpepper wrote:
| 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 wrote:
| Definitely not pedantry: I admittedly conflated the two!
| rolenthedeep wrote:
| 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 wrote:
| 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?
| jhart99 wrote:
| 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 wrote:
| Also, Ghidra's decompiler works with many CPU
| architectures whereas IDA only supports a few.
| rolenthedeep wrote:
| 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.
| Atlas22 wrote:
| 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.
| pifm_guy wrote:
| 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.
| AceJohnny2 wrote:
| The 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...
| sigmar wrote:
| 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.
| obnauticus wrote:
| 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...
| [deleted]
| solarkraft wrote:
| 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.
| sgtnoodle wrote:
| They could potentially develop a shim bootloader, unless
| the ROM bootloader validates the entire flash range.
| detaro wrote:
| 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.
| wccrawford wrote:
| 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.
| arglebargle123 wrote:
| 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.
| rOOb85 wrote:
| Wanna sell one to me?
| jeanofthedead wrote:
| Would love to know why mine needs to be forgotten and re-paired
| to my Nvidia Shield every time I use it now.
| flatiron wrote:
| Stadia controller is by far my favorite. Glad they kept mine
| alive.
___________________________________________________________________
(page generated 2023-01-21 23:00 UTC)