Welcome Back, Voyager

In what is probably the longest-distance tech support operation in history, the Voyager mission team succeeded in hacking their way around some defective memory and convincing their space probe to send sensor data back to earth again. And for the record, Voyager is a 46-year old system at a distance of now 24 billion kilometers, 22.5 light-hours, from the earth.

While the time delay that distance implies must have made for quite a tense couple days of waiting between sending the patch and finding out if it worked, the age of the computers onboard probably actually helped, in a strange way. Because the code is old-school machine language, one absolutely has to know all the memory addresses where each subroutine starts and ends. You don’t call a function like do_something(); but rather by loading an address in memory and jumping to it.

This means that the ground crew, in principle, knows where every instruction lives. If they also knew where all of the busted memory cells were, it would be a “simple” programming exercise to jump around the bad bits, and re-write all of the subroutine calls accordingly if larger chunks had to be moved. By “simple”, I of course mean “incredibly high stakes, and you’d better make sure you’ve got it right the first time.”

In a way, it’s a fantastic testament to simpler systems that they were able to patch their code around the memory holes. Think about trying to do this with a modern operating system that uses address space layout randomization, for instance. Of course, the purpose there is to make hacking directly on the memory harder, and that’s the opposite of what you’d want in a space probe.

Nonetheless, it’s a testament to careful work and clever software hacking that they managed to get Voyager back online. May she send for another 46 years!

This Week In Security: Cisco, Mitel, And AI False Flags

There’s a trend recently, of big-name security appliances getting used in state-sponsored attacks. It looks like Cisco is the latest victim, based on a report by their own Talos Intelligence.

This particular attack has a couple of components, and abuses a couple of vulnerabilities, though the odd thing about this one is that the initial access is still unknown. The first part of the infection is Line Dancer, a memory-only element that disables the system log, leaks the system config, captures packets and more. A couple of the more devious steps are taken, like replacing the crash dump process with a reboot, to keep the in-memory malware secret. And finally, the resident installs a backdoor in the VPN service.

There is a second element, Line Runner, that uses a vulnerability to arbitrary code from disk on startup, and then installs itself onto the device. That one is a long term command and control element, and seems to only get installed on targeted devices. The Talos blog makes a rather vague mention of a 32-byte token that gets pattern-matched, to determine an extra infection step. It may be that Line Runner only gets permanently installed on certain units, or some other particularly fun action is taken.

Fixes for the vulnerabilities that allowed for persistence are available, but again, the initial vector is still unknown. There’s a vulnerability that just got fixed, that could have been such a vulnerability. CVE-2024-20295 allows an authenticated user with read-only privileges perform a command injection as root. Proof of Concept code is out in the wild for this one, but so far there’s no evidence it was used in any attacks, including the one above. Continue reading “This Week In Security: Cisco, Mitel, And AI False Flags”

Microsoft Updates MS-DOS GitHub Repo To 4.0

We’re not 100% sure which phase of Microsoft’s “Embrace, Extend, and Extinguish” gameplan this represents, but just yesterday the Redmond software giant decided to grace us with the source code for MS-DOS v4.0.

To be clear, the GitHub repository itself has been around for several years, and previously contained the source and binaries for MS-DOS v1.25 and v2.0 under the MIT license. This latest update adds the source code for v4.0 (no binaries this time), which originally hit the market back in 1988. We can’t help but notice that DOS v3.0 didn’t get invited to the party — perhaps it was decided that it wasn’t historically significant enough to include.

That said, readers with sufficiently gray beards may recall that DOS 4.0 wasn’t particularly well received back in the day. It was the sort of thing where you either stuck with something in the 3.x line if you had older hardware, or waited it out and jumped to the greatly improved v5 when it was released. Modern equivalents would probably be the response to Windows Vista, Windows 8, and maybe even Windows 11. Hey, at least Microsoft keeps some things consistent.

It’s interesting that they would preserve what’s arguably the least popular version of MS-DOS in this way, but then again there’s something to be said for having a historical record on what not to do for future generations. If you’re waiting to take a look at what was under the hood in the final MS-DOS 6.22 release, sit tight. At this rate we should be seeing it sometime in the 2030s.

Mining And Refining: Uranium And Plutonium

When I was a kid we used to go to a place we just called “The Book Barn.” It was pretty descriptive, as it was just a barn filled with old books. It smelled pretty much like you’d expect a barn filled with old books to smell, and it was a fantastic place to browse — all of the charm of an old library with none of the organization. On one visit I found a stack of old magazines, including a couple of Popular Mechanics from the late 1940s. The cover art always looked like pulp science fiction, with a pipe-smoking father coming home from work to his suburban home in a flying car.

But the issue that caught my eye had a cover showing a couple of rugged men in a Jeep, bouncing around the desert with a Geiger counter. “Build your own uranium detector,” the caption implored, suggesting that the next gold rush was underway and that anyone could get in on the action. The world was a much more optimistic place back then, looking forward as it was to a nuclear-powered future with electricity “too cheap to meter.” The fact that sudden death in an expanding ball of radioactive plasma was potentially the other side of that coin never seemed to matter that much; one tends to abstract away realities that are too big to comprehend.

Things are more complicated now, but uranium remains important. Not only is it needed to build new nuclear weapons and maintain the existing stockpile, it’s also an important part of the mix of non-fossil-fuel electricity options we’re going to need going forward. And getting it out of the ground and turned into useful materials, including its radioactive offspring plutonium, is anything but easy.

Continue reading “Mining And Refining: Uranium And Plutonium”

New JEDEC DDR5 Memory Specification: Up To 8800 MT/s, Anti-Rowhammer Features

Rapid row activations (yellow rows) may change the values of bits stored in victim row (purple row).
Row hammer” by DsimicOwn work. Licensed under CC BY-SA 4.0 via Wikimedia Commons.

As DDR SDRAM increases in density and speed, so too do new challenges and opportunities appear. In the recent DDR5 update by JEDEC – as reported by Anandtech – we see not only a big speed increase from the previous maximum of 6800 Mbps to 8800 Mbps, but also the deprecation of Partial Array Self Refresh (PASR) due to security concerns, and the introduction of Per-Row Activation Counting (PRAC), which should help with row hammer-related (security) implications.

Increasing transfer speeds is primarily a matter of timings within the limits set by the overall design of DDR5, while the changes to features like PASR and PRAC are more fundamental. PASR is mostly a power-saving feature, but can apparently be abused for nefarious means, which is why it’s now gone. As for PRAC, this directly addresses the issue of row hammer attacks. Back in the 2014-era of DDR3, row hammer was mostly regarded as a way to corrupt data in RAM, but later it was found to be also a way to compromise security and effect exploits like privilege escalation.

The way PRAC seeks to prevent this is by keeping track of how often a row is being accessed, with a certain limit after which neighboring memory cells get a chance to recover from the bleed-over that is at the core of row hammer attacks. All of which means that theoretically new DDR5 RAM and memory controllers should be even faster and more secure, which is good news all around.

A pair of hands holds a digital camera. "NUCA" is written in the hood above the lens and a black grip is on the right hand side of the device (left side of image). The camera body is off-white 3D printed plastic. The background is a pastel yellow.

AI Camera Only Takes Nudes

One of the cringier aspects of AI as we know it today has been the proliferation of deepfake technology to make nude photos of anyone you want. What if you took away the abstraction and put the faker and subject in the same space? That’s the question the NUCA camera was designed to explore. [via 404 Media]

[Mathias Vef] and [Benedikt Groß] designed the NUCA camera “with the intention of critiquing the current trajectory of AI image generation.” The camera itself is a fairly unassuming device, a 3D-printed digital camera (19.5 × 6 × 1.5 cm) with a 37 mm lens. When the camera shutter button is pressed, a nude image is generated of the subject.

The final image is generated using a mixture of the picture taken of the subject, pose data, and facial landmarks. The photo is run through a classifier which identifies features such as age, gender, body type, etc. and then uses those to generate a text prompt for Stable Diffusion. The original face of the subject is then stitched onto the nude image and aligned with the estimated pose. Many of the sample images on the project’s website show the bias toward certain beauty ideals from AI datasets.

Looking for more ways to use AI with cameras? How about this one that uses GPS to imagine a scene instead. Prefer to keep AI out of your endeavors to invade personal space? How about building your own TSA body scanner?

 

End-Of-Life For Z80 CPU And Peripherals Announced

In a Product Change Notification (PCN) published on April 15, Zilog (now owned by Littelfuse) announced the End of Life for a range of Z80 products, specifically virtually all of the Z84C00 range. This also includes the peripherals, such as the Z84C10 range of MPUs. These are currently already marked as EoL on stores like Mouser, with Littelfuse noting that the last orders with them can be placed until June 14th of 2024. After that you’ll have to try your luck with shady EBay sellers and a lucky box of old-new-stock found in the back of a warehouse.

What this effectively means is that after just under 48 years since its launch in 1976, the Zilog Z80 will no longer be available for sale as discrete components, which is likely to primarily impact hobbyists and people who are trying to keep retro systems going. This does not mean that it’s the end of the road for Z80, however, as the eZ80 will be produced for the foreseeable future.

These new chips will of course not come in easy to drop in DIPs, making the challenge of breadboarding your own Z80-based microcomputer that much tougher. Yet one thing that definitely won’t happen is any of us witnessing the end of the era of the Z80, 6502 and 8051 architectures.

Thanks to [Techokami] for the tip.