When Microsoft released its first entry into the video game console market with the Xbox, a lot of the discussions at the time revolved around the fact that it used a nearly off-the-shelf Intel CPU and NVIDIA GPU solution. This made it quite different from the very custom consoles from Nintendo and Sony, and invited thoughts on running custom code on the x86 console. Although the security in the console was hacked before long, there were still some open questions, such as whether the secret boot ROM could have been dumped via the CPU’s JTAG interface. This is the question which [Markus Gaasedelen] sought to answer.
The reason why this secret code was originally dumped by intercepting it as it made its merry way from the South to the North Bridge (containing the GPU) of the Xbox was because Microsoft had foolishly left this path unencrypted, and because the JTAG interface on the CPU was left disabled via the TRST# pin which was tied to ground. This meant that without removing the CPU and adding some kind of interposer, the JTAG interface would not be active.
A small issue after the harrowing task of desoldering the CPU and reinstalling it with the custom interposer in place was to keep the system integrity check (enforced by an onboard PIC16 MCU) intact. With the CPU hooked up to the JTAG debugger this check failed, requiring an external injection of the signal on the I2C bus to keep the PIC16 from resetting the system. Yet even after all of this, and getting the secret bootrom code dumped via JTAG, there was one final system reset that was tied to the detection of an abnormal CPU start-up.
The original Xbox ended up being hacked pretty thoroughly, famously giving rise to projects like Xbox Media Center (XBMC), which today is known as Kodi. Microsoft learned their lesson though, as each of their new consoles has been more secure than the last. Barring some colossal screw-up in Redmond, the glory days of Xbox hacking are sadly well behind us.
Sometimes, security mechanisms can be bypassed if you just do things slightly out of the ordinary. For instance, readout protection on microcontrollers is a given nowadays, to the point where it’s intentionally enabled and relied upon as a major technical measure to protect intellectual property. The gist is — when you connect to a microcontroller over its debug interface and then ask to read its flash memory, it will politely refuse. However, [Racerxdl] shows us that in practice, it’s not flawless protection – for certain chips, you just need to be a little quicker than usual.
Usually, flashing and debugging software will chat with the microcontroller for a bit, and probe parameters before going for any direct requests. However, if you skip the courtesy and bluntly get to the point immediately right after power is applied to the microcontroller, you can intimidate them just enough to give you one byte of its memory before it refuses to cooperate further. Since that can be any byte you wish, you can read the entire flash — one byte at a time.
You need to power cycle the chip before you can progress, so the hardware does involve a bit more than just an SWD interface, and it will take a fair bit more time than reading out a non-protected chip the usual way; plus, of course, the debugging interface needs to be active for this in the first place, which isn’t always the case. However, it still beats paying a few thousand dollars for a factory in China to decap your chip and read it out using a fancy machine.
[Racerxdl] didn’t just write a proof-of-concept for this attack – they implemented it for one of our favourite chips, the RP2040. As such, you no longer need an unobtainium STM32 to dump an unobtainium STM32.
To be clear, [Racerxdl] didn’t design this attack — it’s been around for some time now. Credit for that goes to Johanes Obermaier. All in all, this is a wonderful reminder that seemingly reliable security mechanisms can be foiled by the simplest tricks. For instance, if your chip erases the flash when you unlock its protection, you can just tell it not to.
As more and more electric vehicles penetrate the market, there’s going to have to be a proportional rise in the number of charging stations that are built into parking garages, apartment complexes, and even private homes. And the more that happens, the more chargers we’re going to start seeing where security is at best an afterthought in their design.
But as this EV charger teardown and reverse engineering shows, it doesn’t necessarily have to be that way. The charger is a Zaptec Pro station that can do up to 22 kW, and the analysis was done by [Harrison Sand] and [Andreas Claesson]. These are just the kinds of chargers that will likely be widely installed over the next decade, and there’s surprisingly little to them. [Harrison] and [Andreas] found a pair of PCBs, one for the power electronics and one for the control circuits. The latter supports a number of connectivity options, like 4G, WiFi, and Bluetooth, plus some RFID and powerline communications. There are two microcontrollers, a PIC and an ARM Cortex-A7.
Despite the ARM chip, the board seemed to lack an obvious JTAG port, and while some unpopulated pads did end up having a UART line, there was no shell access possible. An on-board micro SD card slot seemed an obvious target for attack, and some of the Linux images they tried yielded at least a partial boot-up, but without knowing the specific hardware configuration on the board, that’s just shooting in the dark. That’s when the NAND flash chip was popped off the board to dump the firmware, which allowed them to extract the devicetree and build a custom bootloader to finally own root.
The article has a lot of fascinating details on the exploit and what they discovered after getting in, like the fact that even if you had the factory-set Bluetooth PIN, you wouldn’t be able to get free charging. So overall, a pretty good security setup, even if they were able to get in by dumping the firmware. This all reminds us a little of the smart meter reverse engineering our friend [Hash] has been doing, in terms of both methodology and results.
Thanks to [Thinkerer] for the tip.
JTAG is a powerful interface for low-level debugging and introspection of all kinds of devices — CPUs, FPGAs, MCUs and a whole lot of complex purpose-built chips like RF front-ends. JTAG adapters can be quite obscure, or cost a pretty penny, which is why we’re glad to see that [Adam Taylor] from [ADIUVO] made a tutorial on using your Pi Pico board as a JTAG adapter. This relies on a project called XVC-Pico by [Dhiru Kholia], and doesn’t require anything other than a Pi Pico board itself — the XVC-Pico provides both a RP2040 firmware implementing the XVC (Xilinx Virtual Cable) specification and a daemon that connects to the Pico board and interfaces to tools like Vivado.
First part of the write-up is dedicated to compiling the Pico firmware using a Linux VM. There’s a pre-built
.uf2 binary available in the GitHub repo, however, so you don’t have to do that. Then, he compiles and runs a daemon on the PC where the Pico is connected, connects to that daemon through Vivado, and shows successful single-stepping through code on a MYIR Z-turn board with a Xilinx XC7Z020. It’s worth remembering that, if your FPGA’s (or any other target’s) JTAG logic levels are 1.8V or 2.5V-based, you will need a level shifter between it and the Pi Pico, which is a board firmly in the 3.3V realm.
You just cannot beat the $3 price and the ease of setup. Pi Pico is shaping up to be more and more of a hardware multi-tool. Just a month ago, we covered how the Pico can work as a logic analyzer. A lot of that, we have the PIO peripherals to thank for — an assembly of state machines that even let you “bitbang” high-speed interfaces like DVI. If you’re interested in how PIO functions, there are some good write-ups around here. Lacking a Pi Pico, you can use this board’s bigger sister to interface with JTAG, too.
Board space is a premium on small circuit board designs, and [Alvaro] knows it. So instead of adding a separate programming port, he’s found a niche USB-C feature that lets him use the port that he’s already added both for its primary application and for programming the target microcontroller over JTAG. The result is that he no longer needs to worry about spending precious board space for a tiny programming port; the USB-C port timeshares for both!
In a Twitter thread (Unrolled Link), [Alvaro] walks us through his discovery and progress towards an encapsulated solution. It turns out that the USB-C spec supports a “Debug-Accessory Mode” specification, where some pins are allowed to be repurposed if pins CC1 and CC2 are pulled up to Logic-1. Under these circumstances, the pin functions are released, and a JTAG programmer can step in to borrow them. To expose the port to a programmer, [Alvaro] cooked up a small breakout board with a USB-C plug and separate microcontroller populated on it.
This board also handles a small quirk. Since [Alvaro’s] choice of programming pins aren’t reversible, the USB-C plug will only work one of the two ways it can be plugged in. To keep the user informed, this breakout board sports a red LED for incorrect orientation and a green LED for correct orientation–nifty. While this design quirk sacrifices reversibility, it preserves the USB 2.0 D+ and D- pins while also handling some edge cases with regard to the negotiating for access to the port.
Stick through [Alvaro]’s Twitter thread for progress pics and more details on his rationale behind his pin choices. Who knows? With more eyes on the USB-C feature, maybe we’ll see this sort of programming interface become the norm?
[Alvaro] is no stranger to Hackaday. In fact, take a tour back to our very first Supercon to see him chat about shooting lasers at moving targets to score points on a DEFCON challenge in the past
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.
If you spend more time working with 8-bit AVR chips, don’t worry. Last year we covered a similar project to turn everyone’s favorite Linux SBC into an all-in-one microcontroller development powerhouse.
Last Fall [Kevin] wanted to program some newer TPI-only AVRs using an old USBasp he had kicking around his lab. Finding an “odd famine of information” and “forums filled with incorrect information and schematics”, he decided to set the record straight and document things correctly. He sleuthed out the details and succeeded in reprogramming the USBasp, although he did end up buying a second one in the process.
Designers who use AVR microcontrollers have no shortage of programming interfaces — we count at least five different methods: ISP/SPI, JTAG, TPI, PDI, and UPDI. We’re not sure whether this is variety is good or bad, but it is what it is. [Kevin] discovers that for the particular family of Attiny devices he is using, the ATtiny20, TPI is the only option available.
While he normally builds his designs around ARM Cortex-M chips, [Kevin] needed some glue logic and decided to go with an ATtiny20 despite its unique programming requirements. He observes that the price of the ATtiny20, $0.53 last Fall, was cheaper than the equivalent logic gates he needed. This particular chip is also quite small — only 3 mm square (a 20-pin VQFN). We would prefer not to use different MCUs and tool chains on a single board, but sometimes the convenience and economics steer the design in that direction.
If you’re not familiar with the USBasp, our own [Mike Szczys] covered the breaking story over ten years ago. And if you have a lot of free time on your hands, ditch all these nicely packaged solutions and program your chips using an old USB Hub and a 74HCT00 NAND gate as described in this bizarre hack by Teensy developer [Paul Stoffregen].