Adding WiFi To Black Magic For Wireless GDB Action

June 4, 2020 by Maya Posch 11 Comments

[Thoquz] wrote to us about an interesting GitHub project by [Valmantas Palikša] involving the porting of the Black Magic firmware to ESP8266. For those who are unaware, Black Magic Probe is firmware along with a range of official and third-party boards that targets the debugging of Cortex-M and Cortex-A MCUs and SoCs.

With this blackmagic-espidf project, one can use any ESP8266 board that has at least 2 MB of Flash program storage, though 1 MB should be possible if OTA updated are disabled. After flashing the firmware to the ESP8266 board, the GDB server can be reached on TCP port 2022 and UDP 2023, with a serial port available via TCP/23, UDP2323, or via the physical TX0/RX0 pins on the ESP8266.

The target board to be debugged is hooked up by default to GPIO0 (SWDIO) and GPIO2 (SWCLK) for Serial Wire Debugging, though JTAG is also said to be supported. If set up properly, next one should be able to pop into a fresh remote GDB session:

If you don’t want the WiFi, you can buy a wired one, or just roll your own from any STM32 board that you’ve got kicking around.

Using Valgrind To Track Down Known And Unknown Bugs In Your Code

April 29, 2020 by Maya Posch 17 Comments

We all know what bugs in code are. We don’t like them when they are in programs we use, and they’re even worse when they are in code which we have written. Clearly, the best code is bug-free, but how do we get there?

This isn’t a new question, of course, just one that has become ever more important as the total number of lines of code (LoC) that run modern day society keeps increasing and which is affecting even hobbyists more and more often now that everything has a microcontroller inside.

Although many of us know the smug satisfaction of watching a full row of green result markers light up across the board after running the unit tests for a project, the painful reality is that you don’t know whether the code really is functionally correct until it runs in an environment that is akin to the production environment. Yet how can one test an application in this situation?

This is where tools like those contained in the Valgrind suite come into play, allowing us to profile, analyze and otherwise nitpick every single opcode and memory read or write. Let’s take a look, shall we?

Continue reading “Using Valgrind To Track Down Known And Unknown Bugs In Your Code” →

Debugging For Sed — No Kidding

April 24, 2020 by Al Williams 13 Comments

If you do much Linux shell scripting, you’ve probably encountered sed — the stream editor — in an example. Maybe you’ve even used it yourself. If all you want to do is substitute text, it is easy and efficient. But if you try to do really elaborate editing, it is often difficult to get things right. The syntax is cryptic and the documentation is lacking. But thanks to [SoptikHa2] you can now debug sed scripts with a text-based GUI debugger. Seriously.

According to the author, the program has several notable features:

Preview variable values, both of them!
See how will a substitute command affect pattern space before it runs
Step through sed script – both forward and backward!
Place breakpoints and examine program state
Hot reload and see what changes as you edit source code
Its name is a palindrome

There’s only one word for that last feature: wow.

Continue reading “Debugging For Sed — No Kidding” →

A Hacker’s Guide To JTAG

April 8, 2020 by Tom Nardi 6 Comments

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.

Linux Fu: Tracing System Calls

April 7, 2020 by Al Williams 11 Comments

One of the nice things about Linux and similar operating systems is that you can investigate something to any level you wish. If a program has a problem you can decompile it, debug it, trace it, and — if necessary — even dig into the source code for the kernel and most of the libraries the program is probably using. However, the tools to do this aren’t ones you use every day. One very interesting tool is strace. Using it you can see what system calls any program makes and that can sometimes give you important clues about how the program works or, probably more often, why it doesn’t work.

Let’s consider the least complex use of the command. Suppose you want to make symlink from testxmit.grc to the /tmp directory. That command is simple:

ln -sf testxmit.grc /tmp

But if you tell strace to run it, the command becomes:

strace ln -sf testxmit.grc /tmp

You might want to redirect the output to a file using the shell or the -o option, though. Some commands generate a lot and often the first page or two of output isn’t really what you care about anyway. Continue reading “Linux Fu: Tracing System Calls” →

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 18 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]