It’s amazing to see how much technology is packed into even the “simple” devices that we take for granted in modern life. Case in point, the third party Xbox controller that [wrongbaud] recently decided to tear into. Not knowing what to expect when he cracked open its crimson red case, inside he found an ARM Cortex microcontroller and a perfect excuse to play around with Serial Wire Debug (SWD).
Though even figuring out that much took a bit of work. As is depressingly common, all the interesting components on the controller’s PCB were locked away behind a black epoxy blob. He had no idea what chip was powering the controller, much less that debugging protocols it might support. But after poking around the board with his multimeter, he eventually found a few test points sitting at 3.3 V which he thought was likely some kind of a programming header. After observing that pulling the line labelled “RES” low reset the controller, he was fairly sure he’d stumbled upon a functional JTAG or SWD connection.
As [wrongbaud] explains in his detailed blog post, SWD is something of a JTAG successor that’s commonly used by ARM hardware. Using just two wires (data and clock), SWD provides hardware debugging capabilities on pin constrained platforms. It allows you to step through instructions, read and write to memory, even dump the firmware and flash something new.
For the rest of the post, [wrongbaud] walks the reader through working with an SWD target. From compiling the latest version of OpenOCD and wiring an FTDI adapter to the port, all the way to navigating through the firmware and unlocking the chip so you can upload your own code.
To prove he’s completely conquered the microcontroller, he ends the post by modifying the USB descriptor strings in the firmware to change what it says when the controller is plugged into the computer. From here, it won’t take much more to get some controller macros like rapid fire implemented; a topic we imagine he’ll be covering in the future.
This post follows something of a familiar formula for [wrongbaud]. As part of his continuing adventures in hardware hacking, he finds relatively cheap consumer devices and demonstrates how they can be used as practical testbeds for reverse engineering. You might not be interested in changing the ROM that a Mortal Kombat miniature arcade cabinet plays, but learning about the tools and techniques used to do it is going to be valuable for anyone who wants to bend silicon to their will.
Nice. More of this.
Glad you dig it, planning on doing a whole series on hardware level debuggers like this, stay tuned!
Absolutely amazing!
I will be paying close attention to further posts!
congratulations and thank you!
This is great, I wonder if can be use as vehicle to exploit some xbox one vunerability like what happend for the PS3.
It could certainly be used as some kind of attack vector – I’ll throw the OpenOCD configs up on github so other people can start poking around with it!
nice!
Ditto.
Finally, someone gets it!
I’m quite impressed with the amount that [wrongbaud] has picked up from the couple of documents he used – it should be noted that one can use almost exactly the same mechanism as SWD when running on the CPU itself.
When he asks “what if we didn’t have access to the DAP and wanted to figure out what our target was via memory reads and writes?”, one can do the same steps that OpenOCD did (but instead one is only doing the same steps as the MEM-AP). Reading the “ROM table” to find the same information that OpenOCD would will then also work on any Cortex irrespective of manufacturer (in this case, in v7M the ROM table is architected as being at 0xE00FF000, see https://static.docs.arm.com/ddi0403/eb/DDI0403E_B_armv7m_arm.pdf from page 740 but Cortex-A and R cores there’s an internal CPU register that reports the address location of the ROM Table)
>From here, it won’t take much more to get some controller macros like rapid fire implemented
It is relative easy to dump the memory and to play around with changing the descriptor strings encoded in Unicode as it is well documented from the USB standard. You are underestimating the amount of work to reverse engineering the ROM and undocumented system. Things like macros are defined by custom firmware. you have to disassemble a binary blob.
OpenOCD alone won’t tell you what the bits in the memory map are. Without finding out the exact model of microcontroller, chip manufacturer, and if they have a programming guide without requiring an NDA etc.
Great article. This is what we want to see.
SWD rules! You can knock yourself out are run remote gdb if you like, pretty amazing.
Glad you like it, next one will be more JTAG focused on a target that I think a lot of people will enjoy seeing!
I use GDB in the article to read out the ID register as well!
Wow