Local And Remote Debugging With GDB

As a debugger, GDB is a veritable Swiss Army knife. And just like exploring all of the non-obvious uses of a those knives, your initial response to the scope of GDB’s feature set is likely to be one of bewilderment, subsequent confusion, and occasional laughter. This is an understandable reaction in the case of the Swiss Army knife as one is unlikely to be in the midst of an army campaign or trapped in the wilderness. Similarly, it takes a tricky debugging session to really learn to appreciate GDB’s feature set.

If you have already used GDB to debug some code, it was likely wrapped in the comfort blanket of an IDE. This is of course one way to use GDB, but limits the available features to what the IDE exposes. Fortunately, the command line interface (CLI) of GDB has no such limitations. Learning the CLI GDB commands also has the advantage that one can perform that critical remote debug session even in the field via an SSH session over the 9600 baud satellite modem inside your Swiss Army knife, Cyber Edition.

Have I carried this analogy too far? Probably. But learning the full potential of GDB is well worth your time so today, let’s dive in to sharpen our digital toolsets.

Continue reading “Local And Remote Debugging With GDB”

A Hacker’s Guide To JTAG

If you’re reading Hackaday, you’ve almost certainly heard of JTAG. There’s an excellent chance you’ve even used it once or twice to reflash an unruly piece of hardware. But how well do you actually know JTAG? More specifically, do you know how useful it can be when reverse engineering hardware?

Whether you’re a JTAG veteran or a novice, this phenomenal guide written by [wrongbaud] is sure to teach you a thing or two. Starting with a low-level explanation of how the interface actually works, the guide takes you though discovering JTAG ports on unknown targets, the current state-of-the-art in open source tools to interact with the device, and finally shows a real-world example of pulling and analyzing a gadget’s firmware.

There’s no way to do his write-up justice with a breakdown or a summary, so we won’t even try. Just get comfortable, maybe grab a drink, and dive in. It’s certainly not a short read, but there isn’t a wasted word on the page. Every piece of the puzzle, from how to figure out an unlabeled pinout to determining the instruction length, is explained in exactly the amount of detail you’re looking for. This is a guide for hackers written by a hacker, and it shows.

It will probably come as no surprise to find this isn’t the first time [wrongbaud] has done a deep dive like this. Over the last few months we’ve been covering his series of practical reverse engineering guides, and each one has been an invaluable resource. Perfect study guides for when a global pandemic has you stuck in the house.

Xbox Controller Provides Intro To SWD Hacking

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.

The Serial Wire Debug architecture.

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.

Parallel Pis For Production Programming; Cutting Minutes And Dollars Off Of Assembly

Assembly lines for electronics products are complicated beasts, often composed of many custom tools and fixtures. Typically a microcontroller must be programmed with firmware, and the circuit board tested before assembly into the enclosure, followed by functional testing afterwards before putting it in a box. These test platforms can be very expensive, easily into the tens of thousands of dollars. Instead, this project uses a set of 12 Raspberry Pi Zero Ws in parallel to program, test, and configure up to 12 units at once before moving on to the next stage in assembly.

Continue reading “Parallel Pis For Production Programming; Cutting Minutes And Dollars Off Of Assembly”

Debug Superpowers Bring An STM32 Back From The Dead

When a processor has a fault it can leave what looks to be precious little in the way of cause and effect. Debug-by-print-statement works surprisingly well in simple cases, but where in a desktop environment you would drop into a debugger to solve trickier problems this can be an onerous task on an embedded system. [Ross Schlaikjer]’s excellent blog post walks through setting up one of our favorite Open Hardware debug probes and shows us that with the right tooling in place, unexpected faults aren’t quite so impenetrable. Continue reading “Debug Superpowers Bring An STM32 Back From The Dead”

Stepping Through Code On A Pace 4000 Set Top Box

[Lee] wrote in to tell us about a Set Top Box he hacked. Before the cable industry lawyers get out their flaming swords… he’s not stealing cable, or really doing much of anything. This is a hack just for the adventure and thrill of making someone else’s hardware design do your bidding without any kind of instructions.

He posted about the adventure in two parts. The first is finding the JTAG header and identifying the pins. Arduino to the rescue! No really, and this is the type of Arduino use we love. Using a package called JTAGenum the board becomes a quick tool for probing and identifying JTAG connections.

The image above shows a different piece of hardware. From looking at it we’re pretty sure this is a Bus Blaster which is specifically designed for JTAG debugging with ARM processors. This is the beginning of the second part of his documentation which involves code dumping and stepping through lines code (or instructions) using OpenOCD and GDB. It’s a chore to follow all that [Lee] discovered just to write his name to the display of the box. But we certainly found it interesting. The display has a convoluted addressing scheme. We assume that there are cascading shift registers driving the segments and that’s why it behaves the way it does. Take a look for yourself and let us know what you think in the comments.

Stealing WiFi From LED Lightbulbs

LIFX Wireless LED PCB

Back in 2012, the LIFX light bulb launched on Kickstarter, and was quite successful. This wireless LED lightbulb uses a combination of WiFi and 6LoWPAN to create a network of lightbulbs within your house. Context Information Security took a look into these devices, and found some security issues.

The LIFX system has a master bulb. This is the only bulb which connects to WiFi, and it sends all commands out to the remaining bulbs over 6LoWPAN. To keep the network up, any bulb can become a master if required. This means the WiFi credentials need to be shared between all the bulbs.

Looking into the protocol, an encrypted binary blob containing WiFi credentials was found. This binary could easily be recovered using an AVR Raven evaluation kit, but was not readable since it was encrypted.

After cracking a bulb apart, they found JTAG headers on the main board. A BusBlaster and OpenOCD were used to communicate with the chip. This allowed the firmware to be dumped.

Using IDA Pro, they determined that AES was being used to encrypt the WiFi credentials. With a bit more work, the key and initialization vector was extracted. With this information, WiFi credentials sent over the air could be decrypted.

The good news is that LIFX fixed this issue. Now they generate an encryption key based on WiFi credentials, preventing a globally unique key from being used.

[via reddit]