People are well aware of the power of virtual machines. If you want to do something dangerous — say, hack on the kernel — you can create a virtual machine, snapshot it, screw it up a few times, restore it, and your main computer never misses a beat. But sometimes you need just a little shift in perspective, not an entire make belive computer. For example, you are building a new boot disk and you want to pretend it is the real boot disk and make some updates. For that there is chroot, a Linux command that lets you temporarily open processes that think the root of the filesystem is in a different place than the real root. The problem is, it is hard to manage a bunch of chroot environments which is why they created Atoms.
The system works with several common distributions and you install it via Flatpak. That means you can launch, for example, a shell that thinks it is running Gentoo or Centos Linux under Ubuntu.
In the old days, if you wanted to snoop on a piece of serial gear, you probably had a serial monitor or, perhaps, an attachment for your scope or logic analyzer. Today, you can get cheap logic analyzers that can do the job, but what if you want a software-only solution? Recently, I needed to do a little debugging on a USB serial port and, of course, there isn’t really anywhere to easily tie in a monitor or a logic analyzer. So I started looking for an alternate solution.
If you recall, in a previous Linux Fu we talked about pseudoterminals which look like serial ports but actually talk to a piece of software. That might make you think: why not put a piece of monitor software between the serial port and a pty? Why not, indeed? That’s such a good idea that it has already been done. When it works, it works well. The only issue is, of course, that it doesn’t always work.
[Michael Lynch] recently replaced his Synology NAS with a self-built solution built on ZFS, a filesystem with a neat feature: the ability to back up encrypted data without having to decrypt it first. The only glitch is that [Michael] is using TrueNAS, and TrueNAS only wants to back up unencrypted ZFS data to another TrueNAS system. Fortunately, there’s a way around this that isn’t particularly complicated, but definitely requires leveraging the right tools. It also provides an educational walkthrough for how ZFS handles these things.
The solution is a small handful of shell scripts to manage full and incremental backups and restores of encrypted datasets, without having to decrypt the data first. As mentioned, this is something TrueNAS will handle by default, but only if the destination is also a TrueNAS system. Now, [Michael] can send that backup to off-site cloud storage with only a little extra work.
There’s one additional trick [Michael] uses to monitor his backups. He leverages a paid (but with a free tier) service called Cronitor. It’s not very obvious from the site’s features, but there is a way to implement cron job monitoring that doesn’t require adding any software whatsoever. Here’s how that part works: Cronitor provides a custom, unique URL. If that URL isn’t visited regularly (for example, because the cron job fails), then the user is notified. By integrating this into an existing cron job, one can be notified. Such an integration would look like this:
In short, if the cron job runs successfully, curl checks in by visiting the custom URL. If that doesn’t happen, the user gets a notification. No added software, just a simple leveraging of a free service for some added peace of mind.
You’ve probably heard about Google Chromebooks. Like Android, Chrome OS is based on some variant of Linux, but it is targeted at the “cloud first” strategy so Chromebooks typically don’t have a huge amount of storage or compute power. If you have a real Chromebook, you can also use it to run certain other kinds of programs via virtualization. However, Google has recently pushed out Chrome OS Flex which is meant to install on a spare laptop you might happen to have hanging around. Seems attractive to take that only Windows 7 laptop and repurpose it to run Chrome OS, especially if you can run Linux apps on it. Unfortunately, Chrome OS Flex has a very different use case and I would only recommend installing it if you meet the exact use case it addresses.
The other option, of course, is to just install Linux on that old hardware. There are several distributions that are made for that purpose and, honestly, even most of the major distributions will work fine on older hardware with a little tweaking to turn off some of the more resource-costly features. That assumes you know how to install, tweak, and maintain Linux.
Sometimes a problem seems hard, but the right insight can make it easy. If you were asked to write a program to compare two PDF files and show the differences, how hard do you think that would be? If you are [serhack], you’ll make it much easier than you might guess.
Of course, sometimes making something simple depends on making simplifying assumptions. If you are expecting a “diff-like” utility that shows insertion and deletions, that’s not what’s going on here. Instead, you’ll see an image of the PDF with changes highlighted with a red box. This is easy because the program uses available utilities to render the PDFs as images and then simply compares pixels in the resulting images, drawing red boxes over the parts that don’t match.
Typewriters may be long past their heyday, but just because PCs, word processor software, and cheap printers have made them largely obsolete doesn’t mean the world is better off without them. Using a typewriter is a rich sensory experience, from the feel of the keys under your fingers that even the clickiest of PC keyboards can’t compare with, to the weirdly universal sound of the type hitting paper.
So if life hands you a typewriter, why not put it back to work? That’s exactly what [Artillect] did by converting an 80s typewriter into a Linux terminal. The typewriter is a Brother AX-25, one of those electronic typewriters that predated word processing software and had a daisy wheel printhead, a small LCD display, and a whopping 8k of memory for editing documents. [Artillect] started his build by figuring out which keys mapped to which characters in the typewriter’s 8×11 matrix, and then turning an Arduino and two multiplexers loose on the driving the print head. The typewriter’s keyboard is yet used for input, as the project is still very much in the prototyping phase, so a Raspberry Pi acts as a serial monitor between the typewriter and a laptop. The video below has a good overview of the wiring and the software, and shows the typewriter banging out Linux command line output.
For now, [Artillect]’s typewriter acts basically like an old-school teletype. There’s plenty of room to take this further; we’d love to see this turned into a cyberdeck complete with a built-in printer, for instance. But even just as a proof of concept, this is pretty great, and you can be sure we’ll be trolling the thrift stores and yard sales looking for old typewriters.
[greenluigi1] bought a Hyundai Ioniq car, and then, to our astonishment, absolutely demolished the Linux-based head unit firmware. By that, we mean that he bypassed all of the firmware update authentication mechanisms, reverse-engineered the firmware updates, and created subversive update files that gave him a root shell on his own unit. Then, he reverse-engineered the app framework running the dash and created his own app. Not just for show – after hooking into the APIs available to the dash and accessible through header files, he was able to monitor car state from his app, and even lock/unlock doors. In the end, the dash got completely conquered – and he even wrote a tutorial showing how anyone can compile their own apps for the Hyundai Ionic D-Audio 2V dash.
In this series of write-ups [greenluigi1] put together for us, he walks us through the entire hacking process — and they’re a real treat to read. He covers a wide variety of things: breaking encryption of .zip files, reprogramming efused MAC addresses on USB-Ethernet dongles, locating keys for encrypted firmware files, carefully placing backdoors into a Linux system, fighting cryptic C++ compilation errors and flag combinations while cross-compiling the software for the head unit, making plugins for proprietary undocumented frameworks; and many other reverse-engineering aspects that we will encounter when domesticating consumer hardware.
This marks a hacker’s victory over yet another computer in our life that we aren’t meant to modify, and a meticulously documented victory at that — helping each one of us fight back against “unmodifiable” gadgets like these. After reading these tutorials, you’ll leave with a good few new techniques under your belt. We’ve covered head units hacks like these before, for instance, for Subaru and Nissan, and each time it was a journey to behold.