UScope: A New Linux Debugger And Not A GDB Shell, Apparently

[Jim Colabro] is a little underwhelmed with the experience of low-level debugging of Linux applications using traditional debuggers such as GDB and LLDB. These programs have been around for a long time, developing alongside Linux and other UNIX-like OSs, and are still solidly in the CLI domain.  Fed up with the lack of data structure support and these tools’ staleness and user experience, [Jim] has created UScope, a new debugger written from scratch with no code from the existing projects.

GBD, in particular, has quite a steep learning curve once you dig into its more advanced features. Many people side-step this learning curve by running GDB within Visual Studio or some other modern IDE, but it is still the same old debugger core at the end of the day. [Jim] gripes that existing debuggers don’t support modern data structures commonly used and have poor customizability. It would be nice, for example, to write a little code, and have the debugger render a data structure graphically to aid visualisation of a problem being investigated. We know that GDB at least can be customised with Python to create application-specific pretty printers, but perhaps [Jim] has bigger plans?

Continue reading “UScope: A New Linux Debugger And Not A GDB Shell, Apparently”

The printer's display with the exploit-loaded animation playing, saying "hacked by blasty" and a bunch more stuff

A Fun Exploit For Canon Printers Brings GDB Gifts

Modern printers make it all that much more tempting to try and hack them — the hardware generally tends to be decent, but the firmware appears to be designed to squeeze as much money out of you as possible while keeping your annoyance level consistently high. That’s why it’s nice to see this exploit of the Canon imageCLASS MF74XCdw series (MF742Cdw/MF743Cdw) by [blasty], triggerable over a network connection, with a story for our amusement.

In this post, we get a tale of how this hack came out of a Pwn2Own Toronto challenge, notes on the hardware involved, and we’re shown the journey to a successful hack. The Canon printer OS is built without many of the protections, which makes playing with it easier than with more modernized targets, but it’s nevertheless not straightforward. Still, exploiting a couple things like the SOAP XML implementation and the UTF8 encoder nets you an ability to play nice animations on the display, and most certainly, control over the entirety of the hardware if you wanted it.

One of the most fun things about this hack is the GDB stub recently included in the repo. If you wanted to debug Canon printers for fun or profit, [blasty] brings you a GDB stub to do that comfortably, with a respectable README that even has porting notes for other Canon ImageCLASS printer models, should you lay your hands on a different machine of despair. WiFi connectivity appears to be enough for this hack, so you better make sure you don’t have your network-connected printers exposed on the Internet — not that you needed more reasons to avoid that.

Linux Fu: Up Your GDB Game!

If you want to buy a car, there are plenty of choices. If you want to buy a jetliner, there are fewer choices. If you want to use the Large Hadron Collider, you have a choice of exactly one. The harder something is to create, the less likely there is to be many of them. If you are looking for a Linux debugger, there are only a few choices, but gdb is certainly the one you will find most often. There is lldb and a handful of non-open commercial offerings, but for the most part you will use gdb to debug software on Linux.

Of course, not everyone’s a fan of gdb’s text-based interface, so there’s no shortage of front ends available for it. In fact, gdb has two potentially built-in interfaces although depending on how you install gdb, you might not have both of them. Of course, if you use an IDE, it very likely is a front end for gdb among other things. But at the core is gdb and — usually — there is a window somewhere that you can stuff gdb commands into. Even emacs — which might be considered the original IDE — can run gdb and gives you a sort-of GUI experience.

Continue reading “Linux Fu: Up Your GDB Game!”

Hacked GDB Dashboard Puts It All On Display

Not everyone is a fan of GUI interfaces. But some tasks really lend themselves to something over a bare command line. Very few people enjoy old command line text editors like edlin or ed. Debugging is another task where showing source files and variables at all times makes sense. Of course, you don’t absolutely have to have a GUI per se. You can also use a Text User Interface (TUI). In fact, you can build gdb — the GNU Debugger — with a built-in TUI mode. Try adding –tui to your gdb command line and see what happens. There are also many GUI frontends for gdb, but [cyrus-and] has an easy way to get a very useful TUI-like interface to gdb that doesn’t require rebuilding gdb or even hacking its internals in any way.

The secret? The gdb program runs a .gdbinit file on startup. By using Python and some gdb commands, [cyrus-and] causes the debugger to have a nice dashboard interface for your debugging sessions. If you install a helper script, you can even get syntax highlighting.

The system uses modules and you can even add your own custom modules and commands, if you like. You can also control what modules appear on each dashboard display. Normally, the dashboard shows when the program stops. For example, on each breakpoint. However, gdb has a hook system that allows you to trigger a dashboard using the appropriately-named dashboard command on other commands, too. Using the layout option to the dashboard command, you can even trigger different modules at different times.

Installation is simple. Just put the .gdbinit file in your home directory. If you want syntax highlights, you need to install Pygments, too. We understand you can even use his under Windows, if you like.

We don’t always take full advantage, but gdb is actually amazing. The flexible architecture makes all sorts of interesting things possible.

Screenshot of debugging the Wokwi Arduino simulator

Digging Into An ATtiny Simulator Bug With GDB

Being able to track down a bug in a mountain of source code is a skill in its own right, and it’s a hard skill to learn from a book or online tutorial. Besides the trial-by-fire of learning while debugging your own project, the next best thing is to observe someone else’s process. [Uri Shaked] has given us a great opportunity to brush up on our debugging skills, as he demonstrates how to track down and squish a bug in the Wokwi Arduino simulator.

A user was kind enough to report the bug and include the offending Arduino sketch. [Uri]’s first step was to reduce the sketch to the smallest possible program that would still produce the bug.

Once a minimal program had been produced, it was time to check whether the problem was in one of the Arduino libraries or in the Wokwi simulator. [Uri] compiled the sketch, loaded it onto a ATtiny85, and compared the behavior of the simulator and the real thing. It turns out the code ran just fine on a physical ATtiny, so the problem must have been in the Arduino simulator itself.

To track down the bug in the simulator, [Uri] decided to break out the big gun—GDB. What follows is an excellent demonstration of how to use GDB to isolate a problem by examining the source code and using breakpoints and print statements. In the end, [Uri] managed to isolate the problem to a mis-placed bit in the simulation of the timer/counter interrupt flag register.

If you’d like to see more of [Uri]’s debugging prowess, check out his dive into an ATtiny’s write protection and configuration fuses. If you’ve been wowed by the power of GDB and want to learn more, check out this quick tutorial!

Continue reading “Digging Into An ATtiny Simulator Bug With GDB”

Gdbdiff: Diff-ing A Real RP2040 MCU Against An Emulated MCU

What to do when developing an RP2040 emulator but validating the emulator instruction by instruction is a slow and tedious process? Why, automatically compare it against the real hardware if you’re [Uri Shaked], of course. This is the purpose of gdbdiff. This project uses the GDB remote serial protocol via OpenOCD to run test firmware step by step.

During a livestream (video linked via the above link), this allowed [Uri] to find a number of instruction bugs in the emulator this way. These issues involved issues such as incorrect flags in the APSR register and an edge case in the LSRS register. This gdbdiff livestream is part of an entire series of live-coding sessions during which [Uri] writes an RP2040 emulator from scratch.

We applaud [Uri] for creative thinking here, and assume that this way the livestream was probably more entertaining to watch than when doing instruction-level debugging purely by hand :)

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”