Debugging Electronics: To Know Why It Didn’t Work, First Find What It Is Actually Doing

March 5, 2020 by Roger Cheng 10 Comments

Congratulations, you have just finished assembling your electronics project. After checking for obvious problems you apply power and… it didn’t do what you wanted. They almost never work on the first try, and thus we step into the world of electronics debugging with Daniel Samarin as our guide at Hackaday Superconference 2019. The newly published talk video embedded below.

Beginners venturing just beyond blinking LEDs and premade kits would benefit the most from information here, but there are tidbits useful for more experienced veterans as well. The emphasis is on understanding what is actually happening inside the circuit, which explains the title of the talk: Debugging Electronics: You Can’t Handle the Ground Truth! So we can compare observed behavior against designed intent. Without an accurate understanding, any attempted fix is doomed to failure.

To be come really good at this, you need to embrace the tools that are often found on a well stocked electronics bench. Daniel dives into the tricks of the trade that transcend printf and blinking LED to form a plan to approach any debugging task.

Continue reading “Debugging Electronics: To Know Why It Didn’t Work, First Find What It Is Actually Doing” →

The Newbie’s Guide To JTAG

February 24, 2020 by Dan Maloney 16 Comments

Do you even snarf?

If not, it might be because you haven’t mastered the basics of JTAG and learned how to dump, or snarf, the firmware of an embedded device. This JTAG primer will get you up to snuff on snarfing, and help you build your reverse engineering skills.

Whatever your motivation for diving into reverse engineering devices with microcontrollers, JTAG skills are a must, and [Sergio Prado]’s guide will get you going. He starts with a description and brief history of the Joint Test Action Group interface, from its humble beginnings as a PCB testing standard to the de facto standard for testing, debugging, and flashing firmware onto devices. He covers how to locate the JTAG pads – even when they’ve been purposely obfuscated – including the use of brute-force tools like the JTAGulator. Once you’ve got a connection, his tutorial helps you find the firmware in flash memory and snarf it up to a file for inspection, modification, or whatever else you have planned.

We always appreciate guides like these that cover the basics, since not everyone is in the same place in their hardware hacking journey. This puts us in the mood to crack something open and start looking for pins, if for no other reason than to get some practice.

[Thumbnail image source: LufSec]

Xbox Controller Provides Intro To SWD Hacking

February 11, 2020 by Tom Nardi 12 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.

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.

The Multiyear Hunt For A Gameboy Game’s Bug

January 31, 2020 by Al Williams 7 Comments

[Enddrift] had a real problem trying to run a classic game, Hello Kitty Collection: Miracle Fashion Maker, into a GBA (Gameboy Advance) emulator. During startup, the game would hit an endless loop waiting for a read from a non-existent memory location and thus wouldn’t start under the emulator. The problem is, the game works on real hardware even though that memory doesn’t exist there, either.

To further complicate things, a similar bug exists when loading a saved game under Sonic Pinball Party. Then a hack for Pokemon Emerald surfaced that helped break the case. The story is pretty interesting.

Continue reading “The Multiyear Hunt For A Gameboy Game’s Bug” →

Linux Fu: Debugging Bash Scripts

December 11, 2019 by Al Williams 23 Comments

A recent post about debugging constructs surprised me. There were quite a few comments about how you didn’t need a debugger, as long as you had printf. For that matter, we’ve all debugged systems where you had nothing but an LED to flash or otherwise turn on to communicate with the user. However, it is hard to deny that a debugger can help with complex code.

To say you only need printf would be like saying you only need machine language. Technically accurate — you can do anything in machine language. But it sure makes things easier to have an assembler or some language to help you work out your problem. If you write a simple bash script, you can use the equivalent to printf — maybe that’s the echo command, although there is usually a printf command on a typical system, if you want to use it. However, there are other things you can do with bash including a pretty cool debugger if you know how to find it.

I assume you already know how to use echo and printf, but let’s dig into how to use trace execution line by line without the need for echo statements on every other line. Along the way, you’ll learn how to get started with the bash debugger.

Continue reading “Linux Fu: Debugging Bash Scripts” →

Finding USB Bugs The Hard Way

October 20, 2019 by Sharon Lin 17 Comments

Sometimes debugging just doesn’t go the way you want it to. When USB problems arise, you can usually use a protocol analyzer to find the issue causing trouble. For [Paul Stoffregen], it was only the first step in a long process to find the culprit.

Procotol Analyzer

The complaint that came up was from a customer whose 2 port USB hub wasn’t working on their Teensy 3.6. The hub had been tested on Linux, Mac, and Windows, so it made sense to test what was different about the Teensy. Furthermore, all other USB hubs worked on the Teensy. As it turns out, these weren’t the most helpful assumptions to make when finding the bug.

Any protocol analyzer can be used, for instance the Beagle480. The way it works is by passing through USB communication, making a copy of the communication coming in and out, and sending it to the PC.

Normally, the analyzer has a small buffer memory and must sustain fast data flow. Unfortunately, this can occasionally cause software lockup. From what could be gathered from the verbose printing, USB descriptors were found for the hub. As it turns out, the faulty hub was a Multi-TT type hub, while most others are single TT (transaction translator).

Fixing Software Lockup

Since it was necessary to get the rest of the descriptor data, fixing the software lockup was the next step. Writing in a panic function – a breakpoint of sorts – into the code allowed the USB host’s power to terminate, and stepping through the program revealed that while the 2 port hub was initially being read, some issue arose afterwards.

As it turns out, the issue relied on USB split transactions, used only between USB hosts and hubs. Communication happens by tokens, which begins with a SPLIT-START token.

As it turns out, the issue was that the tokens weren’t being sent in the correct order. The other hubs seemed to be handle this nevertheless. By applying a fix to the C++ code of the bad hub, which had previously not been implementing the data structure for accessing register properly, the hub was able to work again.The hub appeared to be rejecting bad token, which was causing the issue in the first place.

All in all, while I’m sure this had to be a head scratching experience, at least it gives us some insight into the low-level design of USB communication.

Supercon: Ruth Grace Wong And Firmware From The Firehose

February 22, 2019 by Elliot Williams 13 Comments

Firmware and software are both just code, right? How different could the code that runs Internet-scale distributed web stuff be from the code that runs a tiny microcontroller brain inside a personal hydroponics device? Night and day!

Ruth Grace Wong works in the former world, but moonlights as a manufacturing engineer with some friends. Their product had pre-existing firmware that contained (at least) one bug, and Ruth’s job was to find it. The code in question was written by the Chinese PCB engineer, who knew the electronics intimately but who had no software background, providing Ruth an opportunity to jump head-first into the rawest of raw embedded programming. Spoiler alert: she found the bug and learned a lot about firmware along the way. This talk follows her along the adventure.

“The code is very well documented, in Chinese” but the variable names are insanely non-descriptive. Similarly, while the PCB engineer knows full well what a 24C02 is, if you’re a software geek that might as well be Chinese. As you’d expect, web searches came to the rescue on both fronts.

The bug ended up hiding in a logical flaw in the PWM-setting code inside an interrupt service routine, and it kept the fan from ever coming full on. Once found, it was easily fixed. But getting to the point where you understand the codebase deeply enough to know where to look is four-fifths of the battle. Heck, setting up the toolchain alone can take a day or two.

If you’re a fellow software type, Ruth’s talk (embedded below) will give you a quick glimpse into the outer few layers of the onion that is embedded firmware development, from a familiar viewpoint. Give her quick and value-packed talk a watch! Grizzled hardware veterans will nod along, and maybe even gain a little insight into how our code looks to “them”.

Continue reading “Supercon: Ruth Grace Wong And Firmware From The Firehose” →