There was a time when Linux was much simpler. You’d load a driver, it would find your device at boot up, or it wouldn’t. That was it. Now, though, people plug and unplug USB devices all the time and expect the system to react appropriately. [Arcanenibble] explains all “the gory details” about what really happens when you plug or unplug a device.

You might think, “Oh, libusb handles that.” But, of course, it doesn’t do the actual work. In fact, there are two possible backends: netlink or udev. However, the libusb developers strongly recommend udev. Turns out, udev also depends on netlink underneath, so if you use udev, you are sort of using netlink anyway.

If netlink sounds familiar, it is a generic BSD-socket-like API the kernel can use to send notifications to userspace. The post shows example code for listening to kernel event messages via netlink, just like udev does.

When udev sees a device add message from netlink, it resends a related udev message using… netlink! Turns out, netlink can send messages between two userspace programs, not just between the kernel and userspace. That means that the code to read udev events isn’t much different from the netlink example.

The next hoop is the udev event format. It uses a version number, but it seems stable at version 0xfeedcafe. Part of the structure contains a hash code that allows a bloom filter to quickly weed out uninteresting events, at least most of the time.

The post documents much of the obscure inner workings of USB hotplug events. However, there are some security nuances that aren’t clear. If you can explain them, we bet [Arcanenibble] would like to hear from you.

If you like digging into the Linux kernel and its friends, you might want to try creating kernel modules. If you get overwhelmed trying to read the kernel source, maybe go back a few versions.

hackaday.com/2026/03/06/linux-…

The fourth quarter of 2025 went down as one of the most intense periods on record for high-profile, critical vulnerability disclosures, hitting popular libraries and mainstream applications. Several of these vulnerabilities were picked up by attackers and exploited in the wild almost immediately.

In this report, we dive into the statistics on published vulnerabilities and exploits, as well as the known vulnerabilities leveraged with popular C2 frameworks throughout Q4 2025.

Statistics on registered vulnerabilities

This section contains statistics on registered vulnerabilities. The data is taken from cve.org.

Let’s take a look at the number of registered CVEs for each month over the last five years, up to and including the end of 2025. As predicted in our last report, Q4 saw a higher number of registered vulnerabilities than the same period in 2024, and the year-end totals also cleared the bar set the previous year.

Total published vulnerabilities by month from 2021 through 2025 (download)

Now, let’s look at the number of new critical vulnerabilities (CVSS > 8.9) for that same period.

Total number of published critical vulnerabilities by month from 2021 to 2025< (download)

The graph shows that the volume of critical vulnerabilities remains quite substantial; however, in the second half of the year, we saw those numbers dip back down to levels seen in 2023. This was due to vulnerability churn: a handful of published security issues were revoked. The widespread adoption of secure development practices and the move toward safer languages also pushed those numbers down, though even that couldn’t stop the overall flood of vulnerabilities.

Exploitation statistics

This section contains statistics on the use of exploits in Q4 2025. The data is based on open sources and our telemetry.

Windows and Linux vulnerability exploitation

In Q4 2025, the most prevalent exploits targeted the exact same vulnerabilities that dominated the threat landscape throughout the rest of the year. These were exploits targeting Microsoft Office products with unpatched security flaws.

Kaspersky solutions detected the most exploits on the Windows platform for the following vulnerabilities:

• CVE-2018-0802: a remote code execution vulnerability in Equation Editor.
• CVE-2017-11882: another remote code execution vulnerability, also affecting Equation Editor.
• CVE-2017-0199: a vulnerability in Microsoft Office and WordPad that allows an attacker to assume control of the system.

The list has remained unchanged for years.

We also see that attackers continue to adapt exploits for directory traversal vulnerabilities (CWE-35) when unpacking archives in WinRAR. They are being heavily leveraged to gain initial access via malicious archives on the Windows operating system:

• CVE-2023-38831: a vulnerability stemming from the improper handling of objects within an archive.
• CVE-2025-6218 (formerly ZDI-CAN-27198): a vulnerability that enables an attacker to specify a relative path and extract files into an arbitrary directory. This can lead to arbitrary code execution. We covered this vulnerability in detail in our Q2 2025 report.
• CVE-2025-8088: a vulnerability we analyzed in our previous report, analogous to CVE-2025-6218. The attackers used NTFS streams to circumvent controls on the directory into which files were being unpacked.

As in the previous quarter, we see a rise in the use of archiver exploits, with fresh vulnerabilities increasingly appearing in attacks.

Below are the exploit detection trends for Windows users over the last two years.

Dynamics of the number of Windows users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

The vulnerabilities listed here can be used to gain initial access to a vulnerable system. This highlights the critical importance of timely security updates for all affected software.

On Linux-based devices, the most frequently detected exploits targeted the following vulnerabilities:

• CVE-2022-0847, also known as Dirty Pipe: a vulnerability that allows privilege escalation and enables attackers to take control of running applications.
• CVE-2019-13272: a vulnerability caused by improper handling of privilege inheritance, which can be exploited to achieve privilege escalation.
• CVE-2021-22555: a heap overflow vulnerability in the Netfilter kernel subsystem.
• CVE-2023-32233: another vulnerability in the Netfilter subsystem that creates a use-after-free condition, allowing for privilege escalation due to the improper handling of network requests.

Dynamics of the number of Linux users encountering exploits, Q1 2024 – Q4 2025. The number of users who encountered exploits in Q1 2024 is taken as 100% (download)

We are seeing a massive surge in Linux-based exploit attempts: in Q4, the number of affected users doubled compared to Q3. Our statistics show that the final quarter of the year accounted for more than half of all Linux exploit attacks recorded for the entire year. This surge is primarily driven by the rapidly growing number of Linux-based consumer devices. This trend naturally attracts the attention of threat actors, making the installation of security patches critically important.

Most common published exploits

The distribution of published exploits by software type in Q4 2025 largely mirrors the patterns observed in the previous quarter. The majority of exploits we investigate through our monitoring of public research, news, and PoCs continue to target vulnerabilities within operating systems.

Distribution of published exploits by platform, Q1 2025 (download)

Distribution of published exploits by platform, Q2 2025 (download)

Distribution of published exploits by platform, Q3 2025 (download)

Distribution of published exploits by platform, Q4 2025 (download)

In Q4 2025, no public exploits for Microsoft Office products emerged; the bulk of the vulnerabilities were issues discovered in system components. When calculating our statistics, we placed these in the OS category.

Vulnerability exploitation in APT attacks

We analyzed which vulnerabilities were utilized in APT attacks during Q4 2025. The following rankings draw on our telemetry, research, and open-source data.

TOP 10 vulnerabilities exploited in APT attacks, Q4 2025 (download)

In Q4 2025, APT attacks most frequently exploited fresh vulnerabilities published within the last six months. We believe that these CVEs will remain favorites among attackers for a long time, as fixing them may require significant structural changes to the vulnerable applications or the user’s system. Often, replacing or updating the affected components requires a significant amount of resources. Consequently, the probability of an attack through such vulnerabilities may persist. Some of these new vulnerabilities are likely to become frequent tools for lateral movement within user infrastructure, as the corresponding security flaws have been discovered in network services that are accessible without authentication. This heavy exploitation of very recently registered vulnerabilities highlights the ability of threat actors to rapidly implement new techniques and adapt old ones for their attacks. Therefore, we strongly recommend applying the security patches provided by vendors.

C2 frameworks

In this section, we will look at the most popular C2 frameworks used by threat actors and analyze the vulnerabilities whose exploits interacted with C2 agents in APT attacks.

The chart below shows the frequency of known C2 framework usage in attacks against users during Q4 2025, according to open sources.

TOP 10 C2 frameworks used by APTs to compromise user systems in Q4 2025 (download)

Despite the significant footprints it can leave when used in its default configuration, Sliver continues to hold the top spot among the most common C2 frameworks in our Q4 2025 analysis. Mythic and Havoc were second and third, respectively. After reviewing open sources and analyzing malicious C2 agent samples that contained exploits, we found that the following vulnerabilities were used in APT attacks involving the C2 frameworks mentioned above:

• CVE-2025-55182: a React2Shell vulnerability in React Server Components that allows an unauthenticated user to send commands directly to the server and execute them from RAM.
• CVE-2023-36884: a vulnerability in the Windows Search component that allows the execution of commands on a system, bypassing security mechanisms built into Microsoft Office applications.
• CVE-2025-53770: a critical insecure deserialization vulnerability in Microsoft SharePoint that allows an unauthenticated user to execute commands on the server.
• CVE-2020-1472, also known as Zerologon, allows for compromising a vulnerable domain controller and executing commands as a privileged user.
• CVE-2021-34527, also known as PrintNightmare, exploits flaws in the Windows print spooler subsystem, enabling remote access to a vulnerable OS and high-privilege command execution.
• CVE-2025-8088 and CVE-2025-6218 are similar directory-traversal vulnerabilities that allow extracting files from an archive to a predefined path without the archiving utility notifying the user.

The set of vulnerabilities described above suggests that attackers have been using them for initial access and early-stage maneuvers in vulnerable systems to create a springboard for deploying a C2 agent. The list of vulnerabilities includes both zero-days and well-known, established security issues.

Notable vulnerabilities

This section highlights the most noteworthy vulnerabilities that were publicly disclosed in Q4 2025 and have a publicly available description.

React2Shell (CVE-2025-55182): a vulnerability in React Server Components

We typically describe vulnerabilities affecting a specific application. CVE-2025-55182 stood out as an exception, as it was discovered in React, a library primarily used for building web applications. This means that exploiting the vulnerability could potentially disrupt a vast number of applications that rely on the library. The vulnerability itself lies in the interaction mechanism between the client and server components, which is built on sending serialized objects. If an attacker sends serialized data containing malicious functionality, they can execute JavaScript commands directly on the server, bypassing all client-side request validation. Technical details about this vulnerability and an example of how Kaspersky solutions detect it can be found in our article.

CVE-2025-54100: command injection during the execution of curl (Invoke-WebRequest)

This vulnerability represents a data-handling flaw that occurs when retrieving information from a remote server: when executing the curl or Invoke-WebRequest command, Windows launches Internet Explorer in the background. This can lead to a cross-site scripting (XSS) attack.

CVE-2025-11001: a vulnerability in 7-Zip

This vulnerability reinforces the trend of exploiting security flaws found in file archivers. The core of CVE-2025-11001 lies in the incorrect handling of symbolic links. An attacker can craft an archive so that when it is extracted into an arbitrary directory, its contents end up in the location pointed to by a symbolic link. The likelihood of exploiting this vulnerability is significantly reduced because utilizing such functionality requires the user opening the archive to possess system administrator privileges.

This vulnerability was associated with a wave of misleading news reports claiming it was being used in real-world attacks against end users. This misconception stemmed from an error in the security bulletin.

RediShell (CVE-2025-49844): a vulnerability in Redis

The year 2025 saw a surge in high-profile vulnerabilities, several of which were significant enough to earn a unique nickname. This was the case with CVE-2025-49844, also known as RediShell, which was unveiled during a hacking competition. This vulnerability is a use-after-free issue related to how the load command functions within Lua interpreter scripts. To execute the attack, an attacker needs to prepare a malicious script and load it into the interpreter.

As with any named vulnerability, RediShell was immediately weaponized by threat actors and spammers, albeit in a somewhat unconventional manner. Because technical details were initially scarce following its disclosure, the internet was flooded with fake PoC exploits and scanners claiming to test for the vulnerability. In the best-case scenario, these tools were non-functional; in the worst, they infected the system. Notably, these fraudulent projects were frequently generated using LLMs. They followed a standardized template and often cross-referenced source code from other identical fake repositories.

CVE-2025-24990: a vulnerability in the ltmdm64.sys driver

Driver vulnerabilities are often discovered in legitimate third-party applications that have been part of the official OS distribution for a long time. Thus, CVE-2025-24990 has existed within code shipped by Microsoft throughout nearly the entire history of Windows. The vulnerable driver has been shipped since at least Windows 7 as a third-party driver for Agere Modem. According to Microsoft, this driver is no longer supported and, following the discovery of the flaw, was removed from the OS distribution entirely.

The vulnerability itself is straightforward: insecure handling of IOCTL codes leading to a null pointer dereference. Successful exploitation can lead to arbitrary command execution or a system crash resulting in a blue screen of death (BSOD) on modern systems.

CVE-2025-59287: a vulnerability in Windows Server Update Services (WSUS)

CVE-2025-59287 represents a textbook case of insecure deserialization. Exploitation is possible without any form of authentication; due to its ease of use, this vulnerability rapidly gained traction among threat actors. Technical details and detection methodologies for our product suite have been covered in our previous advisories.

Conclusion and advice

In Q4 2025, the rate of vulnerability registration has shown no signs of slowing down. Consequently, consistent monitoring and the timely application of security patches have become more critical than ever. To ensure resilient defense, it is vital to regularly assess and remediate known vulnerabilities while implementing technology designed to mitigate the impact of potential exploits.

Continuous monitoring of infrastructure, including the network perimeter, allows for the timely identification of threats and prevents them from escalating. Effective security also demands tracking the current threat landscape and applying preventative measures to minimize risks associated with system flaws. Kaspersky Next serves as a reliable partner in this process, providing real-time identification and detailed mapping of vulnerabilities within the environment.

Securing the workplace remains a top priority. Protecting corporate devices requires the adoption of solutions capable of blocking malware and preventing it from spreading. Beyond basic measures, organizations should implement adaptive systems that allow for the rapid deployment of security updates and the automation of patch management workflows.

securelist.com/vulnerabilities…

Light aircraft often use a heading indicator as a way to know where they’re going. Retired instrumentation engineer [Don Welch] recreated a heading indicator of his own, using cheap off-the-shelf hardware to get the job done.

The heart of the build is a Teensy 4.0 microcontroller. It’s paired with a BNO085 inertial measurement unit (IMU), which combines a 3-axis gyro, 3-axis accelerometer, and 3-axis magnetometer into a single package. [Don] wanted to build a heading indicator that was immune to magnetic disturbances, so ignored the magnetometer readings entirely, using the rest of the IMU data instead.

Upon startup, the Teensy 4.0 initializes a small round TFT display, and draws the usual compass rose with North at the top of the display. Any motion after this will update the heading display accordingly, with [Don] noting the IMU has a fast update rate of 200 Hz for excellent motion tracking. The device does not self-calibrate to magnetic North; instead, an encoder can be used to calibrate the device to match a magnetic compass you have on hand. Or, you can just ensure it’s already facing North when you turn it on.

Thanks to the power of the Teensy 4.0 and the rapid updates of the BNO085, the display updates are nicely smooth and responsive. However, [Don] notes that it’s probably not quite an aircraft-spec build. We’ve featured some interesting investigations of just how much you can expect out of MEMS-based sensors like these before, too.

youtube.com/embed/UoS7PKGJVlE?…

hackaday.com/2026/03/06/buildi…

Electric vehicles are everywhere these days, and with them comes along a whole slew of charging infrastructure. The fastest of these are high-power machines that can deliver enough energy to charge a car in well under an hour, but there are plenty of slower chargers available that take much longer. These don’t tend to require any specialized equipment which makes them easier to install in homes and other places where there isn’t as much power available. In fact, these chargers generally amount to fancy extension cords, and [Matt Gray] realized he could use these to do other things like charge his electric bicycle.

To begin the build, [Matt] started with an electric car charging socket and designed a housing for it with CAD software. The housing also holds the actual battery charger for his VanMoof bicycle, connected internally directly to the car charging socket. These lower powered chargers don’t require any communication from the vehicle either, which simplifies the process considerably. They do still need to be turned on via a smartphone app so the energy can be metered and billed, but with all that out of the way [Matt] was able to take his test rig out to a lamppost charger and boil a kettle of water.

After the kettle experiment, he worked on miniaturizing his project so it fits more conveniently inside the 3D-printed enclosure on the rear rack of his bicycle. The only real inconvenience of this project, though, is that since these chargers are meant for passenger vehicles they’re a bit bulky for smaller vehicles like e-bikes. But this will greatly expand [Matt]’s ability to use his ebike for longer trips, and car charging infrastructure like this has started being used in all kinds of other novel ways as well.

youtube.com/embed/i6IyukCIia8?…

hackaday.com/2026/03/05/ebike-…

Last year California’s Digital Age Assurance Act (AB 1043) was signed into law, requiring among other things that operating system providers implement an API for age verification purposes. With the implementation date of January 1, 2027 slowly encroaching this now has people understandably agitated. So what are the requirements, and what will its impact be, as it affects not only OS developers but also application stores and developers?

The required features for OS developers include an interface at account setup during which the person indicates which of the four age brackets they fit into. This age category then has to be used by application developers and application stores to filter access to the software. Penalties for non-compliance go up to $2,500 per affected child if the cause is neglect and up to $7,500 if the violation was intentional.

As noted in the Tom’s Hardware article, CA governor Newsom issued a statement when signing the unanimously passed bill, saying that he hopes the bill gets amended due to how problematic it would be to implement and unintended effects. Of course, the bigger question is whether this change requires more than adding a few input fields and checkboxes to an OS’ account setup and an API call or two.

When we look at the full text of this very short bill, the major questions are whether this bill has any teeth at all. From reading the bill’s text, we can see that the person creating the account is merely asked to provide their birth date, age or both. This makes it at first glance as effective as those ‘pick your age’ selection boxes before entering an age-gated part of a website. What would make this new ‘age-verification feature’ any more reliable than that?

Although the OS developer is required to provide this input option and an API feature of undefined nature that provides the age bracket in some format via some method, the onus is seemingly never put on the user who creates or uses the OS account. Enforcement as defined in section 1798.503 is defined as a vague ‘[a] person that violates this title’, who shall have a civil action lawsuit filed against them. What happens if a 9-year old child indicates that they’re actually 35, for example? Or when a user account is shared on a family computer?

All taken together, this bill looks from all angles to add a lot of nuisance and potential for catching civil lawsuit flak for in particular FOSS developers, all in order to circuitously reimplement the much beloved age dropdown selection widget that’s been around since at least the 1990s.

They could give this bill real teeth by requiring that photo ID is required for registering an (online-only) OS account, much like with the recent social media restrictions and Discord age-verification kerfuffle, but that’d run right over the ‘privacy-preserving’ elements in this same bill.

hackaday.com/2026/03/05/califo…

In theory HDMI’s CEC feature is great, as it gives HDMI devices the ability to do useful things such as turning on multiple HDMI devices with a single remote control. Of course, such a feature will inevitably feature bugs. A case in point is the Nvidia Shield which has often been reported to turn on other HDMI devices that should stay off. After getting ticked off by such issues one time too many, [Matt] decided to implement a network firewall project to prevent his receiver from getting messed with by the Shield.

The project is a Python-based network service that listens for the responsible rogue HDMI-CEC Zone 2 requests and talks with a Denon/Marantz receiver to prevent it from turning on unnecessarily. Of course, when you want these Zone 2 requests to do their thing you need to disable the script.

That said, HDMI-CEC is such a PITA that people keep running into issues like these over and over again, to the point where people are simply disabling the feature altogether. That said, Nvidia did recently release a Shield update that’s claimed to fix CEC issues, so maybe this is one CEC bug down already.

hackaday.com/2026/03/05/preven…

Most end tables that you might find in a home are relatively static objects. However, [Peter Waldraff] of Tiny World Studios likes to build furniture that’s a little more interesting. Thus came about this beautiful piece with a real working railway built right in.

The end table was built from scratch, with [Peter] going through all the woodworking steps required to assemble the piece. The three-legged wooden table is topped with a tiny N-scale model railway layout, and you get to see it put together including the rocks, the grass, and a beautiful epoxy river complete with a bridge. The railway runs a Kato Pocket Line trolley, but the really neat thing is how it’s powered.

[Peter] shows us how a small gearmotor generator was paired with a bridge rectifier and a buck converter to fill up a super capacitor that runs the train and lights up the tree on the table. Just 25 seconds of cranking will run the train anywhere from 4 to 10 minutes depending on if the tree is lit as well. To top it all off, there’s even a perfect coaster spot for [Peter]’s beverage of choice.

It’s a beautiful kinetic sculpture and a really fun way to build a small model railway that fits perfectly in the home. We’ve featured some other great model railway builds before, too.

youtube.com/embed/9cLuf6BuB3A?…

hackaday.com/2026/03/05/railwa…

It’s one thing to create your own relay-based computer; that’s already impressive enough, but what really makes [DiPDoT]’s design special– at least after this latest video— is swapping the SRAM he had been using for historically-plausible capacitor-based memory.

A relay-based computer is really a 1940s type of design. There are various memory types that would have been available in those days, but suitable CRTs for Williams Tues are hard to come by these days, mercury delay lines have the obvious toxicity issue, and core rope memory requires granny-level threading skills. That leaves mechanical or electromechanical memory like [Konrad Zeus] used in the 30s, or capacitors. he chose to make his memory with capacitors.

It’s pretty obvious when you think about it that you can use a capacitor as memory: charged/discharged lets each capacitor store one bit. Charge is 1, discharged is 0. Of course to read the capacitor it must be discharged (if charged) but most early memory has that same read-means-erase pattern. More annoying is that you can’t overwrite a 1 with a 0– a separate ‘clear’ circuit is needed to empty the capacitor. Since his relay computer was using SRAM, it wasn’t set up to do this clear operation.

He demonstrates an auto-clearing memory circuit on breadboard, using 3 relays and a capacitor, so the existing relay computer architecture doesn’t need to change. Addressing is a bit of a cheat, in terms of 1940s tech, as he’s using modern diodes– though of course, tube diodes or point-contact diodes could conceivably pressed into service if one was playing purist. He’s also using LEDs to avoid the voltage draw and power requirements of incandescent indicator lamps. Call it a hack.

He demonstrates his circuit on breadboard– first with a 4-bit word, and then scaled up to 16-bit, before going all way to a massive 8-bytes hooked into the backplane of his Altair-esque relay computer. If you watch nothing else, jump fifteen minutes in to have the rare pleasure of watching a program being input via front panel with a complete explanation. If you have a few extra seconds, stay for the satisfyingly clicky run of the loop. The bonus 8-byte program [DiPDoT] runs at the end of the video is pure AMSR, too.

Yeah, it’s not going to solve the rampocalypse, any more than the initial build of this computer helped with GPU prices. That’s not the point. The point is clack clack clack clack clack, and if that doesn’t appeal, we don’t know what to tell you.

youtube.com/embed/EtDyzEDMOoo?…

hackaday.com/2026/03/05/capaci…

Curious about split keyboards, but overwhelmed by the myriad options for every little thing? You should start with [thehaikuza]’s excellent Beginner’s Guide to Split Keyboards.

Image by [thehaikuza] via redditYour education begins with the why, so you can skip that if you must, but the visuals are a nice refresher on that front.

He then gets into the types of keyboards — you got your standard row-staggered rectangles that we all grew up on, column-staggered, and straight-up ortholinear, which no longer enjoy the popularity they once did.

At this point, the guide becomes a bit of a Choose Your Own Adventure story. If you want a split but don’t want to learn to change much if at all about your typing style, keep reading, because there are definitely options.

But if you’re ready to commit to typing correctly for the sake of ergonomics, you can skip the Alice and other baby ergo choices and get your membership to the light side. First are features — you must decide what you need to get various jobs done. Then you learn a bit about key map customization, including using a non-QWERTY layout. Finally, there’s the question of buying versus DIYing. All the choices are yours, so go for it!

Via reddit

Is That a Bat In Your Pocket?

Need something ultra-portable for those impromptu sessions at the coffee shop (when you can actually find a table)? You can’t get much smaller than the 28-key Koumori by [fata1err0r81], which means “bat” in Japanese. Here’s the repo.

Image by [fata1err0r81] via redditThis unibody beauty runs on an RP2040 Zero using QMK firmware. That 40 mm Cirque track pad has a glass overlay, which is a really nice touch. It’s actually a screen protector for a smart watch, and the purple bit is some craft vinyl cut to size.

Protecting that glass overlay is a case with a handle and a magnetic lid. Both the PCB and the case were designed in Ergogen, which as you know, I really like to see people using.

As you might have guessed, those are Kailh V1 choc switches with matching key caps. If you want a bat for your pocket, the build guide is simple, and there aren’t even any microscopic parts involved.

The Centerfold: [arax20]’s Been Workin’ On the Railroader

Image by [arax20] via redditOkay, before you do anything, go check out the image gallery to see this baby glowing and being worn like a katana or something. Yeah.

So [arax20] built this as a gift for an ex. She likes the ergonomics of splits, but didn’t want cables between the halves and feels the space between is otherwise wasted. Really? There’s so much you can put there, from cats to mice to coffee mugs.

Do you rock a sweet set of peripherals on a screamin’ desk pad? Send me a picture along with your handle and all the gory details, and you could be featured here!

Historical Clackers: the Mysterious Rico

Frustratingly little is known about the Rico, a 1932 index machine out of Nuremburg, Germany. But the Antikey Chop has over a dozen books on typewriters, and only two have any mention of the Rico: Adler’s Antique Typewriters, From Creed to QWERTY, and Dingwerth’s Kleines Lexikon Historischer Schreibmaschinen.
Image via The Antikey Chop
Adler calls it a “pleasant toy typewriter with indicator selecting letters from a rectangular index”, saying nothing more descriptive. Dingwerth’s volume both dates the Rico and lists the maker as Richard Koch & Co. of Nuremburg.

The Rico was ambitiously declared the No. A1 model, though there is no evidence of any other model in existence. It was made mostly of stamped tin, though the type element was made of brass. The type element looked like a tube cut in half lengthwise, and worked in a similar fashion to the Chicago typewriter with its type sleeve.

There are some interesting things about the Rico nonetheless. The platen could not accommodate paper wider than 4″, for one thing. There is also no inking system to speak of. Weirder still, this oversight isn’t mentioned in the original instructions. Most people just taped a couple inches of typewriter ribbon between the element and the platen and called it good .

To use the thing, you would move the center lever to the character you wanted. The lever has a pin in the bottom, and each character has a dimple in it for the pin to sit. The lever on the left side was used to pivot the carriage toward the type element in order to print. In total, the Rico typed 74 characters plus Space.

Finally, Someone’s Made a Braille Keyboard, and It’s Inexpensive

Once upon a time, New Jersey high schooler Umang Sharma saw an ad for a Braille keyboard. The price? A cool seven grand. For a keyboard. No problem, he thought. I can build my own.
Image via NJ.com
The astute among you will notice that there’s a Logitech keyboard in the picture, with what look like key cap hats. That is exactly what’s happening here. Sharma starts with a standard keyboard base, one that is usually either donated or was previously discarded.

He then focuses on the most important accessibility layer, which is tactile Braille key caps that are both readable and durable. In 2022, Sharma launched the non-profit Jdable to bring affordable, accessible design to people with disabilities.

He designed the key caps himself, and uses a combination of 3D printing and other materials to create them in bulk. They’re printed using a combination of PETG for toughness, TPU for grippiness, and resin for definition. The key caps are attached to the standard set with a strong adhesive.

Sharma has a team of student volunteers that help him build the keyboards and distribute them, and they have reached nearly 1,000 blind or visually-impaired students in the U.S. and abroad.

Got a hot tip that has like, anything to do with keyboards? Help me out by sending in a link or two. Don’t want all the Hackaday scribes to see it? Feel free to email me directly.

hackaday.com/2026/03/05/keebin…

Vibe coding is all the rage at the moment if you follow certain parts of the Internet. It’s very easy to dunk upon it, whether it’s to mock the sea of people who’ve drunk the Kool-Aid and want the magic machine to make them a million dollar app with no work, or the vibe coded web apps with security holes you could drive a bus through.

But AI-assisted coding is now a thing that will stick around whether you like it or not, and there are many who want to dip a toe in the water to see what the fuss is about. For those who don’t quite trust the magic machines in their inner sanctum, [jscottmiller] is here with Clix, a bootable live Linux environment which puts Claude Code safely in a sandbox away from your family silver.

Physically it’s a NixOS live USB image with the Sway tiling Wayland compositor, and as he puts it: “Claude Code ready to go”. It has a shared partition for swapping files with Windows or macOS machines, and it’s persistent. The AI side of it has permissive settings, which means the mechanical overlord can reach parts of the OS you wouldn’t normally let it anywhere near; the point of having it in a live environment in the first place.

We can see the attraction of using an environment such as this one for experimenting without commitment, but we’d be interested to hear your views in the comments. It’s about a year since we asked you all about vibe coding, has the art moved forward in that time?

hackaday.com/2026/03/05/a-live…

In the 1970s, the USSR had an undersea cable connecting a major naval base at Petropavlovsk to the Pacific Fleet headquarters at Vladivostok. The cable traversed the Sea of Okhotsk, which, at the time, the USSR claimed. It was off limits to foreign vessels, heavily patrolled, and laced with detection devices. How much more secure could it be? Against the US Navy, apparently not very secure at all. For about a decade starting in 1972, the Navy delivered tapes of all the traffic on the cable to the NSA.

Top Secret

You need a few things to make this a success. First, you need a stealthy submarine. The Navy had the USS Halibut, which has a strange history. You also need some sort of undetectable listening device that can operate on the ocean floor. You also need a crew that is sworn to secrecy.

That last part was hard to manage. It takes a lot of people to mount a secret operation to the other side of the globe, so they came up with a cover story: officially, the Halibut was in Okhotsk to recover parts of a Soviet weapon for analysis. Only a few people knew the real mission. The whole operation was known as Operation Ivy Bells.

The Halibut

The Halibut is possibly the strangest submarine ever. It started life destined to be a diesel sub. However, before it launched in 1959, it had been converted to nuclear power. In fact, the sub was the first designed to launch guided missiles and was the first sub to successfully launch a guided missile, although it had to surface to launch.

Oddly enough, the sub carried nuclear cruise missiles and its specific target, should the world go to a nuclear war, was the Soviet naval base at Petropavolvsk.

By 1965, the sub had been replaced for missile duty by newer submarines. It was tapped to be converted for “special operations.” Under the guise of being a deep-sea recovery vehicle, the Halibut received skids to settle on the seabed, side thrusters, specialized anchors, and a host of electronic equipment, including “the Fish” a 12-foot-long array of cameras, sonar, and strobe lights weighing nearly two tons. The “rescue vehicle” on its stern didn’t actually detach. It was a compartment for deploying saturation divers.

An early mission was Operation Sand Dollar. Halibut found the wreck of the Soviet K-129, which the US would go on to recover in another top secret mission, looking for secrets and Soviet technology.

When it came time to deploy the listening device on an underwater cable, Halibut was perfect. It could park a safe distance away, deploy saturation divers, and recover them. If you want to see more about the Halibut, check out the [Defence Central] video below.

youtube.com/embed/mrgR8cMWKVo?…

The Listening Device

A later undersea wire tap device (Soviet photograph)
This wasn’t a hidden microphone in a briefcase. It was a 20-foot, six-ton pressure vessel parked on the ocean floor. Details are murky, but there was another part, probably smaller, that clamped around the cable. Working inductively, it didn’t pierce the cable for fear the Soviets would notice that. In addition, if they raised the cable for maintenance, the device was made to break away and sink to the bottom.

Needless to say, tapping a cable on the ocean floor isn’t easy. First, they had to locate the cable. Luckily, there were signs at either end telling fishing vessels to avoid the area. That helped, but they still had to search for the 5-inch wide cables. They found them at least 400 feet below the surface, some 120 miles offshore.

Saturation diving was a relatively new idea at the time, and the Navy’s SeaLab experiments had given them several years of experience with the technology. While commercial saturation dives started in 1965, it was still exotic technology in 1971. The first mission simply recorded a bit of data on the submarine and returned it. Once it was proven, the sub returned with the giant tap device and installed it.

It took four divers to position the big tap. Even then, you couldn’t just leave it there. The device used tapes and required service once a month. So Halibut or another sub had to visit each month to swap tapes out. We couldn’t find out what the power source for the bug was, so they probably had to change the batteries, too.

The Soviets didn’t consider the cable to be at risk for eavesdropping, so much of the traffic on the cable was in the clear. It was a gold mine of intelligence information, and many credit the information gained as crucial to closing the SALT II treaty talks.

Secondary Mission

Most of the crews participating in Operation Ivy Bells didn’t have clearance to know what was going on. Instead, they thought they were on a different secret mission to retrieve debris from Soviet anti-ship missiles.

To keep the story believable, the crew actually did recover a large number of parts from the subject Soviet missiles. Turns out, analysis of the debris did reveal some useful information, so two spy missions for the price of one.

Presumably, the assumption would be that if the Soviets heard a sub was scavenging missile parts, it might qualify as a secret, but it would hardly be a surprise. They couldn’t have imagined the real purpose of the submarine.

Future Taps

Later undersea taps were created that used radioisotope batteries and could store a year’s data between visits that tapped other Soviet phone lines. Submarines Parche, Richard B. Russel, and Seawolf saw duty with some of these other taps as well as taking over for Halibut when it retired four years after the start of Operation Ivy Bells.

The original Okhotsk tap would have operated for many more years if it were not for [Ronald Pelton]. A former NSA employee, he found himself bankrupt over $65,000 of debt. In 1980, he showed up at the Soviet embassy in Washington and offered to sell what he knew.

He knew a number of things, including what was going on with Operation Ivy Bells. That data netted him $5,000 and, overall, he got about $35,000 or so. Oh, he also got life in prison when, in 1985, a Soviet defector revealed he had been the initial contact for [Pelton].

The Soviets didn’t immediately act on [Pelton’s] intel, but by 1981, the Americans knew something was up. A small fleet of ships was parked right over the device. The USS Parche was sent to retrieve it, but they couldn’t find it. Today, it (or, perhaps, a replica) is in the Great Patriotic War Museum in Moscow.

A surprising amount of the Cold War was waged under the sea. Not to mention in the air.

hackaday.com/2026/03/05/spytec…

There’s just something delightful about scaled items. Big things shrunk down, like LEGO’s teeny tiny terminal brick? Delightful. Taking that terminal brick and scaling it back to a full-sized computer? Even better. That’s what designer [Paul Staal] has done with his M2x2 project.

In spite of the name, it actually has a Mac Mini M4 as its powerful beating heart. An M2 might have been more on-brand, but it’s probably a case of wanting the most horsepower possible in what [Paul] apparently uses as his main workstation these days. The build itself is simple, but has some great design details. As you probably expected, the case is 3D printed. You may not have expected that he can use the left stud as a volume control, thanks to an IKEA Symfonisk remote hidden beneath. The right stud comes off to allow access to a wireless charger.
The minifigs aren’t required to charge those airpods, but they’re never out of place.
The 7″ screen can display anything, but [Paul] mostly uses it either for a custom home assistant dashboard, or to display an equalizer, both loosely styled after ‘screen’ on the original brick. We have to admit, as cool as it looked with the minifigs back in the day, that sharp angle to the screen isn’t exactly ergonomic for humans.

Perhaps the best detail was putting LEGO-compatible studs on top of the 10:1 scaled up studs, so the brick that inspired the project can sit securely atop its scion. [Paul] has provided a detailed build guide and the STLs necessary to print off a brick, should anyone want to put one of these nostalgic machines on their own desk.

We’ve covered the LEGO computer brick before, but going the other way–putting a microcontroller and display in the brick it to run DOOM. We’ve also seen it scaled up before, but that project was a bit more modest in size and computing power.

hackaday.com/2026/03/05/lego-s…