The modern home is filled with plenty of “smart” devices, but unfortunately, they don’t always speak the same language. The coffee maker and the TV might both be able to talk to your phone through their respective apps, but that doesn’t necessarily mean the two appliances can work together to better coordinate your morning routine. Which is a shame, since if more of these devices could communicate with each other, we’d be a lot closer to living that Jetsons life we were promised.
Luckily, as hardware hackers we can help get our devices better acquainted with one another. A recent post by [MyHomeThings] shows how the ESP8266 can bridge the gap between a Roomba and Amazon’s Alexa assistant. This not only allows you to cheaply and easily add voice control to the robotic vacuum, but makes it compatible with the Amazon’s popular home automation framework. This makes it possible to chain devices together into complex conditional routines, such as turning off the lights and activating the vacuum at a certain time each night.
The hack depends on the so-called Roomba Open Interface, a seven pin Mini-DIN connector that can be accessed by partially disassembling the bot. This connector provides power from the Roomba’s onboard batteries as well as a two-way serial communications bus to the controller.
By connecting a MP1584EN DC-DC converter and ESP8266 to this connector, it’s possible to send commands directly to the hardware. Add a little glue code to combine this capability with a library that emulates a Belkin Wemo device, and now Alexa is able to stop and start the robot at will.
Controlling most desktop 3D printers is as easy as sending them G-code commands over a serial connection. As you might expect, it takes a relatively quick machine to fire off the commands fast enough for a good-quality print. But what if you weren’t so picky? If speed isn’t a concern, what’s the practical limit on the type of computer you could use?
In an effort to answer that question, [Max Piantoni] set out to control his Ender 3 printer with an authentic Apple IIc. Things were made a bit easier by the fact that he really only wanted to use the printer as a 2D plotter, so he could ignore the third dimension in his code. All he needed to do was come up with a BASIC program that let him create some simple geometric artwork on the Apple and convert it into commands that could be sent out over the computer’s serial port.
Unfortunately, [Max] ran into something of a language barrier. While the Apple had no problem generating G-code the Ender’s controller would understand, both devices couldn’t agree on a data rate that worked for both of them. The 3D printer likes to zip along at 115,200 baud, while the Apple was plodding ahead at 300. Clearly, something would have to stand in as an interpreter.
The solution [Max] came up with certainly wouldn’t be our first choice, but there’s something to be said for working with what you know. He quickly whipped up a program in Unity on his Macbook that would accept incoming commands from the Apple II at 300 baud, build up a healthy buffer, and then send them off to the Ender 3. As you can see in the video after the break, this Mac-in-the-middle approach got these unlikely friends talking at last.
We’re reminded of a project from a few years back that aimed to build a fully functional 3D printer with 1980s technology. It was to be controlled by a Commodore PET from the 1980s, which also struggled to communicate quickly enough with the printer’s electronics. Bringing a modern laptop into the mix is probably cheating a bit, but at least it shows the concept is sound.
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.
Outputting data from a microcontroller over a serial port is convenient and easy, but formatting, visualizing, and analyzing the data can be tedious and frustrating. [Alex Spataru] knows this all too well, having spent too many hours building and debugging custom dashboards. To save himself and others the same frustration in the future, he created Serial Studio, a tool for quickly building dashboards for serial data.
The only input required for Serial Studio to create a dashboard is a simple JSON structure specifying the data’s format, and how it should be grouped and displayed. Originally Serial Studio required all the JSON data to be sent over serial, which is fine for simple data but quickly becomes cumbersome for more complex applications. To solve this, [Alex] added a feature allowing the JSON document with the format information loaded from the computer, while only the data is sent over serial.
Serial Studio includes several visualization options, including raw line graphs, bar/level indicator, dial indicator, the artificial horizon for IMU data, or a map widget. It can also output the formatted data to a CSV file for further analysis in other software. A console window is also included for viewing raw data or debugging purposes. See the usage demo after the break.
We like Serial Studio’s ease of use and adaptability, and we’ll likely use it for our own projects in the future. It is compatible with Linux, Windows, and Mac thanks to the Qt framework, and the code is open-source and available on GitHub.
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.
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.
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.
The TP-Link TL-WR841N isn’t a particularly impressive piece of hardware, but since it works decently well and sells for under $20 USD, it’s one of the most popular consumer routers on Amazon. Now, thanks to [TrendyTofu] of the Zero Day Initiative, we now have a concise step-by-step guide on how to hack your way into the newer versions of the hardware and take full control over this bargain WiFi device. This work was initially done to help test out reported vulnerabilities in the router’s firmware, but we’re sure the readers of Hackaday can come up with all sorts of potential uses for this information.
The story starts, as so many before it have, with a serial port. Finding the UART pads on the PCB and wiring up a level shifter was no problem, but [TrendyTofu] found it was only working one-way. Some troubleshooting and an oscilloscope later, the culprit was found to be a 1kΩ pull down resistor connected to the RX line that was keeping the voltage from peaking high enough to be recognized.
Once two-way communication was established, proper poking around inside the router’s Linux operating system could begin. It wasn’t a huge surprise to find the kernel was ancient (version 2.6.36, from 2010) and that the system utilities had been stripped to the absolute bare minimum to save space. Replacing the firmware entirely would of course be ideal, but unfortunately OpenWRT has dropped support for the newer hardware revisions of the TL-WR841N.
To teach this barebones build of Linux some new tricks, [TrendyTofu] used the mount command to find a partition on the system that actually had write-access, and used that to stash a pre-compiled build of BusyBox for MIPS. With a more complete set of tools, the real fun could begin: using GDB to debug TP-Link’s binaries and look for chinks in the armor. But feel free to insert your own brand of mayhem here.