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”

Adding WiFi To Black Magic For Wireless GDB Action

[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:

gdb connection

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.