Car enthusiasts want to know how quickly they can make a quarter mile. Weightlifters are forever trying to add one more plate to the bar. Internet denizens have their own favorite number to brag about: the result from a speed test.

The ritual is familiar. Close a few browser tabs, click the big “Go” button, and watch the needle climb. Perhaps you pay for gigabit service and see 940 megabits per second, which produces a satisfied nod. Perhaps you see 299 megabits and begin obsessing over network hardware. But before you get too excited either way, try another test. There is a fair chance it will give you a different answer.

That does not necessarily mean one test is lying. “Internet speed” is not a single physical quantity waiting to be measured. A speed test measures the performance of a particular device, over a particular local connection, through a particular ISP route, to a particular server, at a particular time using a particular test method. Change any of those things and the answer can change too.

The Usual Suspects

Speedtest by Ookla is probably the best-known test. It selects a nearby server, although you can choose another. It attempts to saturate the connection with multiple simultaneous transfers. That makes it good at answering the question most consumers are asking: approximately how much aggregate bandwidth can this Internet connection deliver?

Running several connections matters. A single TCP connection must gradually increase its sending rate while reacting to round-trip time, packet loss, receive-window limits, and congestion-control behavior. On a high-bandwidth or high-latency path, one connection may not fill the available pipe. Several parallel connections can ramp up independently and make it easier to reach the link’s aggregate capacity. That number is valid, but it represents something like a busy household, a large segmented download, or several applications operating at once. It does not necessarily predict the speed of one file transfer from one distant server.

Google’s built-in search speed test (search “speed test”) uses Measurement Lab’s Network Diagnostic Tool, or NDT. M-Lab describes NDT as a single-stream measurement of bulk-transport capacity. That makes it an interesting counterpoint to Ookla. A single flow may expose latency, loss, or TCP-window limitations that a multi-stream test can partially conceal. You can also use M-Lab’s own speed test directly.

While you may get similar numbers between the two approaches, you also may not get similar numbers, especially on high-latency connections where Ookla’s multiple streams will help hide latency.

Netflix’s Fast.com is deliberately simple. Open the page, and it immediately begins transferring data from Netflix infrastructure. By default it emphasizes download performance, since its original purpose was to answer a practical question: can this connection deliver Netflix video properly? Selecting “Show more info” adds upload speed and both unloaded and loaded latency.

The use of Netflix servers is significant. Fast.com measures the route between you and Netflix’s content-delivery network, while Ookla may test against a server operated by your ISP only a few network hops away. A superb Ookla result and a poor Fast.com result do not prove deliberate throttling, but they do tell you that the destinations — or the routes to them — are behaving differently.

Cloudflare offers two related tests. Its Radar Network Quality Test provides a quick summary, while speed.cloudflare.com  gives an extremely detailed breakdown. The latter reports download and upload throughput, idle and loaded latency, jitter, packet loss, server location, and application-oriented quality estimates.

Loaded latency is especially useful. An otherwise fast connection can become miserable when a large upload or download fills an oversized queue in the modem or router. Your idle ping might be 12 milliseconds, but under load it may jump to several hundred milliseconds. That is the classic symptom usually called bufferbloat.

If you want more options, there is testmy.net, which allows you to test upload and download speeds separately, and speedof.me, which keeps a history for you, among others. It isn’t always obvious which ones are measuring a single connection vs multiple ones, so you may have to dig through whatever documentation you can find.

Your WiFi Is Part of the Test

A browser speed test cannot automatically tell you what’s hurting your speed. A laptop connected through marginal WiFi may report 180 megabits per second even though the router has a flawless gigabit Internet connection.

In fact, once incoming Internet service reaches several hundred megabits per second, WiFi is frequently the limiting factor. The link rate displayed by the operating system is not the same thing as usable throughput. Wireless protocols have framing overhead, acknowledgments, contention, retransmissions, and half-duplex operation. The advertised 866, 1200, or 2400 megabit link rate is therefore not a promise that application data will move at that rate.

The numbers printed on WiFi boxes add another layer of optimism. A router sold as “AC1800,” for example, does not provide an 1800-megabit connection to one device. The figure is normally the sum of the maximum advertised PHY rates on separate radios — perhaps 1300 Mb/s on 5 GHz plus 450 Mb/s on 2.4 GHz — with some rounding for marketing. A conventional WiFi client connects to one band at a time, so it cannot combine those rates. The total is better understood as the router’s theoretical aggregate capacity while serving multiple devices across both bands. Even then, protocol overhead, contention, signal quality, and client limitations make actual data throughput considerably lower. Newer WiFi 7 equipment can sometimes combine links using Multi-Link Operation, but that exception does not make the old ACxxxx arithmetic any less misleading.

WiFi also uses shared airtime. Devices on the same channel — including neighboring access points that can hear one another — must contend for opportunities to transmit. A slow or distant client takes longer to send a given amount of data and can consume disproportionate airtime while doing so. Modern access points may provide airtime fairness and other mitigations. One old device does not invariably drag every client down to its rate, but it can still reduce the capacity available to the rest of the network. Interference has a similar effect. A weak signal, a crowded channel, microwave noise, or an overlapping neighboring network causes frames to be delayed or retransmitted. Those retries consume airtime without delivering additional data.

Repeaters and wireless mesh backhaul add another complication. A simple same-channel repeater must receive each packet and then transmit it again over the same shared medium. In the worst case, each repeated hop can roughly halve the available throughput. Modern tri-band mesh systems can avoid much of that penalty by using a dedicated backhaul radio, and Ethernet backhaul avoids it almost entirely.

This means it is entirely reasonable to buy gigabit Internet service and obtain only 300 or 500 megabits per second from a WiFi laptop. Whether that represents a problem depends on the client, radio band, channel width, signal level, backhaul, and local RF environment.

For a meaningful ISP test, begin with a computer connected directly to the router by Ethernet. Stop large transfers and temporarily disable any VPN. Record the chosen server, latency, upload speed, and download speed rather than preserving only the most flattering number. Then run the same tests over WiFi. The difference is an approximate measurement of what the wireless portion of the network is costing you.

Remove the Internet From the Experiment

Better still, remove the ISP from the test completely. OpenSpeedTest is a self-hostable, browser-based test. Run its server on a wired computer, NAS, or container, then visit it from laptops, phones, and tablets around the house. Because the traffic remains on your LAN, a slow result points toward WiFi, switching, cabling, or the client rather than the Internet connection.

It is possible to run this on the uhttpd server used with OpenWRT, although you’ll need to coax it to measure upload speeds since the server can’t handle the default method. The trick is to create a CGI script that accepts a large amount of data successfully and then configure uhttpd to run that.

A browser-based local test is convenient, but for serious diagnosis it is hard to beat iperf3, the client/server tool we recently used while testing mesh routers. On one machine (say, 192.168.1.100), start the server:

iperf3 -s

From another machine, run:

iperf3 -c 192.168.1.100

By default, iperf3 uses one TCP connection. Add -P 4 to try four parallel streams, or -R to reverse the direction so that the server sends and the client receives. Those variations can tell you something. If four streams are much faster than one, the network may have enough aggregate capacity but a single TCP flow is being limited by latency, loss, window growth, CPU performance, or offload behavior. If the reverse test is much faster, examine the weaker machine’s transmit path, drivers, antennas, or CPU.

iperf3 can also generate UDP traffic at a specified rate and report packet loss and jitter. That is often more informative for evaluating a wireless link than merely chasing the largest TCP number.

Can Linux Make It Faster?

Linux offers an impressive array of network tuning knobs, which naturally tempts us to turn them. But first, you need to understand what needs tweaking.

Check the negotiated Ethernet rate and interface counters:

ethtool eth0
ip -s link show eth0

A gigabit adapter that has negotiated 100 megabits per second usually has a cabling, connector, or switch-port problem. Increasing TCP buffers will not repair it. Rising interface errors and drops point toward a physical, driver, or congestion problem. TCP retransmits (view with ss -ti) may indicate loss elsewhere on the path.

You can inspect the active queue discipline with:

tc qdisc show

Linux supports queue disciplines such as fq_codel, which combines per-flow queueing with active queue management. It attempts to prevent one large transfer from building an enormous queue and delaying unrelated interactive packets. The kernel documentation specifically lists fq_codel as a sensible queue discipline that works without extensive configuration.

It can be selected as the default for newly created interfaces with:

sudo sysctl -w net.core.default_qdisc=fq_codel

That may improve queueing on traffic leaving the Linux machine. It does not, however, fix a large queue in the cable modem or Internet router. Queue management must be applied at the bottleneck. If the ISP link is limited to 20 megabits upstream, controlling a queue on a gigabit Ethernet interface after it has already handed packets to the router is too late.

For a home connection, the most effective bufferbloat treatment is usually Smart Queue Management on the router. OpenWrt’s SQM system supports both fq_codel and CAKE. CAKE generally provides better performance. However, fq_codel requires less CPU overhead.

High-latency paths introduce a different problem. TCP must keep enough data in flight to fill the bandwidth-delay product. Modern Linux generally autotunes TCP buffers, so the old advice to assign enormous fixed values to tcp_rmem and tcp_wmem is less universally useful than it once was. Before changing them, use ss -ti during a transfer and look for retransmissions, round-trip time, congestion-window size, and whether the receiver window is actually limiting the connection.

Linux also supports selectable TCP congestion-control algorithms:

sysctl net.ipv4.tcp_available_congestion_control
sysctl net.ipv4.tcp_congestion_control

Algorithms such as BBR can improve throughput and queue behavior on some long-distance or lossy paths. But changing the algorithm affects connections sent by that Linux machine; it does not control the remote speed-test server, repair poor WiFi, or eliminate a queue in the router. Congestion-control tuning is therefore a useful experiment for a server, VPN endpoint, or long-haul transfer machine — not a universal solution to slow networking.

Finally, inspect hardware offload features when a Linux system cannot keep up with a fast LAN:

ethtool -k eth0

Advanced network tuning is a bit beyond the scope of this post, but there are plenty of roadmaps down this rabbit hole.

The Lesson

The lesson here is that there is no universally correct speed-test result. Ookla tests how effectively multiple transfers can fill a route to one of its servers. M-Lab examines a single bulk flow. Fast.com tests the path to Netflix. Cloudflare pays unusual attention to latency under load and overall connection quality. OpenSpeedTest and iperf3 can determine whether the Internet connection is even the problem.

Run enough tests, and you will eventually obtain a number worth bragging about. Run the right tests, though, and you may find ways to truly increase real-world performance. If you want to chase that extra 1 kbit per second speed, be our guest — we know how it is. But the truth is that if the Internet is doing what you want it to do, then it is fast enough.

In a recent post, I mentioned that I wanted to build some tools for a stripped-down Linux running on a 3D printer with a MIPS CPU. I had two options: build a toolchain to cross-compile, or use Zig, which, in theory, has built-in toolchains for MIPS. I had to jump through hoops to get Zig to work, and I did mention Crosstool-Ng, so you might wonder why I didn’t start there. Turns out, it had its own set of hoops to work through.

What is Crosstool-Ng?

Crosstool-NG is a build system for making cross-compilation toolchains: compilers, assemblers, linkers, C libraries, kernel headers, and all the other pieces needed to build software on one machine that will run on a different kind of machine. Instead of manually matching a particular GCC version with the right binutils, glibc, or musl release, Linux headers, patches, and configuration options, you select the target architecture and let Crosstool-NG download, patch, configure, and build the stack. The result is a self-contained toolchain with commands such as mipsel-linux-musl-gcc or arm-none-eabi-gcc, ready to produce binaries for the target system.

The four-part name is in a particular format that is often used in the cross compiling world. For example, consider arm-none-eabi-gcc. The tool here is gcc and, as you might expect, there will also be arm-none-eabi-as and arm-none-eabi-ld, among other things. The first part, arm in this case, will be the target architecture.

The second part of the name can mean a few different things. In theory, it is a vendor name but it is sometimes “none” which often means “generic” or, in the case of a linux target, “linux,” which isn’t technically a vendor.

The third part is the calling convention and, often, some idea of the library. For example, arm-linux-gnueabihf-gcc would mean the GNU library using the ARM EABI and hardware floating point. These are sometimes called “target triples” because, historically, it was CPU-VENDOR-OS, but now there are usually four or even five parts if the calling convention includes the OS, like linux-musl, for example.

That sounds simple, but cross-toolchains are unusually sensitive to version combinations and ABI details. Endianness, floating-point conventions, instruction-set variants, threading support, and C library choices all have to agree. So saying “Arm” or “MIPS” doesn’t mean much. You need to account for all the possible variations in the CPU and the libraries. Crosstool-NG does not eliminate those decisions, but it turns them into a reproducible configuration rather than a long sequence of hand-built components. I had two problems that I eventually resolved.

Problem One: Versions

One nice thing about Crosstool-Ng is that it pulls the right versions of everything for you. The problem is, when you install it from your system repositories, you are probably getting a crazy old version of the tool itself. I couldn’t find the right entries in the configuration when I did that, so I eventually uninstalled and picked up the latest version right from the source.

If that was the only problem, I would have been lucky.

Problem Two: Infinite Combinations

The CPU on the printer is an odd bird. As I noted last time, the executables use the r2 instruction set but also use the nan2008 convention which is usually found in r6. While Crosstool-Ng is good at letting you specify exactly what you want, it isn’t always clear on how you specify every detail.

To be fair, just like with Zig, some of that may be on me. I don’t use Crosstool-Ng or Zig every day, so maybe I was making either or both of them too hard. The bad news: It took me three or four attempts to get the right toolchain. The good news: It was a lot easier than manually downloading a bunch of stuff, trying to fix it up, building it, and still having to do it three or four times.

Configuration

Sort of like buysbox or building a custom kernel, the configuration for Crosstool-Ng uses the command: ct-ng menuconfig. This gives you a menu where you can set options about what you want and where you want it stored.

The problem is that the nan2008 setting I needed isn’t part of a standard mips32r2 setup. I suspect that if I had needed mips32r6, everything would have just worked. But, of course, I’m not that lucky.

In the target settings, I needed to match all the specifications, of course, but I also needed to add -mnan=2008 to both the CFLAGS and LDFLAGS as you can see in the figure.

So what’s so hard about that? Just those changes won’t produce a working toolchain for my printer. The C compiler also needed --with-nan2008 (in the C Compiler options screen under extra target CFLAGS) and the same option needed to be placed in the C Library screen, too.

Of course, it is like a word search puzzle. Once you see the answers, they look obvious. But when you are searching through pages of options, it is easy to miss one. It isn’t like there is a checkbox for “Use nan2008” that does it all for you because using nan2008 with mips32r2 is “strange.”

The Proof is in the Build

Once everything was set correctly, I was able to produce a toolchain (ct-ng build) that could compile busybox and even a small text editor. Everything ran fine on the printer.

To build busybox, I used:

make V=1 CC="mipsel-unknown-linux-musl-gcc -march=mips32r2 -msoft-float -static -Os" STRIP='mipsel-unknown-linux-musl-strip' -j6

Unlike Zig, no patching needed. The Zig version was about 9 kB larger than this version, so not much different there. Both were just over a megabyte total. I could probably have used hardware floating point to get a smaller executable, but given that I don’t think any of this is using much floating point at all, it didn’t seem to matter very much.

I had also threatened to compile a text editor. Turns out most have dependencies on things like ncurses, which are a pain to bundle. So I grabbed a copy of the tutorial editor kilo and extended it to look a little like emacs. Works great. Great place to start if you need a static editor that doesn’t take much space.

Lesson Learned

If the CPU on the printer had been more conventional, I think either approach would have worked fine. I prefer the Crosstool solution in this case, because I’m not lying by patching the ELF header. In this case, I don’t think that lie hurts anything, but a program that did a lot of floating-point math might not work correctly, whereas I think the one produced by Crosstool would be fine even for a floating-point program.

On the other hand, like most Unix and Linux things, there are always more ways to solve any problem. If your problem is wedging executables on an alien Linux box, there are two perfectly fine ways to solve it.

Since the first V2 rocket sailed above the Kármán line back in 1944 and right up until the modern era, the trajectory of most space-bound rockets was more or less the same: after expending their propellants they would either crash into some desolate steppe or plunge into the ocean. In either event, the rocket was disposable. The important bit up top might go on to explore the stars or send a human crew off on their mission, but the booster rocket that lifted the spacecraft out of the atmosphere was always going to be sacrificed for the cause.

But in the 1970s NASA had a wild idea: what if we didn’t smash a brand-new rocket valued at millions of dollars into the ocean every time we wanted to put something in orbit? Instead, they would build a hybrid space vehicle that blended the vertical takeoff and raw power of a rocket with the capabilities of an airplane, allowing it and whatever it was carrying to make a gentle runway landing at the end of its mission. As such, the Space Shuttle was born.

With the benefit of hindsight, we now know the Shuttle wasn’t quite the spaceflight revolution that NASA had hoped for. The age of reusable rockets didn’t truly begin until 2015, when SpaceX landed the first stage of their Falcon 9. To date they’ve repeated the feat nearly 600 times, all the while increasing the reliability and speed of their operations. Today the Falcon 9 is the most prolific launch vehicle in history, and nearly every other rocket in active development is being designed to include some element of reusability.

Most recently, China demonstrated that they could recover their Long March 10B rocket by gently bringing it down into what amounts to a giant butterfly net. While it might seem a bit quaint compared to rockets that land on their tails like something out of a 1950s sci-fi movie, the idea offers considerable promise.

There and Back Again

But why did it take 70+ years before we were able to regularly refly orbital-class rockets? It’s not that there’s anything inherently complex about reusing a spent rocket. Sure, there’s a case to be made that material science improvements have made the engines robust enough for repeated use. But even if you had to rebuild the engines after each flight it would still be better than slamming the whole vehicle into the ocean. Similarly, there’s nothing particularly unique about the structure of the Falcon 9 that enables it to fly multiple times — it’s a big metal tube with tanks inside of it, just like essentially every rocket that has flown before it.

The revolutionary technology demonstrated by SpaceX in 2015 didn’t have anything to do with making their rocket go up, it was that they were able to safely bring it back without damaging or physically altering it. The Falcon 9 first stage that came back to Earth was in the same condition it was when it left the launch pad eight minutes or so earlier, albeit with empty propellant tanks and a layer of soot on the outside.

As such, most of the variability we see when comparing the reuse of past, present, and future rockets comes not from how the vehicle ascends, but how it ultimately comes to rest back down on Earth.

Splashdown is Easy, But Rough

Without question, the easiest way to recover a rocket intact is to simply slow it down before it hits the surface of the ocean using parachutes This is how all American crewed capsules, and more applicably the Space Shuttle’s Solid Rocket Boosters (SRBs), have been recovered after their flights.

But even when descending under multiple huge parachutes, splashdown isn’t exactly a gentle event. It could probably best be described as “survivable”, in that the vehicle and crew will come through the experience in one piece, but neither is likely to be terribly happy about it.

The situation of course ends up being even worse for the rocket, as its structure is going to be subjected to the brunt of the impact force. Additionally, a complex aerospace vehicle getting partially submerged in salt water is a recipe for corrosion and electrical issues, to say nothing of the thermal shock the hot engines will experience when getting dunked.

One could argue that the only reason this method of recovery worked for the Shuttle SRBs is because of their relative simplicity when compared to a liquid-fueled rocket capable of independent flight. At the risk of oversimplifying the structure of the SRB, at splashdown it was effectively a hollow tube with minimal avionics and thrust vector control (TVC) hardware that could simply be replaced before the next flight.

Still, the NASA document Solid Rocket Booster (SRB) Refurbishment Practices goes over the considerable work required to bring each booster back to flight status after coming down in the ocean. Given the challenges of refurbishing the boosters, it’s perhaps unsurprising that NASA elected to forgo their reuse on the Space Launch System despite its SRBs being largely identical to their Shuttle predecessors.

Teaching Rockets New Tricks

In the very early days, while they were still trying to reach orbit with the Falcon 1, SpaceX had actually considered a Shuttle SRB-style recovery procedure. But in the end they decided to outfit the Falcon 9 with deployable landing legs and the rest, as they say, is history.

Landing legs allow a rocket to come down on effectively any flat surface, be it a concrete pad next to the launch facility or a floating platform. But there are some fairly serious drawbacks to this approach. For one thing, the requirement for precise terminal guidance means parachutes are out of the question. The rocket needs fins, attitude thrusters, or other control surfaces to come down on the center of the pad.

It also means the rocket needs to perform a propulsive landing. That is, use its own primary engines to bring its velocity on touchdown to as close to zero as possible. This in turn requires engines that can not only restart in flight — a capability that has not traditionally been required by first stage boosters — but are able to throttle down low enough to control the rocket’s descent without simply pushing it back upwards. It’s difficult to overstate how unnatural a state of operation this is for a rocket. Indeed, it’s the antithesis of how nearly every rocket has operated since the Song Dynasty started experimenting with gunpowder in the 10th century.

Even if you can accomplish all that, the true cost of landing a rocket is in the extra mass. Although the legs will be stowed away and unused for 99.8% of the rocket’s flight time, it still has to lug all that weight uphill. If that wasn’t bad enough, there’s also the extra weight of whatever control mechanism is in place to guide the rocket’s descent trajectory as well as the propellant that needs to be kept in reserve for the landing burn.

All told, landing a rocket on legs comes with a massive payload penalty. In the case of the Falcon 9, the rocket’s maximum capacity to Low Earth Orbit (LEO) in its expendable configuration is approximately 22,800 kg (50,300 lb). But when outfitted with the hardware necessary to land, that number is reduced by nearly 25% to 17,500 kg (38,600 lb).

Dropping the Dead Weight

There was a time, not so very long ago, when critics doubted the financial viability of recovering and reusing rockets like the Falcon 9. But today, reuse has gone from theoretical to standard operating procedure. Outside of a few Old Space holdouts, it’s top of mind for every launch provider and critical for remaining competitive in a fast-moving commercial market. In November, Blue Origin even managed to land their New Glenn heavy-lift rocket on only its second flight.

So at this point the question isn’t whether or not future rockets will be reusable, but rather, what is the most efficient way to achieve that reusability?

With that in mind, it’s easy to see the appeal of China’s net recovery. While the rocket must still perform a propulsive descent — although in theory the necessary positional accuracy, and therefore the technical challenge, is somewhat reduced — it doesn’t need to have landing legs installed. This mass savings increases the vehicle’s useful payload capacity, which in turn makes it more profitable to operate. Achieving the same end goal while being easier and cheaper is an improvement in anyone’s book.

Admittedly, having the rocket come down in a huge net adds a certain amount of whimsy to the whole endeavor, but the overall logic is sound enough. It should also be said that SpaceX, for all the success they’ve had with landing their Falcon 9 on a set of deployable legs, are themselves planning on catching both the first and second stages of their next-generation Starship vehicle. Instead of a net, their goal is to pluck the rocket out of the air with a huge robotic pincer mechanism.

One is reminded of the old joke about how the Americans and Russians approached the problem of writing in space: NASA spent millions of dollars developing a pen that would work in microgravity, while their Russian counterparts simply used pencils. If China can demonstrate the ability to reuse a rocket they snagged in their net, the more elaborate methods of recovery employed by American rockets may one day look like a similarly overengineered solution.

We’ll start this week off by giving our congratulations to Skyroot Aerospace of India for successfully launching the country’s first privately developed orbital rocket yesterday. The company’s Vikram-1 booster stands 24 m (79 ft) tall and uses a somewhat unusual four-stage arrangement, with the first three stages using solid propellant and the final liquid-fueled stage being responsible for putting the payload into a precise orbit. With this successful launch, India becomes only the third country in the world with a private company capable of performing orbital launches.

On the other end of the spectrum, we have SpaceX’s prototype Starship, which elected not to leave Earth during a last-second (literally) launch termination on Thursday. Aborted launches are, of course, nothing new in the world of rocketry, especially when dealing with an in-development vehicle that has 33 engines that need to fire up at the same moment before it can leave the pad. But this dramatic abort was unique as it was the first time lift-off of the massive 124.4 meter (408 ft) rocket had been called off when the engines were already running.

Onboard systems took advantage of the very narrow window between the time the Raptor engines are switched on and the rocket actually leaves the launchpad to decide that it was not a good day to visit space after all. Word from SpaceX is that two of the Raptor engines on the first stage will be replaced and that they should be ready to make another launch attempt sometime this upcoming week.

While getting rockets off the ground is never easy, one thing that seems to have no trouble going up is the price of gasoline. Even still, Americans seem largely uninterested in electric vehicles, or at the very least, the slate of EVs that are currently available to them — especially now that the $7,500 federal tax credit has ended. Yesterday, TechCrunch ran an article about all the EVs that have exited the US market over the last year due to stagnant sales or import difficulties, and it’s quite a list.

Some of the vehicles, like the Sony-branded Afeela, aren’t exactly surprising. But major players like Honda, Volkswagen, Nissan, and Hyundai also decided not to bring the 2026 models of various EVs in their lineup to the US. Polestar has been forced out of the market entirely due to new import restrictions on Chinese tech. Even Tesla is paring down their offerings by discontinuing their Model X and S vehicles.

Speaking of struggling sales, earlier this week, Amateur Photographer detailed a fairly dire situation over at GoPro. The company, once the undisputed market leader in rugged action cameras, looks like it might fold before the end of the year if they can’t bolster their cash reserves. GoPro’s legendary status for reliability in the most extreme of conditions is still intact, with NASA trusting the company’s cameras to return external views of the Orion capsule during its historic trip around the Moon on Artemis II. But for more mundane pursuits, consumers are increasingly reaching for cheaper alternatives.

One more piece of bad news while we’re at it: OnePlus took to their community forums on Thursday to announce they’ll no longer be selling new phones in Europe and North America. Anyone who owns a OnePlus phone in these territories will still get software support and updates through the originally marketed end date, and the warranty on the hardware itself will still be honored. But after that, they’ll have to find a new company to do business with. While the company wasn’t exactly a household name, they did offer some compelling hardware, and it’s always a shame to see fewer options on the market.

In hopes it will lighten the mood a bit, we’ll leave you with this exhaustive look at the computers featured in 1993’s Jurassic Park, put together by Fabien Sanglard. It covers everything from laptops, which appeared in the background of shots, to the bank of glorious Thinking Machines CM-5 with their iconic arrays of twinkling red LEDs in the park’s control room. There’s even a section that dives into the software side of things, detailing the real-world applications as well as the more fanciful creations. As Fabien notes, the original Jurassic Park novel featured some surprisingly detailed descriptions of the computer tech used at the park, as author Michael Crichton was himself an accomplished programmer.

---

See something interesting that you think would be a good fit for our weekly Links column? Drop us a line; we’d love to hear about it.

Having Linux on so many devices is both a blessing and a curse. Sure, it is great that you can hack on things and modify them or even totally repurpose them. But it also means you have a fleet of Linux devices you have to manage and keep track of.

My current “main” 3D printer is a Flashforge AD5X: a nice, cheap machine that does four colors with the purge/exchange method. It sort of runs Klipper. I say sort of because Flashforge has Klipper running on a Linux host in the box, but it is massively crippled and modified. I’m sure it works for most folks. I’m also sure that if you know nothing about Linux, Klipper, or 3D printing, the experience is probably better thanks to all the cloud point-and-click interfaces. But, of course, I check none of those boxes.

I’ve had the printer for probably a year or more. Almost immediately, I put a “mod” on the printer to give it a more true Klipper interface and gave me things like shell access. There are several that I think will do this, but I used Zmod, which doesn’t totally replace the printer’s firmware; it just sort of patches it and extends it. You can easily bypass or even remove it and go back to the stock printer, although I would not want to.

In my case, the issue was a printer, but the same idea might apply to any embedded Linux system, from a router to a thermostat. Sure, it runs Linux, but is it Linux you can change?

The Problem

The Flashforge firmware and Zmod both will run on the AD5X’s little sister, the AD5M. However, the AD5M has a significantly less capable processor board than the AD5X. That means that Linux on the boxes is very stripped down. From Flashforge’s point of view, no one should be in the Linux OS anyway, and the author of Zmod probably figures every byte used is a byte taken away from the user or other advanced Zmod features.

It may seem like a first-world problem, but there were two things that irked me about the printer’s Linux. There was no less or more command for poking around files. There was also only vi as an editor. I did a few hacks to make myself happy. I wrote a pager in shell script, for example. I would try to remember to use my desktop emacs and tramp to edit files on the box. But it was a shame that there were some very basic tools lacking. Besides that, even the tools that were there like ls lacked help commands in case you want some strange option you can’t remember.

No Install

To save space, the printer doesn’t really have programs like ls, cat, and grep. Instead, it has a single busybox executable. This is common on small systems. You get one copy of the libraries and a single executable that will do all the work you need. You can invoke, for example, grep by running “busybox grep” or, if you make a symlink to busybox named grep, the user may never realize that you don’t really have grep installed.

However, busybox has to be built. You can’t easily install packages to it. So I could just run some package manager and install less or anything else. My plan was to produce a new busybox package myself to supply at least the missing commands and maybe some of the more basic ones, too. How hard could it be?

How Hard, Indeed

The first issue was figuring out exactly what the printer was running. The OS was a buildroot compile as shown by /etc/os-release:

NAME=Buildroot
VERSION=2020.02.1-g0b1f992-dirty
ID=buildroot
VERSION_ID=2020.02.1
PRETTY_NAME="Buildroot 2020.02.1"

In theory, you could probably try to rebuild everything from that information, but it seemed like a bad idea. Who knows what changes they’ve made or what strange dependencies were out there?

The next piece of the puzzle was the architecture. It turned out to be MIPS, which has many variations, a problem that would come back to haunt me later. To figure it all out, I grabbed busybox from the machine and copied it to my regular computer. This let me read the elf file:

# readelf -h busybox
ELF Header:
Magic:   7f 45 4c 46 01 01 01 00 03 00 00 00 00 00 00 00
Class:                             ELF32
Data:                              2's complement, little endian
Version:                           1 (current)
OS/ABI:                            UNIX - System V
ABI Version:                       3
Type:                              EXEC (Executable file)
Machine:                           MIPS R3000
Version:                           0x1
Entry point address:               0x403fa0
Start of program headers:          52 (bytes into file)
Start of section headers:          775880 (bytes into file)
Flags:                             0x70001405, noreorder, cpic, nan2008, o32, mips32r2
Size of this header:               52 (bytes)
Size of program headers:           32 (bytes)
Number of program headers:         10
Size of section headers:           40 (bytes)
Number of section headers:         30
Section header string table index: 29

Forensics

Just knowing that the CPU was MIPS was hardly enough. Note that the processor could have been big endian, but this one was little endian. What’s more, the flags show a few things, and the important ones would turn out to be mips32r2, which defines a particular set of instructions, and nan2008, which means everything is using a more modern floating point stack compared to some older MIPS setups.

The next step is to find a toolchain that can run on my Linux box and produce executables for such a machine. There were two main candidates that I thought about: zig and crosstool-ng.

Zig

You may remember that Zig is a completely different language from C. So it might not make sense that I want to compile busybox, a C program with Zig. However, Zig has an interesting feature. It can pretend to be gcc, and maybe compilers for some other languages too. The idea is that if you have a lot of C code, you could start changing over to Zig without having to convert everything today or even ever. Using CLang and LLVM, Zig purports to be able to just drop in a project as the system C compiler.

So why does that matter for this project? Zig also supports a lot of targets, including MIPS, and provides run time libraries for them. So if I just tell the build system to use Zig, everything will be fine, right?

Right…

Naturally, this didn’t work as well as I expected. It could be that I don’t understand Zig well enough, but passing --target mipsel-linux-musleabihf -mcpu=mips32r2 to zig cc couldn’t produce a working ‘hello world’ program. The reason? Zig appears not to supply a nan2008 library for MIPS. Or maybe I just didn’t know how to enable it. As far as I can tell, Zig might have done the right thing for mips32r6, but that, unsurprisingly, led to illegal instruction problems. Besides, I wanted to stick as close to the existing setup as possible.

I could have made Zig rebuild its libraries, but then I might as well build a full toolchain. However, I wondered if floating point would matter much for what I was doing, so I decided to cheat. I let Zig build an executable, and then I simply patched the output header to say it used nan2008. It worked for a simple program.

Busybox

Configuring busybox is a matter of using a menuconfig system similar to building a kernel. I mainly asked it to make a static copy in options and then just picked a bunch of things I wanted, especially less and more.

Many programs, including less, have options to help you minimize the size. For example, you could disable regular expressions or make it not read $LESS for options. I left nearly everything on for most of the programs.

Once it was ready to go, I needed to run make with the Zig compilers and then do the patch to fool the printer into running it.

The command line that worked the best turned out to be: make V=1 CC="zig cc -target mipsel-linux-musleabihf -mcpu=mips32r2 -static -Os" STRIP='llvm-strip' -j6

Of course, you could adjust the -j6 to suit how many CPUs you have. I like to use about 1/2 of mine when compiling. Then the patch is as simple as:

printf '\024' | dd of=busybox bs=1 seek=37 count=1 conv=notrunc

Did it Work?

Once I transferred the file, renamed to busybox-ad5x, over to the printer, I was able to successfully run things like busybox less or even busybox ls. Everything seemed to work. You can ask busybox to install a bunch of symlinks for everything it knows how to do, but I wanted to start small, so I only made symlinks for things that didn’t already exist in the native busybox.

Once I didn’t find problems, I eventually replaced even the old busybox utilities with the new ones. I even made busybox-ad5x a symlink and renamed this version as busybox-zig because I wanted to try one more experiment: using crosstool-ng to make a proper toolchain.

Next Time

But that’s a whole other topic for another day. For now, Zig — with a little patching — got the job done. There are many ways to get things done under Linux. Turns out it is very hard for a vendor to totally lock down a system, and if there is a way in, then there is almost always some way to tune things to your liking. Busybox is a great tool for stripped-down systems. Even floppy-based boots.

Ceefax was the BBC’s broadcast teletext service that ran until 2012, providing text and rudimentary graphics that were broadcast invisibly with the TV signal. In order to get this teletext data merged into the analog TV signal, special equipment was needed, of which [Nathan Dane] has a 1997-era unit on his bench to take a gander at.

Interestingly, until this time the Ceefax signal had been generated centrally in London, meaning that regional TV broadcasts might have Ceefax issues on occasion due to retransmission glitches. This makes this Ceefax Inserter  system so much more interesting, as it was one of the early examples of what these regional stations would end up installing in their racks.

At their core these units are regular PCs, running MS-DOS 6.22 on a 486-class CPU and all the typical bits and bobs that go with a PC. The speculation here is that these are essentially rebranded industrial PCs, which would make a lot of sense. As for how [Nathan] got his hands on these units, it required a deal with the company scrapping them, preventing him from showing details of the software configuration.

Following a booting demonstration, we get the teardown of a typical 1990s rackmount PC, revealing a rather interesting backplane with the mainboard being one of the cards on it. Of these, two ISA cards provide the special Ceefax sauce as well as a timing signal in the form of a PDC card featuring a Lattice CPLD or FPGA that VCRs could use to automatically start recording.

The Ceefax main event comes in the form of the inSERT Teletext Encoder card. This is pretty much its own computer system, featuring a TI TMS34010 CPU and its own RAM as well as IO. Compared to modern takes on teletext generators, this card appears to directly mix the analog signals, without any kind of conversion.

Although teletext systems have been largely shutdown now at this point due to the transition to digital TV broadcasting, there’s still a lot to be said for having such a service available for basic news and information.

After previously fixing an overly bright picture from a Voodoo graphics card with a simple resistor on one of the RAMDAC’s pins to correct its faulty internal Vref, [Bits und Bolts] got called out for not taking component drift into account. Thus in an update video he shows how instead to use an adjustable AMS1117 voltage regulator to hopefully prevent either the original issue or something new and exciting from cropping up later.

The basic idea here is to use the external voltage reference (Vref) pin for this ICS5342 RAMDAC and supply it with a constant 1.235V. If unused – as on this Orchid-branded Voodoo card – it is connected via an 0.1 microFarad capacitor to ground. This fortunately means that the pin is routed to easily accessible pads that make this modification relatively straightforward.

Basically this is where the AMS1117-ADJ chip comes into the picture, as a widely available adjustable LDO option, even if the 0.8A current rating is very much overkill for this application. With the supplied voltage the lowest voltage this LDO can output is around 1.25V, which is within the 1.10 – 1.35 V range of the datasheet.

Of course, with the PCB never having had a provision for this part, much of the rest of the video is about planning out where to place and route the components. After that tedious work and testing that nothing explodes, the new voltage is used for the RAMDAC’s Vref pin, fixing the brightness issue.

While one could argue that this RAMDAC is likely simply defective and already beginning to break down inside, this should at least give it a bit longer on what seems to be a little used card anyway.

[Simon Willison] ported the Moebuis 0.2B image inpainting model to run locally in a web browser.  The web tool simply requires a user to provide an image, mark a section of it to be removed, and the model will do it’s best to patch up the missing area. The project was handled by Claude Code as an experiment in how things in the AI coding world have evolved, but more on that in a moment.

The existence of this tool shows that it’s possible for this kind of image editing to be done on the client side, running entirely locally with no reliance on remote services or server-side GPU resources. The online demo (GitHub repository here) is available if you want to try it out, but be warned it triggers a 1.27 gigabyte download of the required model on the first run.

What’s also interesting is [Simon]’s write-up, because he used the project as an opportunity to learn what has changed in the realm of AI coding agents. [Simon] is a software developer but in this project he didn’t personally write any of the code. One may think that means he didn’t learn anything other than how to use the tools, but that’s not quite true.

He learned it’s possible to convert a PyTorch-based model to ONXX, that the converted model can run in supported browsers using local WebGPU acceleration, and that the CacheStorage API will work on large files. Last but not least, he learned Claude Opus 4.8 is capable of handling such a project pretty much autonomously, and even created an informative document explaining the underlying architecture.

One may consider AI coding agents to be disasters waiting to happen, but it’s also true that the landscape is changing quickly, and write-ups like [Simon]’s give a helpful peek at those developments.

I’ll admit it: I miss the simplicity of /etc/hosts. There was something elegant about it. You wanted laserprinter to mean 192.168.1.40, so you opened a text file and wrote:

192.168.1.40 laserprinter

Done. No cloud account, no discovery daemon, no dashboard with material-themed icons. Just a name and an address. The trouble, of course, is that /etc/hosts is only simple when you have one machine. The moment you have a desktop, a laptop, a Raspberry Pi, a NAS, a test box, and a phone or two, every little network change becomes a tiny distributed-database problem. Which copy of /etc/hosts is authoritative? Did you update the laptop? What about the machine you only boot once a month?

One Solution

Modern LANs solved this with mDNS, using Avahi on Linux. It resolves addresses that end in .local. Instead of asking a central DNS server “who is thing.local?”, a machine sends a multicast query on the local network: “who has thing.local?” The device that owns the name answers. This is why your Linux box named spock and usually be reached as spock.local on your LAN.

There are limits. mDNS is link-local; it is meant for the local LAN, not the whole Internet and shouldn’t route across subnets. Each device is supposed to publish its own name. That works fine when the device cooperates. But what about devices that do not publish mDNS? Or little embedded things that barely even have an IP address?

That is where I wanted the best of both worlds: keep a small authoritative /etc/hosts file on one Linux box, but publish selected entries onto the LAN using mDNS.

Publishing House

Avahi includes a handy tool for this:

avahi-publish-address widget.local 192.168.1.50

While that process is running, Avahi advertises widget.local as an mDNS address record. Kill the process, and the record goes away. So you could just write a script to publish all the addresses for things that won’t do it themselves and launch in in local.rc or a systemd unit. But that seems inelegant. I wanted to just pick things out of the /etc/hosts file. But not everything. Here is a simple publisher, installed as /usr/local/sbin/localip_pub:

#!/bin/sh
# Scan /etc/hosts for .local addressess and publish them using avahi

tmp="$(mktemp)"
pids=""

cleanup() {
   rm -f "$tmp"
   for p in $pids; do
      kill "$p" 2>/dev/null
   done
   wait
}


mdns_name_exists() {
   timeout 2 avahi-resolve-host-name -4 "$1" 2>/dev/null |
      awk -v h="$1" '
         BEGIN {
            sub(/\.$/, "", h)
            rc = 1
         }
      {
         n = $1
         sub(/\.$/, "", n)
      }
      n == h && $2 ~ /^([0-9]{1,3}\.){3}[0-9]{1,3}$/ {
      rc = 0
   }
   END {
      exit rc
   }'
}

trap cleanup INT TERM EXIT

awk '
   NF < 2 { next } # skip short lines
   $1 ~ /^127\./ { next } # skip local address
   # This assumes  .local
   # it will reject anything with an alias or subdomain or trailing comment
   # it also rejects any full comment lines or IPv6 addresses
   # although you could certainly patch it for IPv6 if you wanted to
   /^[[:space:]]*[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+[[:space:]]+[^.]+\.local[[:space:]]*$/ {
      ip=$1
      name=$2
      if (!seen[ip]++) print name, ip
   }
' /etc/hosts > "$tmp"


while read name ip; do
   if mdns_name_exists "$name"
   then
      echo found $name
      continue
   fi
echo avahi-publish-address "$name" "$ip"
avahi-publish-address "$name" "$ip" &
pids="$pids $!"
done < "$tmp"
wait

The script is intentionally conservative. It ignores loopback, ignores IPv6, and only publishes single names that already end in .local. So consider this hosts snippet:

192.168.1.51 oscope.local
192.168.1.52 server.example.com

The script will publish oscope.local, but leaves server.example.com alone. That avoids accidentally dumping every fully qualified name in your hosts file into mDNS.

But Wait...

The wait at the end of the script matters. Each avahi-publish-address process has to stay alive for the record to remain published. If the shell script simply started them in the background and exited, systemd would consider the service finished and might clean up the child processes. By waiting, the script remains the service’s main process.

Here is the matching systemd unit:

<h1>/etc/systemd/system/localip_pub.service</h1>

[Unit]
Description=Publish selected /etc/hosts names via Avahi/mDNS
Requires=avahi-daemon.service
After=network-online.target avahi-daemon.service
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/sbin/localip_pub
Restart=on-failure
RestartSec=5s
KillMode=control-group

[Install]
WantedBy=multi-user.target

Install and start it:

sudo chmod 755 /usr/local/sbin/localip_pub
sudo systemctl daemon-reload
sudo systemctl enable --now localip_pub.service

After editing /etc/hosts, restart the publisher:

sudo systemctl restart localip_pub.service

Of course, if you want to use this, it has to be a machine that knows to query mDNS. Ironically, your workstation probably does, but if it is configured to use /etc/hosts first, that won't matter there. But it does lead to a practical annoyance: not every application on every platform uses mDNS the same way. Android itself only relatively recently grew better support for normal application-level mDNS resolution, so behavior can vary depending on Android version, app, and resolver path. Chrome on Android seems to resolve .local names correctly in my testing.

Firefox was a little more subtle. At first it looked like Firefox on Android simply did not understand mDNS, but the real culprit was Secure DNS. If Firefox is configured to use DNS-over-HTTPS, it may bypass the local resolver path that knows how to handle .local names. Turning Secure DNS off, or adding exceptions for the local names you care about, lets those names resolve normally. That is not really an Avahi problem; it is an application side effect. To be fair, even if you stood up a LAN DNS server to solve the problem, Firefox would have probably still have skipped it in favor of its "secure" DNS.

Conflicting Data

There is another gotcha: name conflicts are not the only kind of conflict. You might expect trouble if you try to publish widget.local when some other device already owns widget.local, but address conflicts can be troublesome too. If some device is already publishing mDNS information associated with a particular IP address, trying to publish a second name for that same address may fail. In my case, avahi-publish-address did not fail gracefully; it wandered into a collision path and crashed. The safe approach is to check before publishing, avoid duplicate names and duplicate addresses, and let the device itself publish its own mDNS name when possible.

Still, for a small LAN, this is a nice compromise. /etc/hosts remains the simple text file I wanted, but Avahi turns selected entries into something other machines can discover without copying that file everywhere. It is not a replacement for real DNS, and it is not quite as seamless as the old single-machine hosts file. But for those odd devices that sit quietly on the network with an IP address and no useful name, it is a handy little bridge between the old world and the new one. Were there other ways to solve this? There always are. But this works for me.

We've looked under the covers at mDNS. The system can be a lifesaver when you have too many Raspberry Pis.

Among the many forgotten might-have-beens of the games console world, the Atari Jaguar occupies a special place. It was the final gasp of Atari Corporation, the Jack Tramiel-era incarnation of the famous pioneering game console brand that brought us the ST line of computers, and like Marlon Brando’s Terry Malloy character from On the Waterfront, it coulda been a contender. But the early ’90s games business wasn’t kind to the console from Sunnyvale, and it was squeezed from behind by the SNES and Genesis/MegaDrive, and in front from the PlayStation. Thirty years later then, can it run Linux? [Cakehonolulu] is here to show us how.

With only 2 megabytes of RAM and space for 8 megabytes of ROM, this is hardly a powerhouse. But its 16-bit 68000 processor is a supported Linux architecture, albeit with the -nommu flag on compilation. The “Jerry” DSP chip has the required serial port and timer to boot a first Linux kernel, and after a bit of hackery to make it jump to the ROM location, something boots. There’s no init process until the flat executable file for a -nommu kernel is navigated, but with that past a BusyBox userspace and a graphics driver for the “Tom” graphics chip gives it a chunky on-screen console. The code can be found in a GitHub repository, for the curious.

It seems to be the moment for 68k consoles to receive the Linux treatment, as it’s only a few weeks since we saw it on a MegaDrive. Other ’90s consoles aren’t far behind though, with the Nintendo 64 falling to the penguin a few years ago. Meanwhile, the Dreamcast had Linux running decades ago.

---

Jaguar image: Evan-Amos, Public domain.

A clock is by its very nature a device for measuring time, and thus it moves forward at a constant rate. But how about in a theatrical setting, where time runs at the whim of the director? For the stage, a clock with more flexibility is required. To this endeavor [Playful Technology] has you covered, with a larger than life stage clock whose hands are independently controllable by DMX.

Behind the clock is a very unusual part, not the modified clock mechanism one might expect, but a dual stepper motor with a concentric shaft. This is driven by an Arduino with a stepper driver shield more familiar from the world of 3D printers, and an RS485 interface for DMX interfacing. The hands are built in OpenSCAD, and 3D printed to be an interference fit on the shafts. The DMX controller software has a handy rotating knob style interface, allowing easy hand manipulation.

You can see the results in the video below, complete with an exhaustive dissection of the Arduino code. Meanwhile DMX is itself a fascinating subject, and in the past we’ve taken a deep dive into RS485.

Once upon a time, there was a bit of a fad for fingerprint authentication in laptops and desktop computers. It has long since faded, but [superdog] wanted just such a device for Linux and Mac machines. Thus, it was time to build one.

[superdog] designed the device, nicknamed immurok, as a tool for people who use external keyboards, and do lots of terminal work on Mac and Linux machines. Repeat password requests can interrupt one’s flow when hustling at the keys, so immurok was designed to ease this pain.

The device is based on a WCH CH592F microcontroller, which comes with Bluetooth connectivity out of the box. This allows immurok to connect wirelessly to the machine of your choice, advertising itself as a standard Bluetooth HID keyboard device. Fingerprint-wise, scanning is done with an R559S capacitive sensor, which verifies the match locally so there’s no transmitting biometric data anywhere. On the computer side, Linux is setup to use a CLI/TUI app plus PAM integration to handle authorization for system logins and sudo in the terminal. On the Mac platform, it’s used with a menu bar app, with PAM integration for admin prompts. There’s also a separate helper path for using it with the lock screen.

If you’re sick of entering your password all the time and wish unlocking your PC was more like unlocking your phone, this might be the project for you. We’ve seen similar projects before, too. If you’re whipping up fun gear for biometric auth, don’t hesitate to let us know on the tipsline.

Unsurprisingly to many of us, app stores for smart televisions are also trash. Perhaps even more full of trash than other app stores due to the smaller ecosystem and fewer reviewers.

Spur analyzed the LG smart TV app store, and found that almost half of the apps available contain proxy software, turning your TV into a node in their proxy network. Are these apps malware? Many of the analyzed apps provided a thin veneer of user consent: they offer you the tradeoff of seeing an ad every 15 seconds, or allowing their “occasional web indexing” to run permanently in the background. Watch the fishtank app for five minutes, join their proxy network for life.

Spur notes that the proxy SDK in use appears to block connections to private network ranges (internal IP ranges like 192.168.x.x and 10.x.x.x), but that the SDK restricting access to those ranges is the only protection against accessing whatever network the TV is connected to.

Amazon and Roku ban proxy apps on their devices. Samsung and LG do not.

Win 10 Security Updates Extended

Microsoft has added another year of security updates to Windows 10. Despite trying to kill the platform, so many users remain on Windows 10 that Microsoft likely has no choice.

The extended support program was previously due to end in October 2026 but has now been pushed to October 2027. The security updates will be available for free in the UI, but users in other regions must activate OneDrive and sync system settings, or pay 1000 Microsoft credits (about $30).

The death of Windows 10 is near, but for those unwilling or unable to let go, it shuffles along.

Signal Phishing Attempts

Bleeping Computer has an article about increased phishing attempts from hacker groups in Russia targeting Signal users.

The phishing messages target politicians, government officials, military, and other high-profile intelligence targets, and claim that Signal is introducing mandatory two-factor authentication, before prompting the target to enable remote Signal backups. A second follow-up phishing attempt then prompts the user to copy the backup authentication tokens from Signal and provide them to the attacker.

Signal remote backups are a relatively recent addition to the messenger, making a backup on the Signal servers of a users messages and images, encrypted with a key known only to the user. While convenient, and likely fundamentally secure given the track record of the Signal team, this phishing campaign highlights a major weakness: once private content is accessible somewhere else, an attacker simply needs to obtain the keys to access it, which is significantly simpler than obtaining the message content directly from the victims phone.

Payloads in WiFi and LoRa

Sasha Romijn presented an excellent talk at OrangeCon on embedding attack payloads in unusual places.

Sasha found poor input handling of content from DNS servers, TLS certificates, server headers, DHCP host names, LoRa Mesh node names, WiFi network names, and more. In many cases, it seems to be as simple as embedding JavaScript or CSS inside a string; many sites and utilities don’t sanitize against escaped HTML, and the standards allow it.

They then go on to demonstrate more serious impacts, such as compromising the management accounts of two Europe-based hosting providers by injecting content into TLS certificates, and gaining root on some OpenWRT devices via a WiFi SSID which loads a hostile JavaScript into the LUCI web management interface, which then uses the web management system to install a backdoor root shell.

Sasha continues the tour-de-exploits by demonstrating multiple cross-site scripting injections into the Ripe NCC database which then allow browser manipulation of users on the RIPE website. This has enormous implications, because Ripe NCC is the Internet allocation organization for Europe and the Middle East: the company who assigns and manages IP address blocks.

Be sure to check out the full presentation, and let this be a lesson to always treat all data as hostile, even from what would seem to be your own services!

Collecting Boot Console Info

One of the first steps in getting access to an embedded device is to look for a serial port, or serial port test points. Often this can give an idea what sort of code is running on the system, and in some cases, give direct access via the boot loader or a Linux login console.

Boot Intel is a web-based tool to automate scraping boot messages from embedded devices, looking for exposed logins and vulnerable services. Boot Intel can take pasted boot logs, or directly connect to the device via WebSerial.

While Boot Intel is a paid service, there is a free version for hackers to explore devices.

CitrixBleed, again

watchTowr Labs is back with another excellent write-up on CitrixBleed, continuing the trend of memory leaks in Citrix Netscaler devices.

This collection of vulnerabilities allow leaking internal memory from the Citrix servers, which can expose logs, customer data, encryption keys, or anything else found in server memory. Netscaler devices offer SSL offloading, application acceleration, VPN and remote access, and load balancing; all installations where leaking memory is likely very bad.

The watchTower write-up maintains their trend of providing entertaining reads about highly technical topics.  Do yourself a favor and be sure to give it a look!

Bits and Bytes

LastPass marketing partner Klue was compromised this week, impacting the customer data of multiple companies. Customer data such as email, phone numbers, addresses, and support tickets were exposed, however the LastPass vaults themselves were not impacted. While LastPass has revoked access to the impacted partner, the stolen data could assist phishing attacks against customers.

The open source self-hosted video sharing platform PeerTube has released an emergency update which addresses multiple vulnerabilities. While the release notes quote “medium to high severity” vulnerabilities, there are no specific details. If you run a PeerTube server, upgrade now!

Both Apple AirDrop and Google Quick Share have new vulnerabilities reported this week, with fixes coming soon. Both protocols are designed to allow file sharing to nearby devices, and accordingly, the issues found on them can be triggered on nearby devices. Researchers were able to find six vulnerabilities in macOS, iOS, Windows, and Android implementations of the sharing protocols. All of the discovered vulnerabilities led to crashes, but not full exploit and code execution. Sustained denial of service attacks were possible however, with nearby attackers able to keep the services unreachable and unusable for the duration.

 

This week Jonathan chats with Andy Gryc and Aaron Basset about QNX, and the interesting Open Source history and future of that embedded OS. Why does QNX Everywhere feel more open, and why do you need to register an account to download images? All that and more — Watch to find out!

• Open-source Dashboard: https://oss.qnx.com/
• GitHub Repository: https://github.com/qnx-ports
• QNX Everywhere webpage: https://qnx.software/en/developers/get-started/qnx-everywhere

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or have the guest contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

---

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License