This year we challenged the Hackaday community to develop Shitty Simple Supercon Add-Ons (SAO) that did more than just blink a few LEDs. The SAO standard includes I2C data and a pair of GPIO pins, but historically, they’ve very rarely been used. We knew the talented folks in this community would be able to raise the bar, but as they have a tendency to do, they’ve exceeded all of our expectations.

As we announced live during the closing ceremony at the 2024 Hackaday Supercon, the following four SAOs will be put into production and distributed to all the attendees at Hackaday Europe in Spring of 2025.

Best Overall: SAO Multimeter

For the “Best Overall” category, we only intended to compare it with the other entries in the contest. But in the end, we think there’s a strong case to be made that [Thomas Flummer] has created the greatest SAO of all time. So far, anyway.

This add-on is a fully functional digital multimeter, with functions for measuring voltage, resistance, and continuity. The design is a pure work of art, with its structure combining stacked PCBs and 3D printed parts. There’s even tiny banana plugs to connect up properly scaled probes. Incredible.

In the documentation [Thomas] mentions there are additional functions he didn’t have time to include in the firmware, such as modes to analyze the I2C and GPIO signals being received. Now that it’s been selected for production, we’re hoping he’ll have the time to get the code finished up before its European debut.

Fun: Etch sAo Sketch

This SAO recreates the iconic art toy in a (hopefully) non-trademarked way, with a 1.5″ inch 128 x 128 grayscale OLED display and a pair of trimpots capped with 3D printed knobs. Drawing is fun enough, but the nostalgia really kicks in when you give it a good shake — the onboard LIS3DH 3-axis accelerometer picks up the motion and wipes the display just like the real thing.

Created by [Andy Geppert], this SAO isn’t just a pretty face. Flipping it over shows an exceptionally clever technique for connecting the display board to the main PCB. Tiny metal balls (or “alignment spheres” if you want to get fancy) mate up with the mounting holes on the OLED board and center it, and a touch of solder locks it all in place.

Fine Art: Bendy SAO

While this wacky, waving, inflatable, arm-flailing SAO might look like the sort of thing that would be outside of a used car dealership, but creator [debraansell] managed to shrink it down so the point that it’s reasonable to plug into your badge. More or less.

There are several fascinating tricks at work here, from lighting the PCB from the back using side-firing LEDs to the integrated slip rings. If this one didn’t look so good, it would have been a strong contender for the “Least Manufacturable” Honorable Mention.

Functional: Vectrex SAO

Creating a replica of the Vectrex at SAO scale would have been an impressive enough accomplishment, but [Brett Walach] took this one all the way and made it playable.

The display is a 7 x 10 Charlieplexed LED matrix, while the “joystick” is implemented with a 1-button capacitive touch sensor. A PIC16F886 microcontroller runs the simplified version of Scramble, and there’s even a speaker for era-appropriate audio.

But that’s not all! This SAO was also designed to be hacked — so not only is all the hardware and software open source, but there’re various jumpers to fiddle with various settings and an I2C control protocol that lets you command the action from the badge.

Honorable Mentions

As usual, this contest had several Honorable Mentions categories — while we would have loved to put all of these SAOs into production, there’s only so much we can do before now and Spring.

[Jeremy Geppert]’s SAO LoRa Walkie Talkie was a judge favorite, for its simple good looks and the extra functionality that it brings to the table. [Scorch Works]’s SAO Infinity Mirror was absolutely beautiful to see in person, and makes a fantastic display when many of them get together. And [MakeItHackin]’s Skull of Fate SAO not only looked super when its eyes scan the room, but it could read your future as well!

Best Communication:

Using I2C to get SAOs to talk to the badge (or each other) was a big part of this contest, but we were also on the lookout for entries which helped facilitate badge-to-badge communications.

The Badge Tag NFC SAO from [Thomas Flummer] is a perfect example of both — it uses the NXP NTAG I2C Plus to provide 2K of read-write storage that can be accessed either internally through the I2C bus by the badge, or externally by an NFC device such as a smartphone. Modeled after a traditional conference name tag, this SAO was designed to make it easier for sharing your contact info with others during a busy con.

Infrared Communication SAO by [Alec Probst] brings infrared communications to the party, while looking like a classic TV remote. Though the original idea was to get this working in conjunction with the badge to act as a sort of TV-B-Gone, it ended up being used as part of a laser tag game during Supercon.

The GAT Nametag SC8 from [true] tackles communication on a more human level by providing a digital name tag for your badge. This compact board’s secret trick is the ability to make sure your name is legible no matter what its orientation thanks to a LIS2DW12 accelerometer that can detect the SAO’s orientation relative to the ground. RGB LEDs catch the viewer’s eye, but it’s the incredible firmware with seemingly endless options for text styling and tweaks that really set this build apart.

Light Show:

There’s little question that Featuring You! from [Nanik Adnani] is a perfect entry for this category. Nominally, it’s a little arrow you can write your name on and use a name tag. But power it up and you can dazzle anyone standing too close with its array of marching white LEDs. In a particularly nice touch, the circuit is implemented with only discreet components — no microcontroller.

The reDOT_RGB from [Alex] is a tiny 5×7 RGB LED matrix with a minuscule ATtiny816 MCU around the back to control the show. At just 8 x 11 mm, it’s hard to overstate just how tiny this SAO is.

While on the subject of tiny boards, the
Persistence of Vision POV Display is another entry not much larger than the SAO connector itself. Using a row of five tiny white LEDs and a ADXL345 accelerometer, [Michael Yim] is able to write text in mid-air thanks to the gullibility of the human eye.

Least Manufacturable:

Simple Add-Ons are essentially an art form, so it’s not surprising to find that they don’t often lend themselves to mass production. Several of the entries this yeah would be a real challenge to make in large numbers, but the one that really keeps us up at night is the ultra tiny smart SAO from [Alex].

This board is designed to fit inside the space between four header pins. Thanks, but no thanks.

Raising the Bar

Our hope this year was to elevate the Simple Add-On from a decorative piece of flair to something functional, and potentially, even useful. The results were incredible, and while we can only pick four winners this time around, every entry helped push the state-of-the-art forward in its own way. It’s hard to imagine how the SAO envelope can be pushed any further, but we can’t wait to find out.

A popular expression in the Linux forums nowadays is noting that someone “uses Arch btw”, signifying that they have the technical chops to install and use Arch Linux, a distribution designed to be cutting edge but that also has a reputation of being for advanced users only. Whether this meme was originally posted seriously or was started as a joke at the expense of some of the more socially unaware Linux users is up for debate. Either way, while it is true that Arch can be harder to install and configure than something like Debian or Fedora, thanks to excellent documentation and modern (but optional) install tools it’s no longer that much harder to run than either of these popular distributions.

For my money, the true mark of a Linux power user is the ability to install and configure Gentoo Linux and use it as a daily driver or as a way to breathe life into aging hardware. Gentoo requires much more configuration than any mainline distribution outside of things like Linux From Scratch, and has been my own technical white whale for nearly two decades now. I was finally able to harpoon this beast recently and hope that my story inspires some to try Gentoo while, at the same time, saving others the hassle.

A Long Process, in More Ways Than One

My first experience with Gentoo was in college at Clemson University in the late ’00s. The computing department there offered an official dual-boot image for any university-supported laptop at the time thanks to major effort from the Clemson Linux User Group, although the image contained the much-more-user-friendly Ubuntu alongside Windows. CLUG was largely responsible for helping me realize that I had options outside of Windows, and eventually I moved completely away from it and began using my own Linux-only installation. Being involved in a Linux community for the first time had me excited to learn about Linux beyond the confines of Ubuntu, though, and I quickly became the type of person featured in this relevant XKCD. So I fired up an old Pentium 4 Dell desktop that I had and attempted my first Gentoo installation.

For the uninitiated, the main thing that separates Gentoo from most other distributions is that it is source-based, meaning that users generally must compile the source code for all the software they want to use on their own machines rather than installing pre-compiled binaries from a repository. So, for a Gentoo installation, everything from the bootloader to the kernel to the desktop to the browser needs to be compiled when it is installed. This can take an extraordinary amount of time especially for underpowered machines, although its ability to customize compile options means that the ability to optimize software for specific computers will allow users to claim that time back when the software is actually used. At least, that’s the theory.

It didn’t work out too well for me and my Dell, though, largely because Dell of the era would put bottom-basement, obscure hardware in their budget computers which can make for a frustrating Linux experience even among the more user-friendly distributions due to a general lack of open-source drivers. I still hold a grudge against Dell for this practice in much the same way that I still refuse to use Nvidia graphics cards, but before I learned this lesson I spent weeks one summer in college with this Frankensteined computer, waiting for kernels and desktop environments to compile for days only to find out that there was something critical missing that broke my installations. I did get to a working desktop environment at one point, but made a mistake with it along the way and decided, based on my Debian experiences, that re-installing the operating system was the way to go rather than actually fixing the mistake I had made. I never got back to a working desktop after that and eventually gave up.

This experience didn’t drive me away from Gentoo completely, though. It was always at the back of my mind during any new Linux install I performed, especially if I was doing so on underpowered hardware that could have benefited from Gentoo’s customization. I would try it occasionally again and again only to give up for similar reasons, but finally decided I had gained enough knowledge from my decades as a Debian user to give it a proper go. A lot has changed in the intervening years; in the days of yore an aspiring Gentoo user had to truly start at the ground up, even going as far as needing to compile a compiler. These days only Gentoo developers take these fundamental steps, providing end users with a “Stage 3” tarball which contains the core needed to install the rest of Gentoo.

Bringing Out The Best of Old Hardware

And I do have a piece of aging hardware that could potentially benefit from a Gentoo installation. My mid-2012 Macbook Pro (actually featured in this article) is still a fairly capable machine, especially since I only really need a computer these days for light Internet browsing and writing riveting Hackaday articles. Apple long ago dropped support for this machine in macOS meaning that it’s no longer a good idea to run its native operating system. In my opinion, though, these older, pre-butterfly Macs are still excellent Linux machines aside from minor issues like finding the correct WiFi drivers. (It also can’t run libreboot, but it’s worth noting that some Macs even older than mine can.) With all of that in mind I got to work compiling my first Linux kernel in years, hoping to save my old Macbook from an e-waste pile.

There’s a lot expected of a new Gentoo user even with modern amenities like the stage 3 tarball (and even then, you have to pick a stage file from a list of around 50 options), and although the handbooks provided are fairly comprehensive they can be confusing or misleading in places. (It’s certainly recommended to read the whole installation guide first and even perform a trial installation in a virtual machine before trying it on real hardware.) In addition to compiling most software from source (although some popular packages like Firefox, LibreOffice, and even the kernel itself are available as precompiled binaries now), Gentoo requires the user to configure what are called USE flags for each package which specify that package’s compile options. A global USE flag file is also maintained to do things like build GNOME, Bluetooth, even 32-bit support into every package, while specific package USE flags are maintained in other separate files. For example, when compiling GIMP, users can choose which image formats they want their installation of GIMP to support. There’s a second layer of complexity here too as certain dependencies for packages can be “masked” or forbidden from being installed by default, so the user will also need to understand why certain things are masked and manually unmask them if the risk is deemed acceptable.

One thing that Gentoo has pioneered in recent years is the use of what it calls distribution kernels. These are kernel configurations with sane defaults, meaning that that they’ll probably work for most users on most systems on the first try. From there, users can begin tweaking the kernel for their use case once they have a working installation, but they don’t have to do that leg work during the installation process anymore. Of course, in true Gentoo fashion, you can still go through the process of configuring the kernel manually during the install if you choose to.

Aside from compiling a kernel, Gentoo also requires the user to make other fundamental choices about their installation during the install process that most other major distributions don’t. Perhaps the biggest one is that the user has to choose an init system, the backbone of the operating system’s startup and service management systems. Generally most distributions decide for you, with most larger distributions like Debian, Fedora, and Arch going with systemd by default. Like anything in the Linux world, systemd is controversial for some, so there are alternatives with OpenRC being the one with the most acceptance in the Gentoo world. I started out with OpenRC in my installations but found a few pieces of software that I use regularly don’t play well with it, so I started my build over and now use systemd. The user also can select between a number of different bootloaders, and I chose the tried-and-true Grub seeing no compelling reason to change at the moment.

In addition, there’s no default desktop environment, so you’ll also need to choose between GNOME, KDE, XFCE, any other desktop environment, or among countless window managers. The choice to use X or Wayland is up to you as well. For what it’s worth, I can at least report that GNOME takes about three times as long to compile as the kernel itself does, so keep that in mind if you’re traveling this path after me.

It’s also possible you’ll need to install a number of drivers for hardware, some of which might be non-free and difficult to install in Gentoo while they might be included by default in distributions like Ubuntu. And, like everything else, they’ll need to be compiled and configured on your machine as well. For me specifically, Gentoo was missing the software to control the fans on my MacBook Pro, but this was pretty easy to install once I found it. There’s an additional headache here as well with the Broadcom Wi-Fi cards found in older Macs, which are notoriously difficult pieces of hardware to work with in the Linux world. I was eventually able to get Wi-Fi working on my MacBook Pro, but I also have an 11″ MacBook Air from the same era that has a marginally different wireless chipset that I still haven’t been able to get to work in Gentoo, giving me flashbacks to my experience with my old Dell circa 2007.

This level of granularity when building software and an overall installation is what gives Gentoo the possibility for highly optimized installations, as every package can be configured for the user’s exact use case for every package down to the kernel itself. It’s also a rolling release model similar to Arch, so in general the newest versions of software will be available for it as soon as possible while a Debian user might have to wait a year or two for the next stable release.

A Few Drawbacks

It’s not all upside, though. For those without a lot of Gentoo experience (including myself) it’s possible to do something like spend a day and a half compiling a kernel or desktop environment only to find out a critical feature wasn’t built, and then have to spend another day and a half compiling it again with the correct USE flags. Or to use the wrong stage file on the first try, or realize OpenRC won’t work as an init system for a specific use case, or having Grub inscrutably be unable to find the installation. Also, don’t expect Gentoo to be faster out-of-the-box than Debian or Fedora without a customization effort, either; for me Gentoo was actually slower than Debian in my benchmarks without a few kernel and package re-compiles. With enough persistence and research, though, it’s possible to squeeze every bit of processing power out of a computer this way.

Personally, I’m not sure I’m willing to go through the amount of effort to migrate my workstations (and especially my servers) to Gentoo because of how much extra configuration is required for often marginal performance gains thanks to the power and performance capabilities of modern hardware. Debian Stable will likely remain my workhorse for the time being for those machines, and I wouldn’t recommend anyone install Gentoo who doesn’t want to get into the weeds with their OS. But as a Linux hobbyist there’s a lot to be said for using other distributions that are a little more difficult to use than Debian or even Arch, although I’d certainly recommend using a tool like Clonezilla to make backups of your installation from time to time so if you do make the same mistakes I made in college you can more easily restore your system. For me, though, I still plan to keep Gentoo on my MacBook Pro since it’s the machine that I tinker with the most in the same way that a classic car enthusiast wants to keep their vehicle on the road and running as well as it did when it was new. It also lets me end forum posts with a sardonic “I use Gentoo, btw” to flex on the Arch users, which might be the most important thing of all.

“It was the best of times, it was the blurst of times?” Perhaps not anymore, if this Ig Nobel-worthy analysis of the infinite monkey theorem is to be believed. For the uninitiated, the idea is that if you had an infinite number of monkeys randomly typing on an infinite number of keyboards, eventually the complete works of Shakespeare or some other famous writer would appear. It’s always been meant to be taken figuratively as a demonstration of the power of time and randomness, but some people just can’t leave well enough alone. The research, which we hope was undertaken with tongue firmly planted in cheek, reveals that it would take longer than the amount of time left before the heat death of the universe for either a single monkey or even all 200,000 chimpanzees in the world today to type the 884,647 words of Shakespeare’s complete works in the proper order.

We feel like they missed the point completely, since this is supposed to be about an infinite number of monkeys. But if they insist on sticking with real-world force monkey labor, what would really be interesting is an economic analysis of project. How much space would 200,000 chimps need? What would the energy requirements be in terms of food in and waste out? What about electricity so the monkeys can see what they’re doing? If we’re using typewriters, how much paper do we need, and how much land will be deforested for it? Seems like you’ll need replacement chimps as they age out, so how do you make sure the chimps “mix and mingle,” so to speak? And how do you account for maternity and presumably paternity leave? Also, who’s checking the output? Seems like we’d have to employ humans to do this, so what are the economic factors associated with that? Inquiring minds want to know.

Speaking of ridiculous calculations, when your company racks up a fine that only makes sense in exponential notation, you know we’ve reached new levels of stupidity. But here we are, as a Russian court has imposed a two-undecillion rouble fine on Google for blocking access to Russian state media channels. That’s 2×10³⁶ roubles, or about 2×10³³ US dollars at current exchange rates. If you’re British and think a billion is a million million, then undecillion means something different entirely, but we don’t have the energy to work that out right now. Regardless, it’s a lot, and given that the total GPD of the entire planet was estimated to be about 100×10¹² dollars in 2022, Google better get busy raising the money. We’d prefer they don’t do it the totally-not-evil way they usually do, so it might be best to seek alternate methods. Maybe a bake sale?

A couple of weeks back we sang the praises of SpaceX after they managed to absolutely nail the landing of the Starship Heavy booster after its fifth test flight by managing to pluck it from the air while it floated back to the launch pad. But the amazing engineering success was very close to disaster according to Elon Musk himself, who discussed the details online. Apparently SpaceX engineers shared with him that they were scared about the “spin gas abort” configuration on Heavy prior to launch, and that they were one second away from aborting the “chopsticks” landing in favor of crashing the booster into the ground in front of the launch pad. They also expressed fears about spot welds on a chine on the booster, which actually did rip off during descent and could have fouled on the tower during the catch. But success is a hell of a deodorant, as they say, and it’s hard to argue with how good the landing looked despite the risks.

We saw a couple of interesting stories on humanoid robots this week, including one about a robot with a “human-like gait.” The bot is from China’s EnginAI Robotics and while its gait looks pretty good, there’s still a significant uncanny valley thing going on there, at least for us. And really, what’s the point? Especially when you look at something like this new Atlas demo, which really leans into its inhuman gait to get work done efficiently. You be the judge.

And finally, we’ve always been amazed by Liberty ships, the class of rapidly produced cargo ships produced by the United States to support the British war effort during WWII. Simple in design though they were, the fact that US shipbuilders were able to ramp up production of these vessels to the point where they were building a ship every eight hours has always been fascinating to us. But it’s often true that speed kills, and this video shows the fatal flaw in Liberty ship design that led to the loss of some of the early ships in the class. The short video details the all-welded construction of the ships, a significant advancement at the time but which wasn’t the cause of the hull cracks that led to the loss of some ships. We won’t spoil the story, though. Enjoy.

Cameras are a funny rabbit hole to fall down as a hacker, because we have well over a century of items to pick and choose from, a lot of which can be had for relative pennies. In my case I have more of them than I’d care to mention, mostly film cameras and 8mm movie cameras, but there are one or two that are entirely different. My first interest in electronics came through PAL televisions, so it’s hardly surprising that along the way I’ve also acquired more than one chunky old tube-based video camera. These devices are now long ago supplanted by their solid state replacements, but they retain a fascination for me as the mirror of the CRT-based TV sets I know so well. It’s time for a fascinating descent into the world of analogue video.

Electrons chasing light, chasing electrons

The basic mode of operation behind all but some of the very earliest electronic camera tubes is that an electron gun paints its raster of electrons onto a light-sensitive target, and the current flowing through the electron beam varies in proportion to the light at each particular point on the target. This can be used to create a voltage, which when combined with the various sync pulses makes a video signal that would be understood by a monitor. The various different types of tubes have names such as Iconoscope, Emitron, or Vidicon, and while the main differences between those various types of tube lie in the combination of materials and design of their targets. Successive generations of tube made improvements to sensitivity and noise performance, first combining photoemissive layers with electron multiplying layers to amplify the video signal in much the same way as a photomultiplier tube does, and then using photoconductive targets to vary the conductivity of the target depending on the light at a particular point.

Time for some real cameras

The tube camera I’ve owned the longest is probably the best to have the lid off and see its internals, it’s an RCA security camera from the mid 1980s. Very sturdily built in the USA, mine is the 625-line version for the European market. Opening it up there’s another echo of the CRT monitor, with the same deflection and signal panels you’d find at the other end of the chain. On top is a sync generator panel, which is far more than a simple pair of oscillators. Instead it’s stuffed with circuitry to produce the full standard sync timings with odd and even fields. Lifting out the sync panel reveals the tube, in this case a vidicon with a photoconductive target, encased in its magnetic focus and deflection coils. This is a monochrome camera, so everything is pretty easy to understand.

When a colour analogue video camera is explained, it usually starts with a diagram of a light path with a couple of bean splitters and a set of filters to supply red, green, and blue images to three different tubes. This produced those high quality broadcast images, but at the expense of significant expense and complexity. As colour home video equipment appeared in the 1970s there appeared a demand for single-tube colour cameras, and to that end the manufacturers came up with a variety of similar tubes with RGB stripe filters over their targets. A couple of these cameras have come my way, both of which have Panasonic Newvicon tubes. These differentiate between red, green, and blue parts of the image by their amplitudes, and while the image is definitely colour, I’d be lying if I said it was broadcast quality.

Here in 2024 there’s very little reason to use a tube camera unless as I am you are seeking a partcular aesthetic, That said, they remain a fun and forgotten piece of consumer electronics to experiment with, so pick one up and have a play should you see one. Looking at the whole system of both camera and monitor it’s possible to see the beauty of analogue television, in the way that every part of the system exists in perfect synchronisation. Imagine the TV sets of a whole country tuned to the same channel, and all synchronised to within a fraction of a microsecond, and you’ll see what I mean even though the idea of everyone watching the same show together is now more than faintly ridiculous.

If this has tickled your fancy, here’s more from the PAL coalface.

Header: Kyle Senior, CC BY-SA 4.0.

Wired has a fascinating story this week, about the length Sophos has gone to for the last 5 years, to track down a group of malicious but clever security researchers that were continually discovering vulnerabilities and then using those findings to attack real-world targets. Sophos believes this adversary to be overlapping Chinese groups known as APT31, APT41, and Volt Typhoon.

The story is actually refreshing in its honesty, with Sophos freely admitting that their products, and security products from multiple other vendors have been caught in the crosshairs of these attacks. And indeed, we’ve covered stories about these vulnerabilities over the past weeks and months right here on this column. The sneaky truth is that many of these security products actually have pretty severe security problems.

The issues at Sophos started with an infection of an informational computer at a subsidiary office. They believe this was an information gathering exercise, that was a precursor to the widespread campaign. That campaign used multiple 0-days to crack “tens of thousands of firewalls around the world”. Sophos rolled out fixes for those 0-days, and included just a bit of extra logging as an undocumented feature. That logging paid off, as Sophos’ team of researchers soon identified an early signal among the telemetry. This wasn’t merely the first device to be attacked, but was actually a test device used to develop the attack. The game was on.

Sophos managed to deploy it’s own spyware to these test devices, to stealthily keep an eye on this clever opponent. This even thwarted a later attack before it could really start. Among the interesting observations was a bootkit infection on one of these firewalls. This wasn’t ever found in the wild, but the very nature of such an attack makes it hard to discover.

There’s one more interesting wrinkle to this story. In at least one case, Sophos received the 0-day vulnerability used in an attack through their bug bounty program, right after the wave of attacks was launched. The timing, combined with the Chinese IP Address makes it pretty clear this was more than a coincidence. This might be a Chinese hacker making a bit of extra cash on the side. It’s also reminiscent of the Chinese law requiring companies to disclose vulnerabilities to the Chinese government.

PTA 0-Day

GreyNoise runs a honeypot and an AI threat detection system, and found something interesting with that combination. The PTZOptics network security camera was the intended target, and there were a pair of vulnerabilities that this attack was intended to exploit. The first is a simple authorization bypass, where sending HTTP packets without an authorization header to the param.cgi endpoint returns data without any authorization needed. Use the get_system_conf parameter, and the system helpfully prints out valid username and password hashes. How convenient.

Gaining arbitrary command execution is trivial, as the ntp configuration isn’t properly sanitized, and the ntp binary is called insecurely. A simple $(cmd) can be injected for easy execution. Those two were being chained together for a dead simple attack chain, presumably to add the IoT devices to a botnet. The flaws have been fixed, and law enforcement have been on the case, at least seizing the IP address observed in the attacks.

Speaking of camera hacks, we do have an impressive tale from Pwn2Own 2024, where researchers at Synacktiv used a format string vulnerability to pwn the Synology TC500 camera. The firmware in question had a whole alphabet of security features, like ASLR, PIE, NX, and Full RelRO. That’s Address Space Layout Randomization, Position Independent Executables, Non-Executable memory, and Full Relocation Read-Only protections. Oh, and the payload was limited to 128 characters, with the first 32 ASCII characters unavailable for use.

How exactly does one write an exploit in this case? A bit of a lucky break with the existing memory layout gave access to what the write-up calls a “looping pointer”. That seems to be a pointer that points to itself, which is quite useful to work from offsets instead of precise memory locations. The vulnerability allowed for writing a shell command into unused memory. Then finally a bit of Return Oriented Programming, a ROP gadget, manages to launch a system call on the saved command line. Impressive.

Maybe It Wasn’t a Great Idea

…to give LLMs code execution capabilities. That’s the conclusion we came to after reading CyberArk’s post on how to achieve Remote Code Execution on a Large Language Model. The trick here is that this particular example, LoLLMs, can run python code on the backend to perform certain tasks, like do math calculations. This implementation uses Python sandboxing, and naturally there’s a known way to defeat it. The trick can be pulled off just by getting the model to evaluate the right JSON snippet, but it’s smart enough to realize that something is off and refuse to evaluate the JSON.

The interesting detail here is that it is the LLM itself that is refusing, so it’s the LLM that needs bypassed. There has been very interesting work done on LLM jailbreaks, like DAN, the Do Anything Now prompt. That would probably have worked, but this exploit can be even sneakier than that. Simply ask the LLM to help you write some JSON. Specify the payload, and ask it to add something to it. It gladly complies, and code is executed. Who knew that LLMs were so gullible?

More Quantum Erratta

This story just keeps on giving. This time it’s [Dan Goodin] at Ars Technica that has the lowdown, filling in the last few missing details about the much over-hyped quantum computing breakthrough. One of the first of those details is that the story of the compromise of AES was published in the South China Morning Post, which has over-hyped Chinese quantum progress before. What [Goodin]’s article really adds to the discussion is opinions from experts. The important takeaway is that the performance of the D-Wave quantum computer is comparable to classical approaches.

Bits and Bytes

Remember the traffic light hacking? And part two? We now have the third installment, which is really all about you, too, can purchase and hack on one of these traffic controllers. It may or may not surprise you that the answer is to buy them on Ebay and cobble together a makeshift power supply.

It’s amazing how often printers, point of sale, and other IoT gadgets are just running stripped-down, ancient versions of Android. This point of sale system is no exception, running an old, custom Android 6 system, that seems to actually be rather well locked down. Except that it has an NFC reader, and you can program NFC tags to launch Android apps. Use this creative workaround to get into Android settings, and you’re in business.

I have long maintained that printers are terrible. That sentiment apparently is extending into security research on printers, with Lexmark moving to a new encrypted filesystem for printer firmware. Thankfully, like most of these schemes, it’s not foolproof, and [Peter] has the scoop on getting in. May you never need it. Because seriously, printers are the worst.

So far in this series, we’ve talked about man-made byproducts — Fordite, which is built-up layers of cured car enamel, and Trinitite, which was created during the first nuclear bomb test.

But not all byproducts are man-made, and not all of them are basically untouchable. Some are created by Mother Nature, but are nonetheless dangerous. I’m talking about fulgurites, which can form whenever lightning discharges into the Earth.

It’s likely that even if you’ve seen a fulgurite, you likely had no idea what it was. So what are they, exactly? Basically, they are natural tubes of glass that are formed by a fusion of silica sand or rock during a lightning strike.

Much like Lichtenberg figures appear across wood, the resulting shape mimics the path of the lightning bolt as it discharged into the ground. And yes, people make jewelry out of fulgurites.

Lightning Striking Again

Lightning is among the oldest observed phenomena on Earth. You probably know that lightning is just a giant spark of electricity in the atmosphere. It can occur between clouds, the air, or the ground and often hits tall things like skyscrapers and mountaintops.

Lightning is often visible during volcanic eruptions, intense forest fires, heavy snowstorms, surface nuclear detonations, and of course, thunderstorms.

In lightning’s infancy, air acts as an insulator between charges — the positive and negative charges between the cloud and the ground. Once the charges have sufficiently built up, the air’s insulating qualities break down and the electricity is rapidly discharged in the form of lightning.

When lightning strikes, the energy in the channel briefly heats up the air to about 50,000 °F, which is several times the surface of the Sun. This makes the air explode outward. As the shock wave’s pressure decreases, we hear thunder.

Of Sand and Rock and Other Stuff

Fulgurites, also known as fossilized lightning, don’t have a fixed composition: they are composed of whatever they’re composed of at the time of the lightning strike. Four main types of fulgurites are officially recognized: sand, soil, caliche (calcium-rich), and  rock fulgurites. Sand fulgurites can usually be found on beaches or in deserts where clean sand devoid of silt and clay dominates. And like those Lichtenberg figures, sand fulgurites tend to look like branches of tubes. They have rough surfaces comprised of partially-melted grains of sand.

When sand fulgurites are formed, the sand rapidly cools and solidifies. Because of this, they tend to take on a glassy interior. As you might imagine, the size and shape of a fulgurite depends on several factors, including the strength of the strike and the depth of the sand being struck. On average, they are 2.5 to 5 cm in diameter, but have been found to exceed 20 cm.

Soil fulgurites can form in a wide variety of sediment compositions including clay-, silt-, and gravel-rich soils as well as leosses, which are wind-blown formations of accumulated dust. These also appear as tubaceous or branching formations, vesicular, irregular, or a combination thereof.

Calcium-rich sediment fulgurites have thick walls and variable shapes, although it’s common for multiple narrow channels to appear. These can run the gamut of morphological and structural variation for objects that can be classified as fulgurites.

Rock fulgurites are typically found on mountain peaks, which act as natural lightning rods. They appear as coatings or crusts of glass formed on rocks, either found as branching channels on the surface, or as lining in pre-existing fractures in the rock. They are most often found at the summit or within several feet of it.

Fact-Finding Fulgurites

Aside from jewelry and such, fulgurites’ appeal comes in wherever they’re found, as their presence can be used to estimate the number of lightning strikes in an area over time.

Then again there’s some stuff you may not necessarily want to use in jewelry making. Stuff that can be found in the dark, dank corners of the Earth. Stay tuned!

Probably not too many people around the world celebrated November 1st, 2023, but on this momentous date FreeBSD celebrated its 30th birthday. As the first original fork of the first complete and open source Unix operating system (386BSD) it continues the legacy that the Berkeley Software Distribution (BSD) began in 1978 until its final release in 1995. The related NetBSD project saw its beginnings somewhat later after this as well, also forking from 386BSD. NetBSD saw its first release a few months before FreeBSD’s initial release, but has always followed a different path towards maximum portability unlike the more generic nature of FreeBSD which – per the FAQ – seeks to specialize on a limited number of platforms, while providing the widest range of features on these platforms.

This means that FreeBSD is equally suitable for servers and workstations as for desktops and embedded applications, but each platform gets its own support tier level, with the upcoming version 15.x release only providing first tier support for x86_64 and AArch64 (ARMv8). That said, if you happen to be a billion-dollar company like Sony, you are more than welcome to provide your own FreeBSD support. Sony’s Playstation 3, Playstation 4 and Playstation 5 game consoles namely all run FreeBSD, along with a range of popular networking and NAS platforms from other big names. Clearly, it’s hard to argue with FreeBSD’s popularity.

Despite this, you rarely hear people mention that they are running FreeBSD, unlike Linux, so one might wonder whether there is anything keeping FreeBSD from stretching its digital legs on people’s daily driver desktop systems?

In The Beginning There Was UNIX

Once immortalized on the silver screen with the enthusiastically spoken words “It’s a UNIX system. I know this.”, the Unix operating system (trademarked as UNIX) originated at Bell Labs where it initially was only intended for internal use to make writing and running code for systems like the PDP-11 easier. Widespread external use started with Version 6, but even before that it was the starting point for what came to be known as the Unix-based OSes:

After FreeBSD and NetBSD forked off the 386BSD codebase, both would spawn a few more forks, most notable being OpenBSD which was forked off NetBSD by Theo de Raadt when he was (controversially) removed from the project. From FreeBSD forked the Dragonfly BSD project, while FreeBSD is mostly used directly for specific applications, such as GhostBSD providing a pleasant desktop experience with preconfigured desktop and similar amenities, and pfSense for firewall and router applications. Apple’s Darwin that underlies OS X and later contains a significant amount of FreeBSD code as well.

Overall, FreeBSD is the most commonly used of these OSS BSDs and also the one you’re most likely to think of when considering using a BSD, other than OS X/MacOS, on a desktop system.

Why FreeBSD Isn’t Linux

The Linux kernel is described as ‘Unix-like’, as much like Minix it does not directly derive from any Unix or BSD but does provide some level of compatibility. A Unix OS meanwhile is the entirety of the tools and applications (‘userland’) that accompany it, something which is provided for Linux-based distributions most commonly from the GNU (‘GNU is Not Unix’) project, ergo these Linux distributions are referred to as GNU/Linux-based to denote their use of the Linux kernel and a GNU userland. There is also a version of Debian which uses GNU userland and the FreeBSD kernel, called Debian GNU/kFreeBSD, alongside a (also Unix-like) Hurd kernel-based flavor of Debian (Debian GNU/Hurd).

In terms of overall identity it’s thus much more appropriate to refer to ‘Linux kernel’ and ‘GNU userland’ features in the context of GNU/Linux, which contrasts with the BSD userland that one finds in the BSDs, including modern-day MacOS. It is this identity of kernel- and userland that most strongly distinguishes these various operating systems and individual distributions.

These differences result in a number of distinguishing features, such as the kernel-level FreeBSD jail feature that can virtualize a single system into multiple independent ones with very little overhead. This is significantly more secure than a filesystem-level chroot jail, which was what Unix originally came with. For other types of virtualization, FreeBSD offers bhyve, which can be contrasted with the kernel-based virtualization machine (KVM) in the Linux kernel. Both of these are hypervisor/virtual machine managers that can run a variety of guest OSes. As demonstrated in a comparison by Jim Salter, between bhyve and KVM there is significant performance difference, with bhyve/NVMe on FreeBSD 13.1 outperforming KVM/VirtIO on Ubuntu 22.04 LTS by a large margin.

What this demonstrates is why FreeBSD for storage and server solutions is such a popular choice, and likely why Sony picked FreeBSD for its customized Playstation operating systems, as these gaming consoles rely heavily on virtualization, as with e.g. the PS5 hypervisor.

OpenZFS And NAS Things

A really popular application of FreeBSD is in Network-Attached Storage (NAS), with originally FreeNAS (now TrueNAS) running the roost here, with iXsystems providing both development and commercial support. Here we saw some recent backlash, as iXsystems announced that they will be adding a GNU/Linux-based solution (TrueNAS SCALE), while the FreeBSD-based version (TrueNAS CORE) will remain stuck on FreeBSD version 13. Here The Register confirmed with iXsystems that this effectively would end TrueNAS on FreeBSD. Which wouldn’t be so bad if performance on Linux wasn’t noticeably worse as covered earlier, and if OpenZFS on Linux wasn’t so problematic.

Unlike with FreeBSD where the ZFS filesystem is an integral part of the kernel, ZFS on Linux is more of an afterthought, with a range of different implementations that each have their own issues, impacting performance and stability. This means that TrueNAS on Linux will be less stable, slower and also use more RAM. Fortunately, as befits an open source ecosystem, an alternative exists in the form of XigmaNAS which was forked from FreeNAS and follows current FreeBSD fairly closely.

So what is the big deal with ZFS? Originally developed by Sun for the Solaris OS, it was released under the open source CDDL license and is the default filesystem for FreeBSD. Unlike most other filesystems, it is both the filesystem and volume manager, which is why it natively handles features such as RAID, snapshots and replication. This also provides it with the ‘self-healing’ ability where some degree of data corruption is detected and corrected, without the need for dedicated RAID controllers or ECC RAM.

For anyone who has had grief with any of the Ext*, Reiserfs or other filesystems (journaled or not) on Linux, this probably sounds pretty good, and its tight integration into FreeBSD again explains why it’s it’s such a popular choice for situations where data integrity, performance and stability are essential.

FreeBSD As A Desktop

It’s probably little surprise that FreeBSD-as-a-desktop is almost boringly similar to GNU/Linux-as-a-desktop, running the Xorg server and one’s desktop environment (DE) of choice. Which also means that it can be frustratingly broken, as I found out while trying to follow the instructions in the FreeBSD handbook for setting up Xfce. This worked about as well as my various attempts over the years to get to a working startx on Debian and Arch. Fortunately trying out another guide on the FreeBSD Foundation site quickly got me on the right path. This is where using GhostBSD (using the Mate DE by default) is a timesaver if you want to use a GUI with your FreeBSD but would like to skip the ‘deciphering startx error messages’ part.

After installation of FreeBSD (with Xfce) or GhostBSD, it’s pretty much your typical desktop experience. You got effectively the same software as on a GNU/Linux distro, with FreeBSD even providing binary (user-space) compatibility with Linux and with official GPU driver support from e.g. NVidia (for x86_64). If you intend to stick to the desktop experience, it’s probably quite unremarkable from here onwards, minus the use of the FreeBSD pkg (and source code ports) package manager instead of apt, pacman, etc.

Doing Some Software Porting

One of my standard ways to test out an operating system is to try and making some of my personal open source projects run on it, particularly NymphCast as it takes me pretty deep through the bowels of the OS and its package management system. Since NymphCast already runs on Linux, this should be a snap, one would think. As it turns out, this was mostly correct. From having had a play with this on FreeBSD a few years ago I was already aware of a few gotchas, such as the difference between GNU make and BSD make, with the former being available as the gmake package and command.

Another thing you may want to do is set up sudo (also a package) as this is not installed by default. After this it took me a few seconds to nail down the names of the dependencies to install via the FreeBSD Ports site, which I added to the NymphCast dependencies shell script. After this I was almost home-free, except for some details.

These details being that on GhostBSD you need to install the GhostBSD*-dev packages to do any development work, and after some consulting with the fine folks over at the #freebsd channel on Libera IRC I concluded that using Clang (the system default) to compile everything instead of GCC would resolve the quaint linker errors, as both apparently link against different c++ libraries (clang/libc++ vs gcc/libstdc++).

This did indeed resolve the last issues, and I had the latest nightly of NymphCast running on FreeBSD 14.1-RELEASE, playing back some videos streaming from Windows & Android systems. Not that this was shocking, as the current stable version is already up on Ports, but that package’s maintainer had make similar tweaks (gmake and use of clang++) as I did, so this should make their work easier for next time.

FreeBSD Is Here To Stay

I’ll be the first to admit that none of the BSDs really were much of a blip on my radar for much of the time that I was spending time with various OSes. Of course, I got lured into GNU/Linux with the vapid declarations of the ‘Year of the Linux Desktop’ back in the late 90s, but FreeBSD seems to always have been ‘that thing for servers’. It might have been just my fascination with porting projects like NymphCast to other platforms that got me started with FreeBSD a few years ago, but the more you look into what it can do and its differences with other OSes, the more you begin to appreciate how it’s a whole, well-rounded package.

At one point in time I made the terrible mistake of reading the ‘Linux From Scratch’ guide, which just reinforced how harrowingly pieced together Linux distributions are. Compared to the singular code bases of the BSDs, it’s almost a miracle that Linux distributions work as well as they do. Another nice thing about FreeBSD is the project structure, with no ‘Czar for life’, but rather a democratically elected core leadership. In the 30-year anniversary reflection article (PDF) in FreeBSD Journal the way this system was created is described. One could say that this creates a merit-based system that rewards even newcomers to the project. As a possible disadvantage, however, it does not create nearly the same clickbait-worthy headlines as another Linus Torvalds rant.

With widespread industry usage of FreeBSD and a strong hobbyist/enthusiast core, it seems fair to say that FreeBSD’s future looks brighter than ever. With FreeBSD available for easy installation on a range of SBCs and running well in a virtual machine, it’s definitely worth it to give it a try.