@roblabla glad to see that people are still interested in the Steam Controller hardware! Thanks for sharing the work you've done.

To address the question on your RE database, first I need to say I have limited knowledge when it comes to Ghidra. I've been meaning to check it out ever since I heard that Coreboot was using it for its RE efforts, but haven't yet. Do you think your Steam Controller RE effort is a good place to start? Or would you recommend some tutorials before jumping into a specific project like this? Also, forgive me, but what exactly does " PR'd" mean? Also what is would be the file sizes for the database zipped v.s. XML?

Next, I think there might be a slight misunderstanding as to the intention of this effort. The goal of this project is not a complete RE and reimplementation of Valve's official firmware, but rather to deconstruct their software enough to understand the controller and turn it into a platform that can do other things (be a development environment, act as a controller for other systems or maybe even act as a low quality bluetooth speaker someday...). This project is really more of an open ended effort to have fun with this particular hardware (and maybe learn something new along the way). Overall I think it's convenient our goals are different. Less worries of the implication of sharing information and (evening seeming to be) competing or intruding :).

Do you think your Steam Controller RE effort is a good place to start?

If you already have a bit of RE experience with other tools (which you seem to have), then it's not a bad place to start. There are a couple of subtleties with Ghidra when it comes to importing firmware since you have to manually specify the different sections of your binary and their permissions, create regions for the non-file backed areas (BSS, RAM, MMIOs), and manually set the entrypoint to kickoff Ghidra's auto-analysis. But once the binary is imported, the rest is the same as reverse engineering any other kind of software. The Steam Controller Firmware has a lot of global state and direct references, which actually makes RE quite easy.

I can make a quick writeup of how I went about doing my RE work along with my database if you want. And if you (or anyone else reading this!) wants to participate in the RE, feel free to send me an email! Ghidra has a sort of "svn-like" mode where multiple people can collaborate on a single database, so we can avoid duplicating efforts or having to manually merge the XMLs (which doesn't work too well 😅).

Also, forgive me, but what exactly does " PR'd" mean? Also what is would be the file sizes for the database zipped v.s. XML?

"PR'd" as in sending a pull request on github. XML is 1.8MB, zip is 587KB. If having the file in repo is inconvenient due to file sizes, I could also host them separately and maybe add a link to it to the RE Readme?

Next, I think there might be a slight misunderstanding as to the intention of this effort. [...] Overall I think it's convenient our goals are different. Less worries of the implication of sharing information and (evening seeming to be) competing or intruding :).

Haha, TBH even if our goals is the same, I would certainly still want to share everything I learn. This repository is a great, centralized treasure trove of information and I want to make sure everything I find out goes back here for the rest of the community 😄 .

A writeup of your work would be much appreciated! Maybe having experience with reverse engineering this code with other tools will lessen the barrier to entry with Ghidra for myself. I'll do my best to help out once I find the time and get the swing of using Ghidra!

Funny that for all the ways I tried to Google "PR acronym" I didn't add the important keyword of "github." 🤦. I think the Understanding the Software section of the RE Readme would be a great place to add this.

Glad to hear this project has been helpful to you and that we're on the same page regarding wanting to share what we figure out!

@roblabla @greggersaurus I have started using Ghidra to reverse the main part of the firmware. Ghidra just added a debugger, and since the debug ports are still on the steam controller, that might prove helpful as well.

The big issue with real-time examination of the steam controller is that it uses a watchdog timer to trigger auto-resets if something takes too long to execute, so static analysis like in Ghidra will probably be the best way to figure out exactly how Valve has implemented it.

Hey, I've been doing the same thing!

I haven't been able to get ghidra's debugger to play well with any of the gdb-stubs I've used so far (openocd and probe-rs).

My current focus has been the nrf51 firmware, which I've almost entirely reverse engineered. If you'd like to join forces, you should join me on discord! I have a ghidra server setup, so we could maybe share our RE progress.

@roblabla Awesome! I am pretty early in the process, and busy with other things right now, but I will take a look at the discord if I have time.

Ghidra's debugger is really spotty on ARM stuff right now, and does not work at all for gdb on Windows (it needs Linux).

As a side note, where did you get those adapter cables? The only ones I can find are from tag-connect, and they want $50 for them.

That's where I got them, though it's 35eur each (+ shipping). I got a pair of TC2030-CTX, along with an adapter from olimex so I could fit my jumper cables (the adapter at the end of the ribbon cable of the tag connect is super small).