LightBurn Turns Back The Clock, Bails On Linux Users

Angry Birds, flash mobs, Russell Brand, fidget spinners. All of these were virtually unavoidable in the previous decade, and yet, like so many popular trends, have now largely faded into obscurity. But in a recent announcement, the developers of LightBurn have brought back a relic of the past that we thought was all but buried along with Harambe — popular software not supporting Linux.

But this isn’t a case of the developers not wanting to bring their software to Linux. LightBurn, the defacto tool for controlling hobbyist laser cutters and engravers, was already multi-platform. Looking forward, however, the developers claim that too much of their time is spent supporting and packaging the software for Linux relative to the size of the user base. In an announcement email sent out to users, they reached even deeper into the mid-2000s bag of excuses, and cited the number of Linux distributions as a further challenge:

The segmentation of Linux distributions complicates these burdens further — we’ve had to provide three separate packages for the versions of Linux we officially support, and still encounter frequent compatibility issues on those distributions (or closely related distributions), to say nothing of the many distributions we have been asked to support.

We’re not sure how much of their time could possibly be taken up by responding to requests for supporting additional distributions (especially when the answer is no), but apparently, it was enough that they finally had to put their foot down — the upcoming 1.7.00 release of LightBurn will be the last to run on Linux.

Continue reading “LightBurn Turns Back The Clock, Bails On Linux Users”

Linux Fu: Failing Pipelines

Bash is great for automating little tasks, but sometimes a little script you think will take a minute to write turns into a half hour or more. This is the story of one of those half-hour scripts.

I have too many 3D printers. In particular, I have three that are almost — but not exactly — the same, so each one has a slightly different build process when I want to update their firmware. In all fairness, one of those printers is heading out the door soon, but I’ll probably still wind up building firmware images for it.

My initial process was painful. I have a special directory with the four files needed to configure Marlin for each machine. I copy all four files and ask PlatformIO to perform the build. Usually, it succeeds and gives me a file that looks like firmware-yyyyddmmhhmm.bin or something like that.

The problem is that the build process doesn’t know which of the three machines is the target: Sulu, Checkov, or Fraiser. (Long story.) So, I manually look at the file name, copy it, and rename it. Of course, this is an error-prone process, and I’m basically lazy, so I decided to write a script to do it. I figured it would take just a minute to bundle up all the steps. I was wrong.

Continue reading “Linux Fu: Failing Pipelines”

Hacking An IoT Camera Reveals Hard-Coded Root Password

Hacking — at least the kind where you’re breaking into stuff — is very much a learn-by-doing skill. There’s simply no substitute for getting your hands dirty and just trying something. But that doesn’t mean you can’t learn something by watching, with this root password exploit on a cheap IP video camera being a good look at the basics.

By way of background on this project, [Matt Brown] had previously torn into a VStarcam CB73 security camera, a more or less generic IP camera that he picked up on the cheap, and identified a flash memory chip from which he extracted the firmware. His initial goal was to see if the camera was contacting sketchy servers, and while searching the strings for the expected unsavory items, he found hard-coded IP addresses plus confirmation that the camera was running some Linux variant.

With evidence of sloppy coding practices, [Matt] set off on a search for a hard-coded root password. The second video covers this effort, which started with finding UART pins and getting a console session. Luckily, the bootloader wasn’t locked, which allowed [Matt] to force the camera to boot into a shell session and find the root password hash. With no luck brute-forcing the hash, he turned to Ghidra to understand the structure of a suspicious program in the firmware called encoder. After a little bit of poking and some endian twiddling, he was able to identify the hard-coded root password for every camera made by this outfit, and likely others as well.

Granted, the camera manufacturer made this a lot easier than it should have been, but with a lot of IoT stuff similarly afflicted by security as an afterthought, the skills on display here are probably broadly applicable. Kudos to [Matt] for the effort and the clear, concise presentation that makes us want to dig into the junk bin and get hacking.

Continue reading “Hacking An IoT Camera Reveals Hard-Coded Root Password”

Docker-Powered Remote Gaming With Games On Whales

Cloud gaming services allow even relatively meager devices like set top boxes and cheap Chromebooks play the latest and greatest titles. It’s not perfect of course — latency is the number one issue as the player’s controller inputs need to be sent out to the server —  but if you’ve got a fast enough connection it’s better than nothing. Interested in experimenting with the tech on your own terms? The open source Games on Whales project is here to make that a reality.

As you might have guessed from the name, Games on Whales uses Linux and Docker as core components in its remote gaming system. With the software installed on a headless server, multiple users can create virtual desktop environments on the same machine, with each spawning as a separate process on the host computer. This means that all of the hardware of the host can be shared without needing to do anything complicated like setting up GPU pass-through. The main Docker container can spin up more containers as needed.

Of course there will obviously be limits to what any given hardware configuration will be able to support in terms of number of concurrent users and the demands of each stream. But for someone who wants to host a server for their friends or something even simpler like not having to put a powerful gaming PC in the living room, this is a real game-changer. For those not up to speed on Docker yet, we recently featured a guide on getting started with this powerful tool since it does take some practice to wrap one’s mind around at first.

Hacking A Brother Label Maker: Is Your CUPS Half Empty Or Half Full?

On the one hand, we were impressed that a tiny Brother label maker actually uses CUPS to support printing. Like [Sdomi], we were less than impressed at how old a copy it was using – – 1.6.1. Of course, [Sdomi] managed to gain access to the OS and set things up the right way, and we get an over-the-shoulder view.

It wasn’t just the old copy of CUPS, either. The setup page was very dated and while that’s just cosmetic, it still strikes a nerve. The Linux kernel in use was also super old. Luckily, the URLs looked like good candidates for command injection.

Continue reading “Hacking A Brother Label Maker: Is Your CUPS Half Empty Or Half Full?”

Google Drive Now Bootable

USB drives are incredibly useful, both storing files for transport between different computers and for creating bootable drives that let us use or install other operating systems on our computers. While online file storage systems like Dropbox and Google Drive have taken over a large percentage of the former task from USB drives, they have not been able to act as bootable media, ensuring that each of us have a few jump drives lying around. That might not be the case anymore, though, as this guide is the first we know of to be able to use Google Drive to boot to a Linux system.

Unlike the tried-and-true jump drive methods, however, this process is not straightforward at all. It relies on two keys, the first of which is FUSE which allows a filesystem to be created in userspace. The second is exploiting a step in boot process of Linux systems where the kernel unpacks a temporary filesystem, called initramfs, in order to load the real filesystem. Normally a user doesn’t interact much with this step, but that doesn’t mean it’s impossible. A tool called dracut allows using an existing Linux installation to build a custom initramfs and in this case, the custom initramfs is built to include the proper support for both networking and FUSE.

The proof of concept in this demonstration originally ran in a container, using an existing project called google-drive-ocamlfuse to interact with Google Drive itself. From there, after sorting out some issues with root access, networking, malfunctioning symlinks, and various timeouts on the (perhaps predictably) slow system, the whole contraption was moved over to a laptop so it could be tested on real hardware. Everything runs, and although the original creator of this behemoth admits it is a bit “silly” they note that there may be some real-world use cases for something like this. We still won’t expect everyone to throw out their jump drives anytime soon, though. If you’re not feeling like your Linux skills are up to the challenge of something like this, we’d recommend you start with our own [Al Williams]’s Linux Fu series.

Linux Fu: Kernel Modules Have Privileges

I did something recently I haven’t done in a long time: I recompiled the Linux kernel. There was a time when this was a common occurrence. You might want a feature that the default kernel didn’t support, or you might have an odd piece of hardware. But these days, in almost all the cases where you need something like this, you’ll use loadable kernel modules (LKM) instead. These are modules that the kernel can load and unload at run time, which means you can add that new device or strange file system without having to rebuild or even restart the kernel.

Normally, when you write programs for Linux, they don’t have any special permissions. You typically can’t do direct port I/O, for example, or arbitrarily access memory. The kernel, however, including modules, has no such restriction. That can make debugging modules tricky because you can easily bring the system to its knees. If possible, you might think about developing on a virtual machine until you have what you want. That way, an errant module just brings down your virtual machine. Continue reading “Linux Fu: Kernel Modules Have Privileges”