Got an nRF52 or nRF51 device you need to flash? Got an ESP32 laying around collecting dust? If so, then firmware hacking extraordinaire [Aaron Christophel] has the open source code you need. His new project allows the affordable WiFi-enabled microcontroller to read and write to the internal flash of Nordic nRF52 series chips via their SWD interface. As long as you’ve got some jumper wires and a web browser, you’re good to go.
In the first video below [Aaron] demonstrates the technique with the PineTime smartwatch, but the process will be more or less the same regardless of what your target device is. Just connect the CLK and DIO lines to pins GPIO 21 and GPIO 19 of the ESP32, point your web browser to its address on the local network, and you’ll be presented with a straightforward user interface for reading and writing the chip’s flash.
As demonstrated in the second video, with a few more wires and a MOSFET, the ESP32 firmware is also able to perform a power glitch exploit on the chip that will allow you to read the contents of its flash even if the APPROTECT feature has been enabled. [Aaron] isn’t taking any credit for this technique though, pointing instead to the research performed by [LimitedResults] to explain the nuts and bolts of the attack.
Over the last year or so we’ve noticed a definite uptick in the number of folks using OpenOCD on the Raspberry Pi. It’s a cheap and convenient solution for poking around with various microcontrollers and embedded devices, but not always the most elegant. Looking to improve on the situation somewhat, [Matthew Mets] has been working on a purpose-built JTAG Hat to clean things up a bit.
Onboard level shifters allow you connect to JTAG and SWD interfaces from 1.8 to 5 V, and if you power the target device from the Pi itself, there’s even support for measuring the voltage and current. To connect up to your target, the open hardware board features a “legacy” pin header perfect for jumper wires, as well as a dedicated 10-pin Cortex Debug Connector. Whether you spin up your own or buy one assembled, it certainly looks like a tool worth having around if you often find yourself working with the appropriate chips.
In addition to the design files for the hardware, [Matthew] has also provided some nice documentation on how to get the software side of things up and running. Starting with a blank SD card, it walks you through the initial setup of the Raspberry Pi all the way through the installation and configuration of a patched version of OpenOCD designed to support the JTAG Hat.
It will come as no surprise to the average Hackaday reader that what we’re looking at here is a pocket-sized NES emulator, but until [stacksmashing] cracked his open, nobody was quite sure what kind of hardware is was running on. Thankfully there wasn’t an epoxy blob in sight, and all of the chips were easily identifiable. Armed with the knowledge that the Game & Watch is running on a STM32H7B0 microcontroller with a nearby SPI flash chip holding the firmware, it was just a matter of figuring out how the software worked.
But he was able to dump the RAM through SWD, which allowed him to identify where the Super Mario Bros NES ROM lived. By connecting the SPI flash chip to a reader and comparing its contents with what the system had in RAM, [stacksmashing] was able to figure out the XOR encryption scheme and come up with a tool that will allow you to insert a modified ROM into an image that can be successfully flashed to the chip.
So does that mean you can put whatever NES ROM you want on the new Game & Watch? Unfortunately, we’re not quite there yet. The emulator running on the device has a few odd quirks, and it will take some additional coaxing before its ready to run Contra. But we’ve seen enough of these devices get hacked to know that it’s just a matter of time.
Over the last couple of years, we’ve seen an incredible number of DIY keyboard builds come our way. Some have had their switches nestled into laser-cut aluminum and others 3D printed plastic. They may be soldered together on a custom PCB, or meticulously hand-wired. But however they were built, they almost all shared one thing in common: they ran some variant of the open source QMK keyboard firmware.
But what if you just want to run an open firmware on the keyboard you picked up for $50 bucks on Amazon? That’s exactly where [Stephen Peery] found himself nine months ago with this DK63 gaming keyboard. Since so many of these small RGB LED mechanical keyboards are very similar to existing open source designs, he wondered what it would take to blow out the original firmware and replace it with a build of QMK.
While [Stephen] doesn’t have everything working 100% yet, he’s nearly reached the end of his epic reverse engineering journey. The first step was tearing apart the keyboard and identifying all the components it used, then pulling the original firmware out of the updater. From there, between Ghidra and Serial Wire Debug, he was able to figure out most of what the stock firmware was doing so he could replicate it in QMK.
According to his README, the RGB LEDs and Bluetooth functionality don’t currently work, but other than that it seems QMK is up and running. If you’re OK with those concessions, he has information on the page about flashing his build of QMK to the stock DK63 with the ST-Link V2 so you can give it a shot. Though you do so at your own risk; we wouldn’t recommend doing this on your only keyboard.
Hackaday editors Elliot Williams and Mike Szczys reflect on great hacks of the past few days. Strain relief is something every electronics geek encounters and there’s a spiffy way to make your hot-glue look like a factory connector. There’s something in the air and it seems to be recreating early computers. Did you know astronauts are baking cookies they’re forbidden to eat? And did you hear about the 3D printer that’s being fed oil from the deep fryer?
Take a look at the links below if you want to follow along, and as always tell us what you think about this episode in the comments!
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.
A few weeks ago we featured the McHck project (pronounced McHack), a $5 Cortex M4 based platform which can be directly plugged into one’s computer. Recently, [Simon] announced that he made a firmware allowing a McHck to behave as a SWD adapter and also detailed his flashing rig.
Therefore, those who’d want to build their own McHck would only need to borrow an SWD programmer once to get started. When the first platform has been programmed with the SWD firmware, it can be used to flash and debug applications on the second McHck. Consequently, the microcontroller flashing rig [Simon] designed (shown in the picture above) is based on this. The few core elements are a TQFP48 ZIF programming socket, a push button and two LEDs. Simply push the Kinetis in the programming socket, close it and press the button. Success of the operation is indicated by the two LEDs. [Simon] used the Ragel State Machine Compiler to generate his flashing program and all the code he made can be downloaded from his github.