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
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.
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”→
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.
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.
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.
[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.
