Researchers at Aikido run the Aikido Intel system, an LLM security monitor that ingests the feeds from public package repositories, and looks for anything unusual. In this case, the unusual activity was five rapid-fire releases of the xrpl package on NPM. That package is the XRP Ledger SDK from Ripple, used to manage keys and build crypto wallets. While quick point releases happen to the best of developers, these were odd, in that there were no matching releases in the source GitHub repository. What changed in the first of those fresh releases?

The most obvious change is the checkValidityOfSeed() function added to index.ts. That function takes a string, and sends a request to a rather odd URL, using the supplied string as the ad-referral header for the HTML request. The name of the function is intended to blend in, but knowing that the string parameter is sent to a remote web server is terrifying. The seed is usually the root of trust for an individual’s cryptocurrency wallet. Looking at the actual usage of the function confirms, that this code is stealing credentials and keys.

The releases were made by a Ripple developer’s account. It’s not clear exactly how the attack happened, though credential compromise of some sort is the most likely explanation. Each of those five releases added another bit of malicious code, demonstrating that there was someone with hands on keyboard, watching what data was coming in.

The good news is that the malicious releases only managed a total of 452 downloads for the few hours they were available. A legitimate update to the library, version 4.2.5, has been released. If you’re one of the unfortunate 452 downloads, it’s time to do an audit, and rotate the possibly affected keys.

Zyxel FLEX

More specifically, we’re talking about Zyxel’s USG FLEX H series of firewall/routers. This is Zyxel’s new Arm64 platform, running a Linux system they call Zyxel uOS. This series is for even higher data throughput, and given that it’s a new platform, there are some interesting security bugs to find, as discovered by [Marco Ivaldi] of hn Security and [Alessandro Sgreccia] at 0xdeadc0de. Together they discovered an exploit chain that allows an authenticated user with VPN access only to perform a complete device takeover, with root shell access.

The first bug is a wild one, and is definitely something for us Linux sysadmins to be aware of. How do you handle a user on a Linux system, that you don’t want to have SSH access to the system shell? I’ve faced this problem when a customer needed SFTP access to a web site, but definitely didn’t need to run bash commands on the server. The solution is to set the user’s shell to nologin, so when SSH connects and runs the shell, it prints a message, and ends the shell, terminating the SSH connection. Based on the code snippet, the FLEX is doing something similar, perhaps with -false set as the shell instead:

$ ssh user@192.168.169.1
(user@192.168.169.1) Password:
-false: unknown program '-false'
Try '-false --help' for more information.
Connection to 192.168.169.1 closed.

It’s slightly janky, but seems set up correctly, right? There’s one more step to do this completely: Add a Match entry to sshd_config, and disable some of the other SSH features you may not have thought about, like X11 forwarding, and TCP forwarding. This is the part that Zyxel forgot about. VPN-only users can successfully connect over SSH, and the connection terminates right away with the invalid shell, but in that brief moment, TCP traffic forwarding is enabled. This is an unintended security domain transverse, as it allows the SSH user to redirect traffic into internal-only ports.

Next question to ask, is there any service running inside the appliance that provides a pivot point? How about PostgreSQL? This service is set up to allow local connections on port 5432 — without a password. And PostgreSQL has a wonderful feature, allowing a COPY FROM command to specify a function to run using the system shell. It’s essentially arbitrary shell execution as a feature, but limited to the PostgreSQL user. It’s easy enough to launch a reverse shell to have ongoing shell access, but still limited to the PostgreSQL user account.

There are a couple directions exploitation can go from there. The /tmp/webcgi.log file is accessible, which allows for grabbing an access token from a logged-in admin. But there’s an even better approach, in that the unprivileged user can use the system’s Recovery Manager to download system settings, repack the resulting zip with a custom binary, re-upload the zip using Recovery Manager, and then interact with the uploaded files. A clever trick is to compile a custom binary that uses the setuid(0) system call, and because Recovery Manager writes it out as root, with the setuid bit set, it allows any user to execute it and jump straight to root. Impressive.

Power Glitching an STM32

Micro-controllers have a bit of a weird set of conflicting requirements. They need to be easily flashed, and easily debugged for development work. But once deployed, those same chips often need to be hardened against reading flash and memory contents. Chips like the STM32 series from ST Microelectronics have multiple settings to keep chip contents secure. And Anvil Secure has some research on how some of those protections could be defeated. Power Glitching.

The basic explanation is that these chips are only guaranteed to work when run inside their specified operating conditions. If the supply voltage is too low, be prepared for unforeseen consequences. Anvil tried this, and memory reads were indeed garbled. This is promising, as the memory protection settings are read from system memory during the boot process. In fact, one of the hardest challenges to this hack was determining the exact timing needed to glitch the right memory read. Once that was nailed down, it took about 6 hours of attempts and troubleshooting to actually put the embedded system into a state where firmware could be extracted.

MCP Line Jumping

Trail of Bits is starting a series on MCP security. This has echoes of the latest FLOSS Weekly episode, talking about agentic AI and how Model Context Protocol (MCP) is giving LLMs access to tools to interact with the outside world. The security issue covered in this first entry is Line Jumping, also known as tool poisoning.

It all boils down to the fact that MCPs advertise the tools that they make available. When an LLM client connects to that MCP, it ingests that description, to know how to use the tool. That description is an opportunity for prompt injection, one of the outstanding problems with LLMs.

Bits and Bytes

Korean SK Telecom has been hacked, though not much information is available yet. One of the notable statements is that SK Telecom is offering customers a free SIM swapping protection service, which implies that a customer database was captured, that could be used for SIM swapping attacks.

WatchTowr is back with a simple pre-auth RCE in Commvault using a malicious zip upload. It’s a familiar story, where an unauthenticated endpoint can trigger a file download from a remote server, and file traversal bugs allow unzipping it in an arbitrary location. Easy win.

SSD Disclosure has discovered a pair of Use After Free bugs in Google Chrome, and Chrome’s Miracleptr prevents them from becoming actual exploits. That technology is a object reference count, and “quarantining” deleted objects that still show active references. And for these particular bugs, it worked to prevent exploitation.

And finally, [Rohan] believes there’s an argument to be made, that the simplicity of ChaCha20 makes it a better choice as a symmetric encryption primitive than the venerable AES. Both are very well understood and vetted encryption standards, and ChaCha20 even manages to do it with better performance and efficiency. Is it time to hang up AES and embrace ChaCha20?

Alvin Lucier was an American experimental composer whose compositions were arguably as much science experiments as they were music. The piece he is best known for, I Am Sitting in a Room, explored the acoustics of a room and what happens when you amplify the characteristics that are imparted on sound in that space by repeatedly recording and playing back the sound from one tape machine to another. Other works have employed galvanic skin response sensors, electromagnetically activated piano strings and other components that are not conventionally used in music composition.

Undoubtedly the most unconventional thing he’s done (so far) is to perform in an exhibit at The Art Gallery of Western Australia in Perth which opened earlier this month. That in itself would not be so unconventional if it weren’t for the fact that he passed away in 2021. Let us explain.

While he was still alive, Lucier entered into a collaboration with a team of artists and biologists to create an exhibit that would push art, science and our notions of what it means to live beyond one’s death into new ground.

The resulting exhibit, titled Revivication, is a room filled with gong-like cymbals being played via actuators by Lucier’s brain…sort of. It is a brain organoid, a bundle of neurons derived from a sample of his blood which had been induced into pluripotent stem cells. The organoid sits on a mesh of electrodes, providing an interface for triggering the cymbals.

“But the organoid isn’t aware of what’s happening, it’s not performing” we hear you say. While it is true that the bundle of neurons isn’t likely to have intuited hundreds of years of music theory or its subversion by experimental methodology, it is part of a feedback loop that potentially allows it to “perceive” in some way the result of its “actions”.

Microphones mounted at each cymbal feed electrical stimulus back to the organoid, presumably providing it with something to respond to. Whether it does so in any meaningful way is hard to say.

The exhibit asks us to think about where creativity comes from. Is it innate? Is it “in our blood” so to speak? Do we have agency or are we being conducted? Can we live on beyond our own deaths through some creative act? What, if anything, do brain organoids experience?

This makes us think about some of the interesting mind-controlled musical interfaces we’ve seen, the promise of pluripotent stem cell research, and of course those brain computer interfaces. Oh, and there was that time the Hackaday Podcast featured Alvin Lucier’s I Am Sitting in a Room on What’s that Sound.

It’s human nature to look at the technological achievements of the ancients — you know, anything before the 1990s — and marvel at how they were able to achieve precision results in such benighted times. How could anyone create a complicated mechanism without the aid of CNC machining and computer-aided design tools? Clearly, it was aliens.

Or, as [Chris] from Click Spring demonstrates by creating precision nesting thin-wall tubing, it was human beings running the same wetware as what’s running between our ears but with a lot more patience and ingenuity. It’s part of his series of experiments into how the craftsmen of antiquity made complicated devices like the Antikythera mechanism with simple tools. He starts by cleaning up roughly wrought brass rods on his hand-powered lathe, followed by drilling and reaming to create three tubes with incremental precision bores. He then creates matching pistons for each tube, with an almost gas-tight enough fit right off the lathe.

Getting the piston fit to true gas-tight precision came next, by lapping with a jeweler’s rouge made from iron swarf recovered from the bench. Allowed to rust and ground to a paste using a mortar and pestle, the red iron oxide mixed with olive oil made a dandy fine abrasive, perfect for polishing the metal to a high gloss finish. Making the set of tubes concentric required truing up the bores on the lathe, starting with the inner-most tube and adding the next-largest tube once the outer diameter was lapped to spec.

Easy? Not by a long shot! It looks like a tedious job that we suspect was given to the apprentice while the master worked on more interesting chores. But clearly, it was possible to achieve precision challenging today’s most exacting needs with nothing but the simplest tools and plenty of skill.

“TheC64” is a popular recreation of the best selling computer of all time, the original Commodore 64. [10p6] enjoys hacking on this platform, and recently whipped up a new mod — adding a 9-pin Atari joystick connector for convenience.

When it comes to TheC64 units, they ship with joysticks that look retro, but aren’t. These joysticks actually communicate with the hardware over USB. [10p6]’s hack was to add an additional 9-pin Atari joystick connector into the joystick itself. It’s a popular mod amongst owners of TheC64 and the C64 Mini. All one needs to do is hook up a 9-pin connector to the right points on the joystick’s PCB. Then, it effectively acts as a pass-through adapter for hooking up other joysticks to the system.

While this hack could have been achieved by simply chopping away at the plastic housing of the original joystick, [10p6] went a tidier route. Instead, the joystick was granted a new 3D printed base that had a perfect mounting spot for the 9-pin connector. Clean!

We’ve seen some great hacks from [10p6] lately, like the neat reimagined “C64C” build that actually appears in this project video, too.

While tools like CRISPR have blown the field of genome hacking wide open, being able to predict what will happen when you tinker with the code underlying the living things on our planet is still tricky. Researchers at Stanford hope their new Evo 2 DNA generative AI tool can help.

Trained on a dataset of over 100,000 organisms from bacteria to humans, the system can quickly determine what mutations contribute to certain diseases and what mutations are mostly harmless. An “area we are hopeful about is using Evo 2 for designing new genetic sequences with specific functions of interest.”

To that end, the system can also generate gene sequences from a starting prompt like any other LLM as well as cross-reference the results to see if the sequence already occurs in nature to aid in predicting what the sequence might do in real life. These synthetic sequences can then be made using CRISPR or similar techniques in the lab for testing. While the prospect of building our own Moya is exciting, we do wonder what possible negative consequences could come from this technology, despite the hand-wavy mention of not training the model on viruses to “to prevent Evo 2 from being used to create new or more dangerous diseases.”

We’ve got you covered if you need to get your own biohacking space setup for DNA gels or if you want to find out more about powering living computers using electricity. If you’re more curious about other interesting uses for machine learning, how about a dolphin translator or discovering better battery materials?

When you start building lots of something, you’ll know the value of accurate fixturing. [Chris Borge] learned this the hard way on a recent mass-production project, and decided to solve the problem. How? With a custom fixturing tool! A 3D printed one, of course.

Chris’s build is simple enough. He created 3D-printed workplates covered in a grid of specially-shaped apertures, each of which can hold a single bolt. Plastic fixtures can then be slotted into the grid, and fastened in place with nuts that thread onto the bolts inserted in the base. [Chris] can 3D print all kinds of different plastic fixtures to mount on to the grid, so it’s an incredibly flexible system.

3D printing fixtures might not sound the stoutest way to go, but it’s perfectly cromulent for some tasks. Indeed, for [Chris]’s use case of laser cutting, the 3D printed fixtures are more than strong enough, since the forces involved are minimal. Furthermore, [Chris] aided the stability of the 3D-printed workplate by mounting it on a laser-cut wooden frame filled with concrete. How’s that for completeness?

We’ve seen some other great fixturing tools before, too. Video after the break.

[Bill Dudley] had a problem. He had an Onkyo AV receiver that did a great job… until it didn’t. A DSP inside failed. When that happened, the main microprocessor running the show decided it wouldn’t play ball without the DSP operational. [Bill] knew the bulk of the audio hardware was still good, it was just the brains that were faulty. Thus started a 4-month operation to resurrect the Onkyo receiver with new intelligence instead.

[Bill’s] concept was simple. Yank the dead DSP, and the useless microprocessor as well. In their place, an ESP32 would be tasked with running things. [Bill] no longer cared if the receiver had DSP abilities or even the ability to pass video—he just wanted to use it as the quality audio receiver that it was.

His project report steps through all the hard work he went through to get things operational again. He had to teach the ESP32 to talk to the front panel display, the keys, and the radio tuner. More challenging was the core audio processor—the obscure Renaisys R2A15218FP. However, by persevering, [Bill] was able to get everything up and running, and even added some new functionality—including Internet radio and Bluetooth streaming.

It’s a heck of a build, and [Bill] ended up with an even more functional audio receiver at the end of it all. Bravo, we say. We love to see older audio gear brought back to life, particularly in creative ways. Meanwhile, if you’ve found your own way to save a piece of vintage audio hardware, don’t hesitate to let us know!

There was a time when each and every printer and typesetter had its own quirky language. If you had a wordprocessor from a particular company, it worked with the printers from that company, and that was it. That was the situation in the 1970s when some engineers at Xerox Parc — a great place for innovation but a spotty track record for commercialization — realized there should be a better answer.

That answer would be Interpress, a language for controlling Xerox laser printers. Keep in mind that in 1980, a laser printer could run anywhere from $10,000 to $100,000 and was a serious investment. John Warnock and his boss, Chuck Geschke, tried for two years to commercialize Interpress. They failed.

So the two formed a company: Adobe. You’ve heard of them? They started out with the idea of making laser printers, but eventually realized it would be a better idea to sell technology into other people’s laser printers and that’s where we get PostScript.

Early PostScript and the Birth of Desktop Publishing

PostScript is very much like Forth, with words made specifically for page layout and laser printing. There were several key selling points that made the system successful.

First, you could easily obtain the specifications if you wanted to write a printer driver. Apple decided to use it on their LaserWriter. Of course, that meant the printer had a more powerful computer in it than most of the Macs it connected to, but for $7,000 maybe that’s expected.

Second, any printer maker could license PostScript for use in their device. Why spend a lot of money making your own when you could just buy PostScript off the shelf?

Finally, PostScript allowed device independence. If you took a PostScript file and sent it to a 300 DPI laser printer, you got nice output. If you sent it to a 2400 DPI typesetter, you got even nicer output. This was a big draw since a rasterized image was either going to look bad on high-resolution devices or have a huge file system in an era where huge files were painful to deal with. Even a page at 300 DPI is fairly large.

If you bought a Mac and a LaserWriter you only needed one other thing: software. But since the PostScript spec was freely available, software was possible. A company named Aldus came out with PageMaker and invented the category of desktop publishing. Adding fuel to the fire, giant Lionotype came out with a typesetting machine that accepted PostScript, so you could go from a computer screen to proofs to a finished print job with one file.

If you weren’t alive — or too young to pay attention — during this time, you may not realize what a big deal this was. Prior to the desktop publishing revolution, computer output was terrible. You might mock something up in a text file and print it on a daisy wheel printer, but eventually, someone had to make something that was “camera-ready” to make real printing plates. The kind of things you can do in a minute in any word processor today took a ton of skilled labor back in those days.

Take Two

Of course, you have to innovate. Adobe did try to prompt Display PostScript in the late 1980s as a way to drive screens. The NeXT used this system. It was smart, but a bit slow for the hardware of the day. Also, Adobe wanted licensing fees, which had worked well for printers, but there were cheaper alternatives available for displays by the time Display PostScript arrived.

In 1991, Adobe released PostScript Level 2 — making the old PostScript into “Level 1” retroactively. It had all the improvements you would expect in a second version. It was faster and crashed less. It had better support for things like color separation and handling compressed images. It also worked better with oddball and custom fonts, and the printer could cache fonts and graphics.

Remember how releasing the spec helped the original PostScript? For Level 2, releasing it early caused a problem. Competitors started releasing features for Level 2 before Adobe. Oops.

They finally released PostScript 3. (And dropped the “Level”.) This allowed for 12-bit colors instead of 8-bit. It also supported PDF files.

PDF?

While PostScript is a language for controlling a printer, PDF is set up as a page description language. It focuses on what the page looks like and not how to create the page. Of course, this is somewhat semantics. You can think of a PostScript file as a program that drives a Raster Image Processor (RIP) to draw a page. You can think of a PDF as somewhat akin to a compiled version of that program that describes what the program would do.

Up to PDF 1.4, released in 2001, everything you could do in a PDF file could be done in PostScript. But with PDF 1.4 there were some new things that PostScript didn’t have. In particular, PDFs support layers and transparency. Today, PDF rules the roost and PostScript is largely static and fading.

What’s Inside?

Like we said, a PostScript file is a lot like a Forth program. There’s a comment at the front (%!PS-Adobe-3.0) that tells you it is a PostScript file and the level. Then there’s a prolog that defines functions and fonts. The body section uses words like moveto, lineto, and so on to build up a path that can be stroked, filled, or clipped. You can also do loops and conditionals — PostScript is Turing-complete. A trailer appears at the end of each page and usually has a command to render the page (showpage), which may start a new page.

A PDF file has a similar structure with a %PDF-1.7 comment. The body contains objects that can refer to pages, dictionaries, references, and image or font streams. There is also a cross-reference table to help find the objects and a trailer that points to the root object.  That object brings in other objects to form the entire document. There’s no real code execution in a basic PDF file.

If you want to play with PostScript, there’s a good chance your printer might support it. If not, your printer drivers might. However, you can also grab a copy of GhostScript and write PostScript programs all day. Use GSView to render them on the screen or print them to any printer you can connect to. You can even create PDF files using the tools.

For example, try this:

%!PS
% Draw square
100 100 moveto
100 0 rlineto
0 100 rlineto
-100 0 rlineto
closepath
stroke

% Draw circle
150 150 50 0 360 arc
stroke

% Draw text "Hackaday" centered in the circle
/Times-Roman findfont 12 scalefont setfont % Choose font and size
(Hackaday) dup stringwidth pop 2 div % Calculate half text width
150 exch sub % X = center - half width
150 % Y = vertical center
moveto
(Hackaday) show

showpage

If you want to hack on the code or write your own, here’s the documentation. Think it isn’t really a programming language? [Nicolas] would disagree.

There’s just something about a satisfying “click” that our world of touchscreens misses out on; the only thing that might be better than a good solid “click” when you hit a button is if device could “click” back in confirmation. [Craig Shultz] and his crew of fine researchers at the Interactive Display Lab at the University of Illinois seem to agree, because they have come up with an ingenious hack to provide haptic feedback using readily-available parts.

The “hapticoil”, as they call it, has a simple microspeaker at its heart. We didn’t expect a tiny tweeter to have the oomph to produce haptic feedback, and on its own it doesn’t, as finger pressure stops the vibrations easily. The secret behind the hapticoil is to couple the speaker hydraulically to a silicone membrane. In other words, stick the thing in some water, and let that handle the pressure from a smaller soft button on the silicone membrane. That button can be virtually any shape, as seen here.

Aside from the somewhat sophisticated electronics that allow the speaker coil to be both button and actuator (by measuring inductance changes when pressure is applied, while simultaneously driven as a speaker), there’s nothing here a hacker couldn’t very easily replicate: a microspeaker, a 3D printed enclosure, and a silicone membrane that serves as the face of the haptic “soft button”. That’s not to say we aren’t given enough info replicate the electronics; the researchers are kind enough to provide a circuit diagram in figure eight of their paper.

In the video below, you can see a finger-mounted version used to let a user feel pressing a button in virtual reality, which raises some intriguing possibilities. The technology is also demonstrated on a pen stylus and a remote control.

This isn’t the first time we’ve featured hydraulic haptics — [Craig] was also involved with an electroosmotic screen we covered previously, as well as a glove that used the same trick. This new microspeaker technique does seem much more accessible to the hacker set, however.

[Agatha] sent us this stunning multimeter she built as a gift for her mom. Dubbed the Mohmmeter — a playful nod to its ohmmeter function and her mom — this project combines technical ingenuity with heartfelt craftsmanship.

At its core, a Raspberry Pi Pico microcontroller reads the selector knob, controls relays, and lights up LEDs on the front panel to show the meter’s active range. The Mohmmeter offers two main measurement modes, each with two sub-ranges for greater precision across a wide spectrum.

She also included circuitry protections against reverse polarity and over-voltage, ensuring durability. There was also a great deal of effort put into ensuring it was accurate, as the device was put though its paces using a calibrated meter as reference to ensure the final product was as useful as it was beautiful.

The enclosure is a work of art, crafted from colorful wooden panels meticulously jointed together. Stamped brass plates label the meter’s ranges and functions, adding a steampunk flair. This thoughtful design reflects her dedication to creating something truly special.

Want to build a meter for mom, but she’s more of the goth type? The blacked-out Hydameter might be more here style.

[Michal Sapka] wanted to learn a new skill, so he decided on the Commodore 64 assembly language. We didn’t say he wanted to learn a new skill that might land him a job. But we get it and even applaud it. Especially since he’s written a multi-part post about what he’s doing and how you can do it, too. So far, there are four parts, and we’d bet there are more to come.

The series starts with the obligatory “hello world,” as well as some basic setup steps. By part 2, you are learning about registers and numbers. Part 3 covers some instructions, and by part 4, he finds that there are even more registers to contend with.

One of the great things about doing a project like this today is that you don’t have to have real hardware. Even if you want to eventually run on real hardware, you can edit in comfort, compile on a fast machine, and then debug and test on an emulator. [Michal] uses VICE.

The series is far from complete, and we hear part 5 will talk about branching, so this is a good time to catch up.

We love applying modern tools to old software development.

Strenghtening FDM prints has been discussed in detail over the last years. Solutions and results vary as each one’s desires differ. Now [TenTech] shares his latest improvements on his post-processing script that he first created around January. This script literally bends your G-code to its will – using non-planar, interlocking sine wave deformations in both infill and walls. It’s now open-source, and plugs right into your slicer of choice: PrusaSlicer, OrcaSlicer, or Bambu Studio. If you’re into pushing your print strength past the limits of layer adhesion, but his former solution wasn’t quite the fit for your printer, try this improvement.

Traditional Fused Deposition Modeling (FDM) prints break along layer lines. What makes this script exciting is that it lets you introduce alternating sine wave paths between wall loops, removing clean break points and encouraging interlayer grip. Think of it as organic layer interlocking – without switching to resin or fiber reinforcement. You can tweak amplitude, frequency, and direction per feature. In fact, the deformation even fades between solid layers, allowing smoother transitions. Structural tinkering at its finest, not just a cosmetic gimmick.

This thing comes without needing a custom slicer. No firmware mods. Just Python, a little G-code, and a lot of curious minds. [TenTech] is still looking for real-world strength tests, so if you’ve got a test rig and some engineering curiosity, this is your call to arms.

The script can be found in his Github. View his full video here , get the script and let us know your mileage!

These days you can run Doom anywhere on just about anything, with things like porting Doom to JavaScript these days about as interesting as writing Snake in BASIC on one’s graphical calculator. In a twist, [Patrick Trainer] had the idea to use SQL instead of JS to do the heavy lifting of the Doom game loop. Backed by the Web ASM version of  the analytical DuckDB database software, a Doom-lite clone was coded that demonstrates the principle that anything in life can be captured in a spreadsheet or database application.

Rather than having the game world state implemented in JavaScript objects, or pixels drawn to a Canvas/WebGL surface, this implementation models the entire world state in the database. To render the player’s view, the SQL VIEW feature is used to perform raytracing (in SQL, of course). Any events are defined as SQL statements, including movement. Bullets hitting a wall or impacting an enemy result in the bullet and possibly the enemy getting DELETE-ed.

The role of JavaScript in this Doom clone is reduced to gluing the chunks of SQL together and handling sprite Z-buffer checks as well as keyboard input. The result is a glorious ASCII-based game of Doom which you can experience yourself with the DuckDB-Doom project on GitHub. While not very practical, it was absolutely educational, showing that not only is it fun to make domain specific languages do things they were never designed for, but you also get to learn a lot about it along the way.

Thanks to [Particlem] for the tip.

When was the last time you saw a computer actually outlast your weekend trip – and then some? Enter the Evertop, a portable IBM XT emulator powered by an ESP32 that doesn’t just flirt with low power; it basically lives off the grid. Designed by [ericjenott], hacker with a love for old-school computing and survivalist flair, this machine emulates 1980s PCs, runs DOS, Windows 3.0, and even MINIX, and stays powered for hundreds of hours. It has a built-in solar panel and 20,000mAh of battery, basically making it an old-school dream in a new-school shell.

What makes this build truly outstanding – besides the specs – is how it survives with no access to external power. It sports a 5.83-inch e-ink display that consumes zilch when static, hardware switches to cut off unused peripherals (because why waste power on a serial port you’re not using?), and a solar panel that pulls 700mA in full sun. And you guessed it – yes, it can hibernate to disk and resume where you left off. The Evertop is a tribute to 1980s computing, and a serious tool to gain some traction at remote hacker camps.

For the full breakdown, the original post has everything from firmware details to hibernation circuitry. Whether you’re a retro purist or an off-grid prepper, the Evertop deserves a place on your bench. Check out [ericjenott]’s project on Github here.

It’s amazing how quickly medical science made radiography one of its main diagnostic tools. Medicine had barely emerged from its Dark Age of bloodletting and the four humours when X-rays were discovered, and the realization that the internal structure of our bodies could cast shadows of this mysterious “X-Light” opened up diagnostic possibilities that went far beyond the educated guesswork and exploratory surgery doctors had relied on for centuries.

The problem is, X-rays are one of those things that you can’t see, feel, or smell, at least mostly; X-rays cause visible artifacts in some people’s eyes, and the pencil-thin beam of a CT scanner can create a distinct smell of ozone when it passes through the nasal cavity — ask me how I know. But to be diagnostically useful, the varying intensities created by X-rays passing through living tissue need to be translated into an image. We’ve already looked at how X-rays are produced, so now it’s time to take a look at how X-rays are detected and turned into medical miracles.

Taking Pictures

For over a century, photographic film was the dominant way to detect medical X-rays. In fact, years before Wilhelm Conrad Röntgen’s first systematic study of X-rays in 1895, fogged photographic plates during experiments with a Crooke’s tube were among the first indications of their existence. But it wasn’t until Röntgen convinced his wife to hold her hand between one of his tubes and a photographic plate to create the first intentional medical X-ray that the full potential of radiography could be realized.

The chemical mechanism that makes photographic film sensitive to X-rays is essentially the same as the process that makes light photography possible. X-ray film is made by depositing a thin layer of photographic emulsion on a transparent substrate, originally celluloid but later polyester. The emulsion is a mixture of high-grade gelatin, a natural polymer derived from animal connective tissue, and silver halide crystals. Incident X-ray photons ionize the halogens, creating an excess of electrons within the crystals to reduce the silver halide to atomic silver. This creates a latent image on the film that is developed by chemically converting sensitized silver halide crystals to metallic silver grains and removing all the unsensitized crystals.

Other than in the earliest days of medical radiography, direct X-ray imaging onto photographic emulsions was rare. While photographic emulsions can be exposed by X-rays, it takes a lot of energy to get a good image with proper contrast, especially on soft tissues. This became a problem as more was learned about the dangers of exposure to ionizing radiation, leading to the development of screen-film radiography.

In screen-film radiography, X-rays passing through the patient’s tissues are converted to light by one or more intensifying screens. These screens are made from plastic sheets coated with a phosphorescent material that glows when exposed to X-rays. Calcium tungstate was common back in the day, but rare earth phosphors like gadolinium oxysulfate became more popular over time. Intensifying screens were attached to the front and back covers of light-proof cassettes, with double-emulsion film sandwiched between them; when exposed to X-rays, the screens would glow briefly and expose the film.

By turning one incident X-ray photon into thousands or millions of visible light photons, intensifying screens greatly reduce the dose of radiation needed to create diagnostically useful images. That’s not without its costs, though, as the phosphors tend to spread out each X-ray photon across a physically larger area. This results in a loss of resolution in the image, which in most cases is an acceptable trade-off. When more resolution is needed, single-screen cassettes can be used with one-sided emulsion films, at the cost of increasing the X-ray dose.

Wiggle Those Toes

Intensifying screens aren’t the only place where phosphors are used to detect X-rays. Early on in the history of radiography, doctors realized that while static images were useful, continuous images of body structures in action would be a fantastic diagnostic tool. Originally, fluoroscopy was performed directly, with the radiologist viewing images created by X-rays passing through the patient onto a phosphor-covered glass screen. This required an X-ray tube engineered to operate with a higher duty cycle than radiographic tubes and had the dual disadvantages of much higher doses for the patient and the need for the doctor to be directly in the line of fire of the X-rays. Cataracts were enough of an occupational hazard for radiologists that safety glasses using leaded glass lenses were a common accessory.

One ill-advised spin-off of medical fluoroscopy was the shoe-fitting fluoroscopes that started popping up in shoe stores in the 1920s. Customers would stick their feet inside the machine and peer at a fluorescent screen to see how well their new shoes fit. It was probably not terribly dangerous for the once-a-year shoe shopper, but pity the shoe salesman who had to peer directly into a poorly regulated X-ray beam eight hours a day to show every Little Johnny’s mother how well his new Buster Browns fit.

As technology improved, image intensifiers replaced direct screens in fluoroscopy suites. Image intensifiers were vacuum tubes with a large input window coated with a fluorescent material such as zinc-cadmium sulfide or sodium-cesium iodide. The phosphors convert X-rays passing through the patient to visible light photons, which are immediately converted to photoelectrons by a photocathode made of cesium and antimony. The electrons are focused by coils and accelerated across the image intensifier tube by a high-voltage field on a cylindrical anode. The electrons pass through the anode and strike a phosphor-covered output screen, which is much smaller in diameter than the input screen. Incident X-ray photons are greatly amplified by the image intensifier, making a brighter image with a lower dose of radiation.

Originally, the radiologist viewed the output screen using a microscope, which at least put a little more hardware between his or her eyeball and the X-ray source. Later, mirrors and lenses were added to project the image onto a screen, moving the doctor’s head out of the direct line of fire. Later still, analog TV cameras were added to the optical path so the images could be displayed on high-resolution CRT monitors in the fluoroscopy suite. Eventually, digital cameras and advanced digital signal processing were introduced, greatly streamlining the workflow for the radiologist and technologists alike.

Get To The Point

So far, all the detection methods we’ve discussed fall under the general category of planar detectors, in that they capture an entire 2D shadow of the X-ray beam after having passed through the patient. While that’s certainly useful, there are cases where the dose from a single, well-defined volume of tissue is needed. This is where point detectors come into play.

In medical X-ray equipment, point detectors often rely on some of the same gas-discharge technology that DIYers use to build radiation detectors at home. Geiger tubes and ionization chambers measure the current created when X-rays ionize a low-pressure gas inside an electric field. Geiger tubes generally use a much higher voltage than ionization chambers, and tend to be used more for radiological safety, especially in nuclear medicine applications, where radioisotopes are used to diagnose and treat diseases. Ionization chambers, on the other hand, were often used as a sort of autoexposure control for conventional radiography. Tubes were placed behind the film cassette holders in the exam tables of X-ray suites and wired into the control panels of the X-ray generators. When enough radiation had passed through the patient, the film, and the cassette into the ion chamber to yield a correct exposure, the generator would shut off the X-ray beam.

Another kind of point detector for X-rays and other kinds of radiation is the scintillation counter. These use a crystal, often cesium iodide or sodium iodide doped with thallium, that releases a few visible light photons when it absorbs ionizing radiation. The faint pulse of light is greatly amplified by one or more photomultiplier tubes, creating a pulse of current proportional to the amount of radiation. Nuclear medicine studies use a device called a gamma camera, which has a hexagonal array of PM tubes positioned behind a single large crystal. A patient is injected with a radioisotope such as the gamma-emitting technetium-99, which accumulates mainly in the bones. Gamma rays emitted are collected by the gamma camera, which derives positional information from the differing times of arrival and relative intensity of the light pulse at the PM tubes, slowly building a ghostly skeletal map of the patient by measuring where the ⁹⁹Tc accumulated.

Going Digital

Despite dominating the industry for so long, the days of traditional film-based radiography were clearly numbered once solid-state image sensors began appearing in the 1980s. While it was reliable and gave excellent results, film development required a lot of infrastructure and expense, and resulted in bulky films that required a lot of space to store. The savings from doing away with all the trappings of film-based radiography, including the darkrooms, automatic film processors, chemicals, silver recycling, and often hundreds of expensive film cassettes, is largely what drove the move to digital radiography.

After briefly flirting with phosphor plate radiography, where a sensitized phosphor-coated plate was exposed to X-rays and then “developed” by a special scanner before being recharged for the next use, radiology departments embraced solid-state sensors and fully digital image capture and storage. Solid-state sensors come in two flavors: indirect and direct. Indirect sensor systems use a large matrix of photodiodes on amorphous silicon to measure the light given off by a scintillation layer directly above it. It’s basically the same thing as a film cassette with intensifying screens, but without the film.

Direct sensors, on the other hand, don’t rely on converting the X-ray into light. Rather, a large flat selenium photoconductor is used; X-rays absorbed by the selenium cause electron-hole pairs to form, which migrate to a matrix of fine electrodes on the underside of the sensor. The current across each pixel is proportional to the amount measured to the amount of radiation received, and can be read pixel-by-pixel to build up a digital image.

Sometimes in fantasy fiction, you don’t want to explain something that seems inexplicable, so you throw your hands up and say, “A wizard did it.” Sometimes in astronomy, instead of a wizard, the answer is dark matter (DM). If you are interested in astronomy, you’ve probably heard that dark matter solves the problem of the “missing mass” to explain galactic light curves, and the motion of galaxies in clusters.

Now [Pedro De la Torre Luque] and others are proposing that DM can solve another pair of long-standing galactic mysteries: ionization of the central molecular zone (CMZ) in our galaxy, and mysterious 511 keV gamma-rays.

The Central Molecular Zone is a region near the heart of the Milky Way that has a very high density of interstellar gases– around sixty million times the mass of our sun, in a volume 1600 to 1900 light years across. It happens to be more ionized than it ought to be, and ionized in a very even manner across its volume. As astronomers cannot identify (or at least agree on) the mechanism to explain this ionization, the CMZ ionization is mystery number one.

Mystery number two is a diffuse glow of gamma rays seen in the same part of the sky as the CMZ, which we know as the constellation Sagittarius. The emissions correspond to an energy of 515 keV, which is a very interesting number– it’s what you get when an electron annihilates with the antimatter version of itself. Again, there’s no universally accepted explanation for these emissions.

So [Pedro De la Torre Luque] and team asked themselves: “What if a wizard did it?” And set about trying to solve the mystery using dark matter. As it turns out, computer models including a form of light dark matter (called sub-GeV DM in the paper, for the particle’s rest masses) can explain both phenomena within the bounds of error.

In the model, the DM particles annihilate to form electron-positron pairs. In the dense interstellar gas of the CMZ, those positrons quickly form electrons to produce the 511 keV gamma rays observed. The energy released from this annihilation results in enough energy to produce the observed ionization, and even replicate the very flat ionization profile seen across the CMZ. (Any other proposed ionization source tends to radiate out from its source, producing an uneven profile.) Even better, this sort of light dark matter is consistent with cosmological observations and has not been ruled out by Earth-side dark matter detectors, unlike some heavier particles.

Further observations will help confirm or deny these findings, but it seems dark matter is truly the gift that keeps on giving for astrophysicists. We eagerly await what other unsolved questions in astronomy can be answered by it next, but it leaves us wondering how lazy the universe’s game master is if the answer to all our questions is: “A wizard did it.”

We can’t talk about dark matter without remembering [Vera Rubin].

Building a Commodore 64 is among the easier projects for retrocomputing fans to tackle. That’s because the C64’s core chipset does most of the heavy lifting; source those and you’re probably 80% of the way there. But what if you can’t find those chips, or if you want more of a challenge than plugging and chugging? Are you out of luck?

Hardly. The video below from [DrMattRegan] is the first in a series on his scratch-built C64 that doesn’t use the core chipset, and it looks pretty promising. This video concentrates on building a replacement for the 6502 microprocessor — actually the 6510, but close enough — using just a couple of EPROMs, some SRAM chips, and a few standard logic chips to glue everything together. He uses the EPROMs as a “rulebook” that contains the code to emulate the 6502 — derived from his earlier Turing 6502 project — and the SRAM chips as a “notebook” for scratch memory and registers to make a Turing-complete random access machine.

[DrMatt] has made good progress so far, with the core 6502 CPU built on a PCB and able to run the Apple II version of Pac-Man as a benchmark. We’re looking forward to the rest of this series, but in the meantime, a look back at his VIC-less VIC-20 project might be informative.

Thanks to [Clint] for the tip.

If you’ve ever fumbled through circuit simulation and ended up with a flatline instead of a sine wave, this video from [saisri] might just be the fix. In this walkthrough she demonstrates simulating a Colpitts oscillator using NI Multisim 14.3 – a deceptively simple analog circuit known for generating stable sine waves. Her video not only shows how to place and wire components, but it demonstrates why precision matters, even in virtual space.

You’ll notice the emphasis on wiring accuracy at multi-node junctions, something many tutorials skim over. [saisri] points out that a single misconnected node in Multisim can cause the circuit to output zilch. She guides viewers step-by-step, starting with component selection via the “Place > Components” dialog, through to running the simulation and interpreting the sine wave output on Channel A. The manual included at the end of the video is a neat bonus, bundling theory, waveform visuals, and circuit diagrams into one handy PDF.

If you’re into precision hacking, retro analogue joy, or just love watching a sine wave bloom onscreen, this is worth your time. You can watch the original video here.

Using steam to produce electricity or perform work via steam turbines has been a thing for a very long time. Today it is still exceedingly common to use steam in this manner, with said steam generated either by burning something (e.g. coal, wood), by using spicy rocks (nuclear fission) or from stored thermal energy (e.g. molten salt). That said, today we don’t use steam in the same way any more as in the 19th century, with e.g. supercritical and pressurized loops allowing for far higher efficiencies. As covered in a recent video by [Ryan Inis], a more recent alternative to using water is supercritical carbon dioxide (CO₂), which could boost the thermal efficiency even further.

In the video [Ryan Inis] goes over the basics of what the supercritical fluid state of CO2 is, which occurs once the critical point is reached at 31°C and 83.8 bar (8.38 MPa). When used as a working fluid in a thermal power plant, this offers a number of potential advantages, such as the higher density requiring smaller turbine blades, and the potential for higher heat extraction. This is also seen with e.g. the shift from boiling to pressurized water loops in BWR & PWR nuclear plants, and in gas- and salt-cooled reactors that can reach far higher efficiencies, as in e.g. the HTR-PM and MSRs.

In a 2019 article in Power the author goes over some of the details, including the different power cycles using this supercritical fluid, such as various Brayton cycles (some with extra energy recovery) and the Allam cycle. Of course, there is no such thing as a free lunch, with corrosion issues still being worked out, and despite the claims made in the video, erosion is also an issue with supercritical CO₂ as working fluid. That said, it’s in many ways less of an engineering issue than supercritical steam generators due to the far more extreme critical point parameters of water.

If these issues can be overcome, it could provide some interesting efficiency boosts for thermal plants, with the caveat that likely nobody is going to retrofit existing plants, supercritical steam (coal) plants already exist and new nuclear plant designs are increasingly moving towards gas, salt and even liquid metal coolants, though secondary coolant loops (following the typical steam generator) could conceivably use CO₂ instead of water where appropriate.