Spade is an open-source hardware description language (HDL) developed at Linköping University, Sweden.

Other HDLs you might have heard of include Verilog and VHDL. Hardware engineers use HDLs to define hardware which can be rendered in silicon. Hardware defined in HDLs might look like software, but actually it’s not software, it’s hardware description. This hardware can be realized myriad ways including in an FPGA or with an ASIC.

You have probably heard that your CPU processes instructions in a pipeline. Spade has first-class support for such pipelines. This means that design activities such as re-timing and re-pipelining are much easier than in other HDLs where the designer has to implement these by hand. (Note: backward justification is NP-hard, we’re not sure how Spade supports this, if it does at all. If you know please enlighten us in the comments!)

Spade implements a type system for strong and static typing inspired by the Rust programming language and can do type inference. It supports pattern matching such as you might see in a typical functional programming language. It boasts having user-friendly and helpful error messages and tooling.

Spade is a work in progress so please expect missing features and breaking changes. The documentation is in The Spade Book. If you’re interested you can follow development on GitLab or Discord.

So now that you know about the Spade language, are you planning to take it for a spin? You will find plenty of Verilog/VHDL designs at Hackaday which you could re-implement using Spade, such as an easy one like Breathing LED Done With Raw Logic Synthesized From A Verilog Design (see benchmarks) or a much more challenging one like Game Boy Recreated In Verilog. If you give Spade a go we’d love to see what you come up with!

From Blog – Hackaday via this RSS feed

Sick of raiding old TVs and CRT monitors for flyback transformers to feed your high-voltage addiction? Never fear; if you’re careful, a 3D-printed flyback might be just the thing you’re looking for.

To be fair, it’s pretty easy to come by new flyback transformers, so building your own isn’t strictly necessary. But [SciTubeHD] was in the market for a particularly large flyback, in a good-natured effort to displace [Jay Bowles] from his lofty perch atop the flyback heap. And it’s also true that this project isn’t entirely 3D-printed, as the split core of the transformer was sourced commercially. The secondary coil, though, was where most of the effort went, with a secondary form made from multiple snap-together discs epoxied together for good measure. The secondary has about a kilometer of 30-gauge magnet wire while the primary holds just ten turns of 8-gauge wire covered with silicone high-voltage insulation.

To decrease the likelihood of arcing, the transformer was placed in a plastic container filled with enough mineral oil liquid dielectric to cover the secondary. After degassing in a vacuum chamber for a day, [SciTubeHD] hooked the primary to a couple of different but equally formidable-looking full-bridge inverters for testing. The coil was capable of some pretty spicy arcs — [SciTubeHD] measured 20 amps draw at 35 volts AC input, so this thing isn’t to be trifled with. STL files for the core parts are coming up soon; we trust schematics for the power supply will be available, too.

From Blog – Hackaday via this RSS feed

With all the attention on LLMs (Large Language Models) and image generators lately, it’s nice to see some of the more niche and unusual applications of machine learning. GARF (Generalizeable 3D reAssembly for Real-world Fractures) is one such project.

GARF may play fast and loose with acronym formation, but it certainly knows how to be picky when it counts. Its whole job is to look at the pieces of a broken object and accurately figure out how to fit the pieces back together, even if there are some missing bits or the edges aren’t clean.

Re-assembling an object from imperfect fragments is a nontrivial undertaking.

Efficiently and accurately figuring out how to re-assemble different pieces into a whole is not a trivial task. One may think it can in theory be brute-forced, but the complexity of such a job rapidly becomes immense. That’s where machine learning methods come in, as researchers created a system that can do exactly that. It addresses the challenge of generalizing from a synthetic data set (in which computer-generated objects are broken and analyzed for training) and successfully applying it to the kinds of highly complex breakage patterns that are seen in real-world objects like bones, recovered archaeological artifacts, and more.

The system is essentially a highly adept 3D puzzle solver, but an entirely different beast from something like this jigsaw puzzle solving pick-and-place robot. Instead of working on flat pieces with clean, predictable edges it handles 3D scanned fragments with complex break patterns even if the edges are imperfect, or there are missing pieces.

GARF is exactly the kind of software framework that is worth keeping in the back of one’s mind just in case it comes in handy some day. The GitHub repository contains the code (although at this moment the custom dataset is not yet uploaded) but there is also a demo available for the curious.

From Blog – Hackaday via this RSS feed

Have you ever felt the urge to make your own private binary format for use in Linux? Perhaps you have looked at creating the smallest possible binary when compiling a project, and felt disgusted with how bloated the ELF format is? If you are like [Brian Raiter], then this has led you down many rabbit holes, with the conclusion being that flat binary formats are the way to go if you want sleek, streamlined binaries. These are formats like COM, which many know from MS-DOS, but which was already around in the CP/M days. Here ‘flat’ means that the entire binary is loaded into RAM without any fuss or foreplay.

Although Linux does not (yet) support this binary format, the good news is that you can learn how to write kernel modules by implementing COM support for the Linux kernel. In the article [Brian] takes us down this COM rabbit hole, which involves setting up a kernel module development environment and exploring how to implement a binary file format. This leads us past familiar paths for those who have looked at e.g. how the Linux kernel handles the shebang (#!) and ‘misc’ formats.

On Windows, the kernel identifies the COM file by its extension, after which it gives it 640 kB & an interrupt table to play with. The kernel module does pretty much the same, which still involves a lot of code.

Of course, this particular rabbit hole wasn’t deep enough yet, so the COM format was extended into the .♚ (Unicode U+265A) format, because this is 2025 and we have to use all those Unicode glyphs for something. This format extension allows for amazing things like automatically exiting after finishing execution (like crashing).

At the end of all these efforts we have not only learned how to write kernel modules and add new binary file formats to Linux, we have also learned to embrace the freedom of accepting the richness of the Unicode glyph space, rather than remain confined by ASCII. All of which is perfectly fine.

Top image: Illustration of [Brian Raiter] surveying the fruits of his labor by [Bomberanian]

From Blog – Hackaday via this RSS feed

We don’t think of computers as something you’d find in the 17th century. But [Levi McClain] found plans for one in a book — books, actually — by [Athanasius Kirker] about music. The arca musarithmica, a machine to allow people with no experience to compose church music, might not fit our usual definition of a computer, but as [Levi] points out in the video below, there are a number of similarities to mechanical computers like slide rules.

Apparently, there are a few of these left in the world, but as you’d expect, they are quite rare. So [Levi] decided to take the plans from the book along with some information available publicly and build his own.

The computer is a box of wooden cards — tablets — with instructions written on them. Honestly, we don’t know enough about music theory to quite get the algorithm. [Kirker] himself had this to say in his book about the device:

Mechanical music-making is nothing more than a particular system invented by us whereby anyone, even the ἀμουσος [unmusical] may, through various applications of compositional instruments compose melodies according to a desired style. We shall briefly relate how this mechanical music-making is done and, lest we waste time with prefatory remarks, we shall begin with the construction of the Musarithmic Ark.

If you want to try it yourself, you won’t need to break out the woodworking tools. You can find a replica on the web, of course. Let us know if you set any Hackaday posts to music.

We know not everyone thinks something mechanical can be a computer, but we disagree. True, some are more obvious than others.

From Blog – Hackaday via this RSS feed

Incomplete JSON (such as from a log that terminates unexpectedly) doesn’t parse cleanly, which means anything that usually prints JSON nicely, won’t. Frustration with this is what led [Simon Willison] to make The Incomplete JSON pretty printer, a single-purpose web tool that pretty-prints JSON regardless of whether it’s complete or not.

Making a tool to solve a particular issue is a fantastic application of software, but in this case it also is a good lead-in to some thoughts [Simon] has to share about vibe coding. The incomplete JSON printer is a perfect example of vibe coding, being the product of [Simon] directing an LLM to iteratively create a tool and not looking at the actual code once.

Sometimes, however the machine decides to code something is fine.

[Simon] shares that the term “vibe coding” was first used in a social media post by [Andrej Karpathy], who we’ve seen shared a “hello world” of GPT-based LLMs as well as how to train one in pure C, both of which are the product of a deep understanding of the subject (and fantastically educational) so he certainly knows how things work.

Anyway, [Andrej] had a very specific idea he was describing with vibe coding: that of engaging with the tool in almost a state of flow for something like a weekend project, just focused on iterating one’s way to what they want without fussing the details. Why? Because doing so is new, engaging, and fun.

Since then, vibe coding as a term seems to get used to refer to any and all AI-assisted coding, a subject on which folks have quite a few thoughts (many of which were eagerly shared on a recent Ask Hackaday on the subject).

Of course human oversight is critical to a solid and reliable development workflow. But not all software is the same. In the case of the Incomplete JSON Pretty Printer, [Simon] really doesn’t care what the code actually looks like. He got it made in a short amount of time, the tool does exactly what he wants, and it’s hard to imagine the stakes being any lower. To [Simon], however the LMM decided to do things is fine, and there’s a place for that.

From Blog – Hackaday via this RSS feed

The “USB C” cable that comes with the Inaya Portable Rechargeable Lamp. (Credit: The Stock Pot, YouTube)

Recently [Dillan Stock] over at The Stock Pot YouTube channel bought a $17 ‘mushroom’ lamp from his local Kmart that listed ‘USB-C rechargeable’ as one of its features, the only problem being that although this is technically true, there’s a major asterisk. This Inaya-branded lamp namely comes with a USB-C cable with a rather prominent label attached to it that tells you that this lamp requires that specific cable. After trying with a regular USB-C cable, [Dillan] indeed confirmed that the lamp does not charge from a standard USB-C cable. So he did what any reasonable person would do: he bought a second unit and set about to hacking it.

[Dillan] also dug more into what’s so unusual about this cable and the connector inside the lamp. As it turns out, while GND & Vcc are connected as normal, the two data lines (D+, D-) are also connected to Vcc. Presumably on the lamp side this is the expected configuration, while using a regular USB-C cable causes issues. Vice versa, this cable’s configuration may actually be harmful to compliant USB-C devices, though [Dillan] did not try this.

With the second unit in hand, he then started hacking it, with the full plans and schematic available on his website.

The changes include a regular USB-C port for charging, an ESP32 board with integrated battery charger for the 18650 Li-ion cell of the lamp, and an N-channel MOSFET to switch the power to the lamp’s LED. With all of the raw power from the ESP32 available, the two lamps got integrated into the Home Assistant network which enables features such as turning the lamps on when the alarm goes off in the morning. All of this took about $7 in parts and a few hours of work.

Although we can commend [Dillan] on this creative hack rather than returning the item, it’s worrying that apparently there’s now a flood of ‘USB C-powered’ devices out there that come with non-compliant cables that are somehow worse than ‘power-only’ USB cables. It brings back fond memories of hunting down proprietary charging cables, which was the issue that USB power was supposed to fix.

From Blog – Hackaday via this RSS feed

Lots of people swear by large-language model (LLM) AIs for writing code. Lots of people swear at them. Still others may be planning to exploit their peculiarities, according to [Joe Spracklen] and other researchers at USTA. At least, the researchers have found a potential exploit in ‘vibe coding’.

Everyone who has used an LLM knows they have a propensity to “hallucinate”– that is, to go off the rails and create plausible-sounding gibberish. When you’re vibe coding, that gibberish is likely to make it into your program. Normally, that just means errors. If you are working in an environment that uses a package manager, however (like npm in Node.js, or PiPy in Python, CRAN in R-studio) that plausible-sounding nonsense code may end up calling for a fake package.

A clever attacker might be able to determine what sort of false packages the LLM is hallucinating, and inject them as a vector for malicious code. It’s more likely than you think– while CodeLlama was the worst offender, the most accurate model tested (ChatGPT4) still generated these false packages at a rate of over 5%. The researchers were able to come up with a number of mitigation strategies in their full paper, but this is a sobering reminder that an AI cannot take responsibility. Ultimately it is up to us, the programmers, to ensure the integrity and security of our code, and of the libraries we include in it.

We just had a rollicking discussion of vibe coding, which some of you seemed quite taken with. Others agreed that ChatGPT is the worst summer intern ever. Love it or hate it, it’s likely this won’t be the last time we hear of security concerns brought up by this new method of programming.

Special thanks to [Wolfgang Friedrich] for sending this into our tip line.

From Blog – Hackaday via this RSS feed

It started when [Mitxela] was faced with about a hundred incorrectly-placed 0603 parts. Given that he already owned two TS101 soldering irons, a 3D printer, and knows how to use FreeCAD (he had just finished designing a custom TS101 holder) it didn’t take long to create cost-effective DIY soldering tweezers.

Two screws allow adjusting the irons to ensure the tips line up perfectly.

The result works great! The TS101 irons are a friction-fit and the hinge (designed using the that-looks-about-right method) worked out just fine on the first try. Considering two TS101 irons are still cheaper than any soldering tweezer he could find, and one can simply undock the TS101s as needed, we call this a solid win.

One feature we really like is being able to precisely adjust the depth of each iron relative to each other, so that the tips can be made to line up perfectly. A small screw and nut at the bottom end of each holder takes care of that. It’s a small but very thoughtful design feature.

Want to give it a try? The FreeCAD design file (and .stl model) is available from [Mitxela]’s project page. Just head to the bottom to find the links.

We’ve seen DIY soldering tweezers using USB soldering irons from eBay but the TS101 has a form factor that seems like a particularly good fit.

From Blog – Hackaday via this RSS feed

Earlier this year, I bought one of those K40-style laser machines that was listed at a ridiculously low price, and it arrived broken. Well, let me qualify that: the laser tube and the power supply work perfectly, but that’s about the best you can say about it.

On first power-up, it made a horrible noise, the Y-axis was jammed, the X-axis was so off-square that it was visibly apparent, and it turned out that as I fixed one of these problems after the other, that it was just the tip of the iceberg. The Y-axis was jammed because the belts were so tight that they made the motor bind. Replacing them, because they were simply too short, got the stage moving, but it didn’t engage the endstops. Fixing those revealed that the motor was stepped wrong, and flipping the pins in the connector finally got it homing in the right direction. Full disassembly and reassembly steps required at each stage here.

The X-axis just needed adjustment, but the opto on its endstop had been completely crushed by a previous failed homing, and I had to desolder and resolder in a new one. (Keep your junkbox well stocked!) With the machine working, it became obvious that the driver board was barely usable. It accelerates horribly jerkily, which makes the motors skip and stall. It had to be run artificially slowly because it couldn’t make the corners. So I put in a new motor controller board that handles Gcode and does legitimate acceleration ramps.

Movement mostly fixed, it was time to align the laser. Of course, the optical path is all messed up, they forgot the o-ring that holds the focusing lens in place, and the thing keeps powering down randomly. This turns out to be because of the aiming red laser pointer, which has a positive case, which is shorting through the single wrap of electrical tape that “insulates” it from the machine’s frame. When this shorts, the motor driver board browns out. Lovely!

Once I was finally able to start aligning the beam, I discovered that the frame is warped out of plane. The simple solution is to take it all apart again and shim it until it’s flat, but I just haven’t had the time yet. I’m not beaten, but it’s been eating up hours after hours on the weekends, and that time is scarce.

I love DIY, and I love taking a machine apart in order to understand it. Once. But I’m now on my tenth or twelfth unmounting of the motion stage, and frankly, it’s no fun any more. It would have been quicker, if maybe not cheaper, to have built this machine entirely from scratch. At least for the moment, I’ve bitten off more than I have time to chew.

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

From Blog – Hackaday via this RSS feed

Most robots depend on controlled environments, because the real world is hard to get around in. The smaller the robot, the bigger this problem because little wheels (or legs) can take only little steps. One way around that is MIT’s latest one-legged hopping robot, which sports a set of four insect-like wings on its top end and can quickly pogo-hop its way across different terrain with ease.

The four wings provide lift, and steer the robot so that its single leg lands precisely.

The wings aren’t for flying in the usual sense. They provide lift, but also help the tiny device steer itself so that its hops land precisely. Earlier incarnations of one-legged hopping robots (like this one) accomplished this with propellers and electric motors, but traditional motors are a non-starter on a device that weighs less than a paperclip.

Right now, this little winged hopper is not completely self-contained (power and control systems are off-board) but running it as a tethered unit allows researchers to test and evaluate different, minimalistic ways for a machine to move around efficiently. And efficiency is the whole goal of going in this direction.

Certainly tiny flying drones already exist and get about in the real world just fine. But if one wants to shed mass, ditch conventional motors, and reduce cost and power consumption, this tiny winged hopping machine is one way to do it. And it can even carry payloads! The payloads are tiny, of course, but being able to haul around ten times one’s own weight and still function reliably is an impressive feat.

You can watch it in action in the video embedded just below the page break. Once you’ve watched that, we’d like to remind you that novel locomotion isn’t just the domain of hopping robots. Tiny robots with explosive joints is just as wild as it sounds.

From Blog – Hackaday via this RSS feed

Sound hardware has been built into PC motherboards for so long now it’s difficult to remember the days when a sound card was an expensive add-on peripheral. By the mid to late 1990s they were affordable and ubiquitous enough to be everywhere, but three decades later some of them are starting to fail. [Necroware] takes us through the repair of a couple of Creative Labs Sound Blaster 16s, which were the card to have back then.

The video below is a relaxed look at typical problems afflicting second-hand cards with uncertain pasts. There’s a broken PCB trace on the first one, which receives a neat repair. The second one has a lot more wrong with it though, and reveals some surprises. We would have found the dead 74 series chips, but we’re not so sure we’d have immediately suspected a resistor network as the culprit.

Watching these cards become sought-after in the 2020s is a little painful for those of us who were there at the time, because it’s certain we won’t be the only ones who cleared out a pile of old ISA cards back in the 2000s. If you find one today and don’t have an ISA slot, worry not, because you can still interface it via your LPC bus.

From Blog – Hackaday via this RSS feed

One of the delights in Bash, zsh, or whichever shell tickles your fancy in your OSS distribution of choice, is the ease of which you can use scripts. These can be shell scripts, or use the Perl, Python or another interpreter, as defined by the shebang (#!) at the beginning of the script. This signature is followed by the path to the interpret, which can be /bin/sh for maximum compatibility across OSes, but how does this actually work? As [Bruno Croci] found while digging into this question, it is not the shell that interprets the shebang, but the kernel.

It’s easy enough to find out the basic execution sequence using strace after you run an executable shell script with said shebang in place. The first point is in execve, a syscall that gets one straight into the Linux kernel (fs/exec.c). Here the ‘binary program’ is analyzed for its executable format, which for the shell script gets us to binfmt_script.c. Incidentally the binfmt_misc.c source file provides an interesting detour as it concerns magic byte sequences to do something similar as a shebang.

As a bonus [Bruno] also digs into the difference between executing a script with shebang or running it in a shell (e.g. sh script.sh), before wrapping up with a look at where the execute permission on a shebang-ed shell script is checked.

From Blog – Hackaday via this RSS feed

Human biology is very much like that of other mammals, and yet so very different in areas where it matters. One of these being human neurology, with aspects like the human brain and the somatosensory pathways (i.e. touch etc.) being not only hard to study in non-human animal analogs, but also (genetically) different enough that a human test subject is required. Over the past years the use of human organoids have come into use, which are (parts of) organs grown from human pluripotent stem cells and thus allow for ethical human experimentation.

For studying aspects like the somatosensory pathways, multiple of such organoids must be combined, with recently [Ji-il Kim] et al. as published in Nature demonstrating the creation of a so-called assembloid. This four-part assembloid contains somatosensory, spinal, thalamic and cortical organoids, covering the entirety of such a pathway from e.g. one’s skin to the brain’s cortex where the sensory information is received.

Such assembloids are – much like organoids – extremely useful for not only studying biological and biochemical processes, but also to research diseases and disorders, including tactile deficits as previously studied in mouse models by e.g. [Lauren L. Orefice] et al. caused by certain genetic mutations in Mecp2 and other genes, as well as genes like SCN9A that can cause clinical absence of pain perception.

Using these assembloids the development of these pathways can be studied in great detail and therapies developed and tested.

From Blog – Hackaday via this RSS feed

Over on the Google blog [Joel Meares] explains how Google built the new family of Gemini Robotics models.

The bi-arm ALOHA robot equipped with Gemini 2.0 software can take general instructions and then respond dynamically to its environment as it carries out its tasks. This family of robots aims to be highly dexterous, interactive, and general-purpose by applying the sort of non-task-specific training methods that have worked so well with LLMs, and applying them to robot tasks.

There are two things we here at Hackaday are wondering. Is there anything a robot will never do? And just how cherry-picked are these examples in the slick video? Let us know what you think in the comments!

From Blog – Hackaday via this RSS feed

There are some ideas which someone somewhere has to try. Take [Uri Tuchman]’s foot mouse. It’s a computer mouse for foot operation, but it’s not just a functional block. Instead it’s an ornate inlaid-wood-and-brass affair in the style of a very fancy piece of antique footwear.

The innards of an ordinary USB mouse are placed in something best described as a wooden platform heel, upon which is placed a brass sole with a couple of sections at the front to activate the buttons with the user’s toes. The standout feature is the decoration. With engraving on the brass and inlaid marquetry on the wood, it definitely doesn’t look like any computer peripheral we’ve seen.

The build video is below the break, and we’re treated to all the processes sped up. At the end he uses it in a basic art package and in a piloting game, with varying degrees of succes. We’re guessing it would take a lot of practice to gain a level of dexterity with this thing, but we salute him for being the one who tries it.

This has to be the fanciest peripheral we’ve ever seen, but surprisingly it’s not the first foot mouse we’ve brought you.

From Blog – Hackaday via this RSS feed

GPS and similar satellite navigation systems revolutionized how you keep track of where you are and what time it is. However, it isn’t without its problems. For one, it generally doesn’t work very well indoors or in certain geographic or weather scenarios. It can be spoofed. Presumably, a real or virtual attack could take the whole system down.

Addressing these problems is a new system called Broadcast Positioning System (BPS). It uses upgraded ATSC 3.0 digital TV transmitters to send exact time information from commercial broadcast stations. With one signal, you can tell what time it is within 100 ns 95% of the time. If you can hear four towers, you can not only tell the time, but also estimate your position within about 100 m.

The whole thing is new — we’ve read that there are only six transmitters currently sending such data. However, you can get a good overview from these slides from the National Association of Broadcasters. They point out that the system works well indoors and can work with GPS, help detect if GPS is wrong, and stand in for GPS if it were to go down suddenly.

If all digital TV stations adopt this, the presentation mentions that there would be 516 VHF stations operating with up to 10 kW over two widely separated bands. That adds to 1,526 UHF stations running between 100 kW to 1000 kW. So lots of power and very diverse in terms of frequencies. Coverage is spotty in some parts of the country, though. A large part of the western United States would lack visibility of the four stations required for a position fix. Of course, currently there are only five or six stations, so this is theoretical at this point.

The Real Story

If you read the slide deck, the real story is at the end in the backup slides. That shows the ATSC standard frame and how the preamble changes. The math is fairly standard stuff. You know where the stations are, you know what time they think they sent the signal, and you can estimate the range to each station. With three or four stations, you can get a good idea of where you must be based on the relative receive times.

The stations diversify their time sources, which helps guard against spoofing. For example, they may get time information from GPS, the network, a local atomic clock, and even neighboring stations, and use that to create an accurate local time that they send out with their signal.

Learn More

Most of the slides come from more detailed white papers you can find on the NAB website. A lot of the site is dedicated to explaining why you can’t live without GPS, but you can’t depend on it, either. The bottom right part of the page has the technical papers you’ll probably be more interested in.

GPS is an impressive system, but we know it needs some help. BPS reminded us a bit of LORAN.

From Blog – Hackaday via this RSS feed

Join Hackaday Editors Elliot Williams and Tom Nardi as they talk about the best stories and hacks of the week. This episode starts off with a discussion of the Vintage Computer Festival East and Philadelphia Maker Faire — two incredible events that just so happened to be scheduled for the same weekend. From there the discussion moves on to the latest developments in DIY soft robotics, the challenge of running Linux on 8-pin ICs, hardware mods to improve WiFi reception on cheap ESP32 development boards, and what’s keeping old smartphones from being reused as general purpose computers.

You’ll also hear about Command and Conquer: Red Alert running on the Pi Pico 2, highly suspect USB-C splitters, and producing professional looking PCBs at home with a fiber laser. Stick around to the end to hear about the current state of non-Google web browsers, and a unique new machine that can engrave circuit boards with remarkable accuracy.

Check out the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

As always, the Hackaday Podcast is available as a DRM-free MP3 download.

Where to Follow Hackaday Podcast

Places to follow Hackaday podcasts:

iTunesSpotifyStitcherRSSYouTubeCheck out our Libsyn landing page

Episode 316 Show Notes:

News:

Celebrating 30 Years Of Windows 95 At VCFIn 2025, The Philly Maker Faire Finds Its Groove

What’s that Sound?

Congratulations to [laserkiwi] for winning a Hackaday Podcast t-shirt!

Interesting Hacks of the Week:

Salamander Robot Is Squishy The Future of Robots is Soft (and Squishy!) – YouTubeThese Electronics-free Robots Can Walk Right Off the 3D-PrinterFlowIO Platform8 Pins For Linux Building The Worst Linux PC EverSimple Antenna Makes For Better ESP32-C3 WiFi ESP32 Range Extender / Antenna ModificationLayerLapse Simplifies 3D Printer Time-lapse ShotsTurning Old Cellphones Into SBCs IOIO – WikipediaBen Eater Vs. Microsoft BASIC A Very Trippy Look At Microsoft’s Beginnings

Quick Hacks:

Elliot’s Picks: A Tiny Tape SynthIf You’re 3D Scanning, You’ll Want A Way To Work With Point CloudsWhy USB-C Splitters Can Cause Magic Smoke ReleaseTom’s Picks: Tracking The ISS Made EasyCommand And Conquer Ported To The Pi Pico 2Fiber Laser Gives DIY PCBs A Professional Finish

Can’t-Miss Articles:

Which Browser Should I Use In 2025? qutebrowserSupercon 2024: Quick High-Feature Boards With The Circuit Graver

From Blog – Hackaday via this RSS feed

If you are a visual thinker, you might enjoy [AIHVHIA’s] recent video, which shows the effect of applying audio processing to text displayed on an oscilloscope. The video is below.

Of course, this presupposes you have some way to display text on an oscilloscope. Audio driving the X and Y channels of the scope does all the work. We aren’t sure exactly how he’s doing that, but we suspect it is something like Osci-Render.

Does this have any value other than art? It’s hard to say. Perhaps the effect of panning audio on text might give you some insight into your next audio project. Incidentally, panning certainly did what you would expect it to do, as did the pass filters. But some of the effects were a bit surprising. We still want to figure out just what’s happening with the wave folder.

If text isn’t enough for you, try video. Filtering that would probably be pretty entertaining, too. If you want to try your own experiments, we bet you could do it all — wave generation and filtering — in GNU Radio.

From Blog – Hackaday via this RSS feed

AI continues to be used in new and exciting ways… like generating spam messages. Yes, it was inevitable, but we now have spammers using LLM to generate unique messages that don’t register as spam. AkiraBot is a Python-powered tool, designed to evade CAPTCHAs, and post sketchy SEO advertisements to web forms and chat boxes around the Internet.

AkiraBot uses a bunch of techniques to look like a legitimate browser, trying to avoid triggering CAPTCHAs. It also runs traffic through a SmartProxy service to spread the apparent source IP around. Some captured logs indicate that of over 400,000 attempted victim sites, 80,000 have successfully been spammed.

SSRF Attacking AWS

March brought a spike in instances of an interesting EC2 attack. F5 labs has the details, and it’s really pretty simple. Someone is sending requests ending in /?url=hxxp://169.254.169.254/latest/meta-data/iam/security-credentials/, with the hope that the site is vulnerable to a Server Side Request Forgery (SSRF).

That IP address is an interesting one. It’s the location where Amazon EC2 makes the Instance Metadata Service available (IMDSv1). Version 1 of this service completely lacks authentication, so a successful SSRF can expose whatever information that service makes available. And that can include AWS credentials and other important information. The easiest fix is to upgrade the instance to IMDSv2, which does have all the authentication features you’d expect.

SAP and setuid

Up next is this Anvil Secure report from [Tao Sauvage], about finding vulnerable setuid binaries in the SAP Linux images.

Setuid is a slightly outdated way to allow a less-privileged user to run a binary with elevated privileges. The simplest example is ping, which needs raw socket access to send special ICMP packets. The binary is launched by the user, escalates its privileges to send the packet, and then terminates without actually breaking the security barrier. At least that’s what is supposed to happen. In reality, setuid binaries are a consistent source of privilege escalation problems on Linux. So much so, that it’s now preferred to use the capabilities functionality to achieve this. But that’s fairly new, and many distros just give binaries like ping the setuid bit.

This brings us to SAP’s Linux images, like SAP HANA Express. These images include a small collection of custom setuid binaries, with icmbnd and hostexecstart catching our researcher’s eyes. icmbnd notably has the -f flag to specify the output file for a debug trace. That’s a typical setuid problem, in that a user can specify an oddball location, and the binary will change the system’s state in unexpected ways. It’s an easy denial of service attack, but is there a way to actually get root? It turns out the the Linux /etc/passwd file is particularly resilient. Lines that don’t make any sense as password entries are just ignored. Inject a pair of newlines and a single valid passwd entry into the passwd file, and you too can be root on an SAP system.

The hostexecstart vulnerability is a bit more involved. That binary starts and stops the SAP Host Agent on the system. That would be a dead end, except it can also take a SAR archive and upgrade the system agent. [Tao] chased a couple of dead ends regarding library injection and SAR archive signing, before finally using another standard setuid technique, the symbolic link. In this case, link the /etc/passwd file to the local sapcar_output location, and include a malicious passwd line inside a cooked SAR archive. hostexecstart tries to unpack the archive, and outputs the log right into the local sapcar_output file. But that file is really a symbolic link, and it once again clobbers passwd.

Google’s Take on End-to-end-encryption

We’re fans of end-to-end encryption around here. If Alice had a message that’s only intended for Bob to see, then it seems only right that Bob is really the only one that can read the message. The reality of modern cryptography is that this is 100% possible via RSA encryption, and the entire variety of asymmetric encryption schemes that followed. The problem with actually using such encryption is that it’s a pain. Between managing keys, getting an email client set up properly, and then actually using the system in practice, end-to-end asymmetric encryption is usually just not worth the hassle for everyday people.

Google feels that pain, and is bringing easy end-to-end encryption to business Gmail accounts. Except, it’s not actually asymmetric encryption. This works using the key access control list (KACL). Here Alice writes a message, and asks the KACL server for a key to use to send it to Bob. The server provides a symmetric key, and Alice encrypts the message. Then when Bob receives the message, he asks the same server for the same key, and the server provides it, allowing him to decrypt the message.

So is this actually end-to-end encryption? Yes, but also no. While this solution does mean that Google never has the key needed to decrypt the message, it also means that whoever is running the KACL server does have that key. But it is better than the alternative. And the technique in use here could be adapted to make true symmetric encryption far easier for end users.

Ivanti Connect Active Exploit

Google’s Mandiant has announced that Ivanti Connect Secure boxes are under active exploitation via an n-day exploit. This is a buffer overflow that Ivanti discovered internally, and patched in February of this year. The overflow was considered to be strictly limited to denial of service, as the characters written to memory could only be digits and the dot symbol. If that sounds like an IP address, just hang on, and we’ll get there.

It’s apparent that malware actors around the world are actively checking for potential vulnerabilities in Ivanti firmware updates, as the group Mandiant calls UNC5221 has apparently worked out a way to achieve Remote Code Execution with this vulnerability, and is using it to deploy malware on these systems. This is thought to be the same Chinese group that Microsoft appropriately calls Silk Typhoon.

Our friends at watchTowr have dug a bit more into this issue, and found the exact vulnerable code. It’s in HTTP header handling code, where a specific header is first limited to numerals and the period, and then copied into a fixed size buffer. Remember that observation that this sounds like an IP address? The header is X-Forwarded-For, and setting that to a long string of numbers on a vulnerable Ivanti box will indeed trigger a crash in the web binary. There’s no word yet on how exactly that was used to achieve RCE, but we’re very much hoping the rest of the story comes to light, because it’s an impressive feat.

Bits and Bytes

About 100,000 WordPress sites have a real problem. The Ottokit plugin has an authentication bypass issue, where a blank API key can be matched by setting an empty st_authorization header in an incoming request. The flaw was reported privately on April 3rd, and a fixed version was released the same day. But within hours exploitation attempts were seen in the wild.

Legacy Gigacenter devices expose a TR-069 service on port 6998. That service can be accessed with a simple telnet connection, and the commands entered here are not properly sanitized before being evaluated. Anything inside a $() substitution string is executed locally: $(ping -c5 your.ip.address) This makes for an exceedingly trivial remote code execution attack on these devices.

And finally, the Langflow AI workflow tool has a simple remote exploit vulnerability fixed in version 1.3.0. This vulnerability notably allows bypassing authentication through an API endpoint. While Langflow has Python execution by design, doing it while bypassing authentication is a definite problem. You should update to 1.3.0, and don’t expose Langflow to the Internet at all if you can help it.

From Blog – Hackaday via this RSS feed

It is hard to imagine that it has been more than four decades since two of the original designers of the Sinclair ZX Spectrum broke off to market the Jupiter Ace. [Nemanja Trifunovic] remembers the tiny computer in a recent post, and we always love to recall the old computers that used TVs for screens and audio tape recorders for mass storage.

One thing we always loved about the Jupiter Ace is that while most computers of the era had Basic as their native tongue, the Ace used Forth. As the post points out, while this may have given it great geek cred, it didn’t do much for sales, and the little machine was history within a year. However, the post also proposes that Forth wasn’t the real reason for the machine’s lack of commercial success.

Why did they pick Forth? Why not? It is efficient and interactive. The only real disadvantage was that Basic was more familiar to more people. Books and magazines of the day showed Basic, not Forth. But, according to the post, the real reason for its early demise was that it was already using outdated hardware from day one.

The Ace provided only 3K of RAM and did not offer color graphics. While this may sound laughable today, it wasn’t totally out of the question in 1978. Unfortunately, the Ace debuted in 1982. There were options that offered much more for just a little less. There is also the argument that as users became less technical, they just wanted to load pre-programmed tapes or cartridges and didn’t really care what language was running the computer.

Maybe, but we did and we can’t help but imagine a future where Forth was the language of choice for personal computers. Given how few of these were made, we see a lot of projects around them or, at least, replicas. Of course, these days that can be as simple as a single chip.

From Blog – Hackaday via this RSS feed

Would-be spooks and spies, take note: this one-transistor FM transmitter is a circuit you might want to keep in mind for your bugging needs. True, field agents aren’t likely to need to build their own equipment, but how cool a spy would you be if you could?

Luckily, you won’t need too many parts to recreate [Ciprian (YO6DXE)]’s project, most of which could be found in a decently stocked junk bin, or even harvested from e-waste. On the downside, the circuit is pretty fussy, with even minor component value changes causing a major change in center frequency. [Ciprian] had to do a lot of fiddling to get the frequency in the FM band, particularly with the inductor in the LC tank circuit. Even dropping battery voltage shifted the frequency significantly, which required a zener diode to address.

[Ciprian] ran a few tests and managed to get solid copy out to 80 meters range, which is pretty impressive for such a limited circuit. The harmonics, which extend up into the ham bands and possibly beyond, are a bit of a problem; while those could be addressed with a low-pass filter, in practical terms, the power of this little fellow is probably low enough to keep you from getting into serious trouble. Still, it’s best not to push your luck.

While you’re trying your hand at one-transistor circuits, you might want to try [Ciprian]’s one-transistor CW transceiver next.

From Blog – Hackaday via this RSS feed

If you paid attention to advertising in 1980s Britain, you were never far from Economy 7. It was the magic way to heat your house for less, using storage heaters which would run at night using cheap electricity, and deliver warmth day-long. Behind it all was an unseen force, a nationwide radio switching signal transmitted using the BBC’s 198 kHz Long Wave service. Now in 2025 the BBC Radio 4 Long Wave service it relies on is to be turned off, rendering thousands of off-peak electricity meters still installed, useless. [Ringway Manchester] is here to tell the tale.

The system was rolled out in the early 1980s, and comprised of a receiver box which sat alongside your regular electricity meter and switched in or out your off-peak circuit. The control signal was phase-modulated onto the carrier, and could convey a series of different energy use programs. 198 kHz had the useful property due to its low frequency of universal coverage, making it the ideal choice. As we’ve reported in the past the main transmitter at Droitwich is to be retired due to unavailability of the high-power vacuum tubes it relies on, so now time’s up for Economy 7 too. The electricity companies are slow on the uptake despite years of warning, so there’s an unseemly rush to replace those old meters with new smart meters. The video is below the break.

The earliest of broadcast bands may be on the way out, but it’s not entirely over. There might even be a new station on the dial for some people.

From Blog – Hackaday via this RSS feed

Once the domain of esoteric scientific and business computing, floating point calculations are now practically everywhere. From video games to large language models and kin, it would seem that a processor without floating point capabilities is pretty much a brick at this point. Yet the truth is that integer-based approximations can be good enough to hit the required accuracy. For example, approximating floating point multiplication with integer addition, as [Malte Skarupke] recently had a poke at based on an integer addition-only LLM approach suggested by [Hongyin Luo] and [Wei Sun].

As for the way this works, it does pretty much what it says on the tin: adding the two floating point inputs as integer values, followed by adjusting the exponent. This adjustment factor is what gets you close to the answer, but as the article and comments to it illustrate, there are plenty of issues and edge cases you have to concern yourself with. These include under- and overflow, but also specific floating point inputs.

Unlike in scientific calculations where even minor inaccuracies tend to propagate and cause much larger errors down the line, graphics and LLMs do not care that much about float point precision, so the ~7.5% accuracy of the integer approach is good enough. The question is whether it’s truly more efficient as the paper suggests, rather than a fallback as seen with e.g. integer-only audio decoders for platforms without an FPU.

Since one of the nice things about FP-focused vector processors like GPUs and derivatives (tensor, ‘neural’, etc.) is that they can churn through a lot of data quite efficiently, the benefits of shifting this to the ALU of a CPU and expecting (energy) improvements seem quite optimistic.

From Blog – Hackaday via this RSS feed

While some companies like Apple have gone all-in on the ARM architecture, others are more hesitant to dive into the deep end. For example, Microsoft remains heavily invested in the x86 architecture and although it does have some ARM offerings, a lot of them feel a bit half-baked. So you might question why someone like [Gustave] has spent so much time getting Windows to run on unusual ARM platforms. But we don’t need much of a reason to do something off-the-wall like that around these parts, so take a look at his efforts to get Windows for ARM running on a smartwatch.

The smartwatch in question here is a Pixel Watch 3, which normally runs a closed-source Android implementation called Wear OS. The bootloader can be unlocked, so [Gustave] took that approach to implement a few clever workarounds to get Windows to boot including adding UEFI to the watch. During the process Google updated these devices to Android 15, though, which broke some of these workarounds. The solution at that point was to fake a kernel header and re-implement UEFI and then load Windows (technically Windows PE) onto the watch.

Although this project was released on April 1, and is by [Gustave]’s own admission fairly ridiculous and not something he actually recommends anyone do, he does claim that it’s real and provides everything needed for others to run Windows on their smartwatches if they want to. Perhaps one of our readers will be brave enough to reproduce the results and post about it in the comments. In the meantime, there are a few more open options for smartwatches available if you’re looking for something to tinker with instead.

Thanks to [Ruhan] for the tip!

From Blog – Hackaday via this RSS feed