Smartwatch Snitches On Itself And Enables Reverse Engineering

If something has a “smart” in its name, you know that it’s talking to someone else, and the topic of conversation is probably you. You may or may not like that, but that’s part of the deal when you buy these things. But with some smarts of your own, you might be able to make that widget talk to you rather than about you.

Such an opportunity presented itself to [Benjamen Lim] when a bunch of brand X smartwatches came his way. Without any documentation to guide him, [Benjamen] started with an inspection, which revealed a screen of debug info that included a mysterious IP address and port. Tearing one of the watches apart — a significant advantage to having multiple units to work with — revealed little other than an nRF52832 microcontroller along with WiFi and cellular chips. But the luckiest find was JTAG pins connected to pads on the watch face that mate with its charging cradle. That meant talking to the chip was only a spliced USB cable away.

Once he could connect to the watch, [Benjamen] was able to dump the firmware and fire up Ghidra. He decided to focus on the IP address the watch seemed fixated on, reasoning that it might be the address of an update server, and that patching the firmware with a different address could be handy. He couldn’t find the IP as a string in the firmware, but he did manage to find a sprintf-like format string for IP addresses, which led him to a likely memory location. Sure enough, the IP and port were right there, so he wrote a script to change the address to a server he had the keys for and flashed the watch.

So the score stands at [Benjamen] 1, smartwatch 0. It’s not clear what the goal of all this was, but we’d love to see if he comes up with something cool for these widgets. Even if there’s nothing else, it was a cool lesson in reverse engineering.

Fixing Issues With Knockoff Altera USB Blasters

Using an external MCU as a crude clock source for the Altera CPLD. (Credit: [Doug Brown])
One exciting feature of hardware development involving MCUs and FPGAs is that you all too often need specific tools to program them, with [Doug Brown] suffering a price tag aneurysm after checking the cost of an official Altera/Intel USB Blaster (yours for $300) to program a MAX 10 FPGA device with. This led him naturally down the path of exploring alternatives, with the $69 Terasic version rejected for ‘being too expensive’ and opting instead for the Waveshare USB Blaster V2, at a regretful $34. The amazing feature of this USB Blaster clone is that while it works perfectly fine under Windows, it works at most intermittently under Linux.

This led [Doug] down the path of reverse-engineering and diagnosing the problem, ultimately throwing in the towel and downclocking the Altera CPLD inside the adapter after finding that it was running a smidge faster than the usual 6 MHz. This was accomplished initially by wiring in an external MCU as a crude (and inaccurate) clock source, but will be replaced with a 12 MHz oscillator later on. Exactly why the problem only exists on Linux and not on Windows will remain a mystery, with Waveshare support also being clueless.

Undeterred, [Doug] then gambled on a $9 USB Blaster clone (pictured above), which turned out to be not only completely non-functional, but also caused an instant BSOD on Windows, presumably due to the faked FTDI USB functionality tripping up the Windows FTDI driver. This got fixed by flashing custom firmware by [Vladimir Duan] to the WCH CH552G-based board after some modifications shared in a project fork. This variety of clone adapters can have a range of MCUs inside, ranging from this WCH one to STM32 and PIC MCUs, with very similar labels on the case. While cracking one open we had lying around, we found a PIC18 inside, but if you end up with a CH552G-based one, this would appear to fully fix it. Which isn’t bad for the merest fraction of the official adapter.

Thanks to [mip] for the tip.

Pi with the PiFEX shield on the right, the SSD under test on the left with testpoints held by a jumper clip, jumper wires connecting the two together

JTAG Hacking An SSD With A Pi: A Primer

[Matthew “wrongbaud” Alt] is well known around these parts for his hardware hacking and reverse-engineering lessons, and today he’s bringing us a JTAG hacking primer that demoes some cool new hardware — the PiFEX (Pi Interface Explorer). Ever wondered about those testpoint arrays on mSATA and M.2 SSDs? This write-up lays bare the secrets of such an SSD, using a Pi 4, PiFEX, OpenOCD and a good few open-source tools for JTAG probing that you can easily use yourself.

The PiFEX hat gives you level-shifted bidirectional GPIO connectors for UART, SPI, I2C, JTAG, SWD and potentially way more, an OLED screen to show any debugging information you might need, and even a logic analyzer header so that you can check up on your reverse-engineering progress.

Continue reading “JTAG Hacking An SSD With A Pi: A Primer”

Showing the ESP-Prog-Adapter board plugged into the ESP-Prog adapter, wired to a SOIC clip, that then attaches to a PCB under test

ESP-Prog-Adapter Makes Your ESP32 Tinkering Seamless

Did you ever struggle with an ESP32 board of yours, wishing you had exposed that UART, or seriously lacking the JTAG port access? If so, you should seriously check out [0xjmux]’s ESP-PROG-Adapter project, because [0xjmux] has put a lot of love and care into making your ESP32 hardware interfacing a breeze. This project shows you how to add JTAG and UART headers with extra low board footprint impact, gives you a KiCad library to do so super quickly, and shares a simple and helpful adapter PCB you can directly use with the exceptionally cheap Espressif’s ESP-Prog dongle you should have bought months ago.

The hardware is perfect for ZIF no-soldering interfacing – first of all, both UART and JTAG can be connected through a SOICBite connection, a solderless connector idea that lets you use SPI flashing clips on specially designed pads at the edge of your board. For the fancy toolkit hackers among us, there’s also a Tag Connect symbol suggested and a connector available, but it carries JTAG that you will already get with the SOICBite, so it’s maybe not worth spending extra money on.

Everything is fully open-source, as one could hope! If you’re doing ESP32 hacking, you simply have to order this board and a SOIC clip to go with it, given just how much trouble [0xjmux]’s board will save you when programming or debugging your ESP32 devices. Now, you don’t strictly need the ESP-Prog dongle – you could remix this into an adapter for the Pi Pico board instead. Oh, and if designing boards with ARM CPUs are your thing, you might benefit from being reminded about the Debug Edge standard!

37C3: When Apple Ditches Lightning, Hack USB-C

[Thomas Roth], aka [Ghidraninja], and author of the [Stacksmashing] YouTube channel, investigated Apple’s Lightning port and created a cool debugging tool that allowed one to get JTAG on the device. Then, Apple went to USB-C for their new phones, and all his work went to waste. Oh well, start again — and take a look at USB-C.

Turns out, though, that the iPhone 15 uses the vendor-defined messages (VDM) capability of USB-PD to get all sorts of fun features out. Others had explored the VDM capabilities on Mac notebooks, and it turns out that the VDM messages on the phone are the same. Some more fiddling, and he got a serial port and JTAG up and running. But JTAG is locked down in the production devices, so that will have to wait for an iPhone 15 jailbreak. So he went poking around elsewhere.

He found some other funny signals that turned out to be System Power Management Interface (SPMI), one of the horribly closed and NDA-documented dialects owned by the MIPI Alliance. Digging around on the Interwebs, he found enough documentation to build an open-source SPMI plugin that he said should be out on his GitHub soon.

The end result? He reworked his old Lightning hardware tool for USB-C and poked around enough in the various available protocols to get a foothold on serial, JTAG, and SPMI. This is just the beginning, but if you’re interested in playing with the new iPhone, this talk is a great place to start. Want to know all about USB-C? We’ve got plenty of reading for you.

Using JTAG To Dump The Xbox’s Secret Boot ROM

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.

Dumping script window, showing the bytes being dumped one by one from the STM chip

Need To Dump A Protected STM32F0x? Use Your Pico!

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.