Serial ports used to be everywhere. In a way, they still are since many things that appear to plug in as a USB device actually look like a serial port. The problem is that today, the world runs on the network. Sure, you can buy a terminal server that converts a serial port to an Ethernet port, but what fun is that? In this article, I’m going to show you how to stream serial ports over the network using some available Linux tools. It isn’t perfect, and it won’t work for every case, but when it works it works well.
Everything is a File, Until it Isn’t
At some point in the past, Unix — the progenitor of Linux — treated virtually everything as a file, and all files were created more or less equal. Programs didn’t care if a file was local, on the network, from a tape drive, or arriving over a named pipe.
But things started to change. Even though a serial port is just a file under Linux, it has some special attributes that let you set, for example, baud rates. Worse, some programs “know” too much about files and insist on certain naming conventions. So, in theory, you should be able to create a network socket, connect one end to a serial port and the other end to a program, and be done with it. In theory.
We’re guessing that we have something in common with a substantial number of our readers in that this post is being written on an open-source operating system. A well-known GNU/Linux distribution provides everything you might expect from a PC, but of course it’s not the only open-source game in town. A year-old piece from [Unixsheikh] caught the eye with the title “Why you should migrate everything from Linux to BSD“, and being naturally curious, it was worth a read. It’s interesting enough to talk about here not because of its BSD advocacy, but because of its examination of some of GNU/Linux’s shortcomings. Using and appreciating an operating system shouldn’t mean slavish fandom, it’s worth every Linux user taking a moment to consider its points. Continue reading “Holding A Mirror Up In Front Of GNU/Linux”→
For the impatient Nissan owners who may be joining us from Google, a hacker by the name of [ea] has figured out how to get a root shell on the Bosch LCN2kai head unit of their 2015 Xterra, and it looks like the process should be the same for other vehicles in the Nissan family such as the Rogue, Sentra, Altima, and Frontier. If you want to play along at home, all you have to do is write the provided image to a USB flash drive and insert it.
Now for those of us who are a more interested in how this whole process works, [ea] was kind of enough to provide a very detailed account of how the exploit was discovered. Starting with getting a spare Linux-powered head unit out of a crashed Xterra to experiment with, the write-up takes the reader through each discovery and privilege escalation that ultimately leads to the development of a non-invasive hack that doesn’t require the user to pull their whole dashboard apart to run.
The early stages of the process will look familiar to anyone who’s messed with embedded Linux hacking. The first step was to locate the board’s serial port and connect it to the computer. From there, [ea] was able to change the kernel parameters in the bootloader to spawn an interactive shell. To make things a little easier, the boot scripts were then modified so the system would start up an SSH server accessible over a USB Ethernet adapter. With full access to the system, the search for exploits could begin.
A simple script on the flash drive enables the SSH server.
After some poking, [ea] discovered the script designed to mount USB storage devices had a potential flaw in it. The script was written in such a way that the filesystem label of the device would be used to create the mount point, but there were no checks in place to prevent a directory traversal attack. By crafting a label that read ../../usr/bin/ and placing a Bash script on the drive, it’s possible to run arbitrary commands on the head unit. The provided script permanently adds SSHd to the startup process, so when the system reboots, you’ll be able to log in and explore.
So what does [ea] want to do with this new-found exploit? It looks like the goal is to eventually come up with some custom programs that extend the functionality of the in-dash Linux system. As it seems like these “infotainment” systems are now an inescapable feature of modern automobiles, we’re certainly excited to see projects that aim to keep them under the consumer’s control.
We are extraordinarily fortunate to live at a time in which hardware with astounding capabilities can be had for only a few dollars. Systems that would once have taken an expensive pile of chips and discretes along with months of development time to assemble are now integrated onto commodity silicon. Whether it is a Linux-capable system-on-chip or a microcontroller, such peripherals as WiFi, GPUs, Bluetooth, or USB stacks now come as part of the chip, just another software library rather than a ton of extra hardware.
Beware The Blob!
The cheapest of chips still comes with a blob.
If there is a price to be paid for this convenience, it comes in the form of the blob. A piece of pre-compiled binary software that does the hard work of talking to the hardware and which presents a unified API to the software. Whether you’re talking to the ESP32 WiFi through an Arduino library or booting a Raspberry Pi with a Linux distribution, while your code may be available or even maybe open source, the blob it relies upon to work is closed source and proprietary. This presents a challenge not only to Software Libre enthusiasts in search of a truly open source computer, but also to the rest of us because we are left reliant upon the willingness of the hardware manufacturer to update and patch their blobs.
An open-source advocate would say that the solution is easy, the manufacturers should simply make their blobs open-source. And it’s true, were all blobs open-source then the Software Libre crowd would be happy and their open-source nature would ease the generation of those updates and patches. So why don’t manufacturers release their blobs as open-source? In some cases that may well be due to a closed-source mindset of never releasing anything to the world to protect company intellectual property, but to leave it at that is not a full answer. To fully understand why that is the case it’s worth looking at how our multifunctional chips are made.
Though it was famously started by Linus Torvalds as “a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones“, the Linux kernel and surrounding operating system ecosystems have been ported to numerous architectures beyond their x86 roots. It’s therefore not unusual to hear of new ports for unsupported platforms, but it is extremely unexpected to hear of one when the platform is a games console from the mid-1990s. But that’s what [Lauri Kasanen] has done, announcing a fresh Linux port for the Nintendo 64.
This isn’t a Linux from 1996 either. The port builds on an up-to-date kernel version 5.10 with his N64 branch and a tantalising possibility that it might be incorporated into the main Linux source for the MIPS-64 processor architecture. That’s right, the Nintendo 64 could be an officially supported Linux platform.
It would be stretching the story a long way to call this any kind of distro, for what he’s produced is a bootloader that loads the kernel and creates a terminal with busybox loaded. With this on your flashcart you won’t be replacing that Raspberry Pi any time soon, so why other than [Lauri]’s “because I can” would you be interested in it? He supplies the answer and it lies in the emulation scene, because having a Linux for the platform makes it so much easier to port other software to it. If this tickles your fancy you can see the source in his GitHub repository, and we’re certainly looking forward to what the community will do with it.
Creality, makers of the Ender series of 3D printers, have released a product called Wi-Fi Box meant to cheaply add network control to your printer. Naturally I had to order one so we could take a peek, but this is certainly not a product review. If you’re looking to control your 3D printer over the network, get yourself a Raspberry Pi and install Gina Häußge’s phenomenal OctoPrint on it. Despite what Creality might want you to believe, their product is little more than a poor imitation of this incredible open source project.
Even if you manage to get it working with your printer, which judging by early indications is a pretty big if, it won’t give you anywhere near the same experience. At best it’ll save you a few dollars compared to going the DIY route, but at the cost of missing out on the vibrant community of plugin developers that have helped establish OctoPrint as the defacto remote 3D printing solution.
That being said, the hardware itself seems pretty interesting. For just $20 USD you get a palm-sized Linux computer with WiFi, Ethernet, a micro SD slot, and a pair of USB ports; all wrapped up in a fairly rugged enclosure. There’s no video output, but that will hardly scare off the veteran penguin wrangler. Tucked in a corner and sipping down only a few watts, one can imagine plenty of tasks this little gadget would be well suited to. Perhaps it could act as a small MQTT broker for all your smart home devices, or a low-power remote weather station. The possibilities are nearly limitless, assuming we can get into the thing anyway.
So what’s inside the Creality Wi-Fi Box, and how hard will it be to bend it to our will? Let’s take one apart and find out.
