We wrote up a video about speeding up Arduino code, specifically by avoiding DigitalWrite. Now, the fact that DigitalWrite is slow as dirt is long known. Indeed, a quick search pulls up a Hackaday article from 2010 demonstrating that it’s fifty times slower than toggling the pin directly using the native pin registers, but this is still one of those facts that gets periodically rediscovered from generation to generation. How can this be new again?

First off, sometimes you just don’t need the speed. When you’re just blinking LEDs on a human timescale, the general-purpose Arduino functions are good enough. I’ve written loads of useful firmware that fits this description. When the timing requirements aren’t tight, slow as dirt can be fast enough.

But eventually you’ll want to build a project where the old slow-speed pin toggling just won’t cut it. Maybe it’s a large LED matrix, or maybe it’s a motor-control application where the loop time really matters. Or maybe it’s driving something like audio or video that just needs more bits per second. One way out is clever coding, maybe falling back to assembly language primitives, but I would claim that the right way is almost always to use the hardware peripherals that the chipmakers gave you.

For instance, in the end of the video linked above, the hacker wants to drive a large shift register string that’s lighting up an LED matrix. That’s exactly what SPI is for, and coming to this realization makes the project work with timing to spare, and in just a few lines of code. That is the way.

Which brings me to the double-edged sword that the Arduino’s abstraction creates. By abstracting away the chips’ hardware peripherals, it makes code more portable and certainly more accessible to beginners, who don’t want to learn about SPI and I2C and I2S and DMA just yet. But by hiding the inner workings of the chips in “user friendly” libraries, it blinds new users to the useful applications of these same hardware peripherals that clever chip-design engineers have poured their sweat and brains into making do just exactly what we need.

This isn’t really meant to be a rant against Arduino, though. Everyone has to start somewhere, and the abstractions are great for getting your feet wet. And because everything’s open source anyway, nothing stops you from digging deeper into the datasheet. You just have to know that you need to. And that’s why we write up videos like this every five years or so, to show the next crop of new hackers that there’s a lot to gain underneath the abstractions.

Digital Rights Management (DRM) has been the bane of users since it was first introduced. Who remembers the battle it was getting Netflix running on Linux machines, or the literal legal fight over the DVD DRM decryption key? So the news from Signal, that DRM is finally being put to use to protect users is ironic.

The reason for this is Microsoft Recall — the AI powered feature that takes a snapshot of everything on the user’s desktop every few seconds. For whatever reason, you might want to exempt some windows from Recall’s memory window. It doesn’t speak well for Microsoft’s implementation that the easiest way for an application to opt out of the feature is to mark its window as containing DRM content. Signal, the private communications platform, is using this to hide from Recall and other screenshotting applications.

The Signal blogs warns that this may be just the start of agentic AI being rolled out with insufficient controls and permissions. The issue here isn’t the singularity or AI reaching sentience, it’s the same old security and privacy problems we’ve always had: Too much information being collected, data being shared without permission, and an untrusted actor having access to way more than it should.

Legacy Malware?

The last few stories we’ve covered about malicious code in open source repositories have featured how quickly the bad packages were caught. Then there’s this story about two-year-old malicious packages on NPM that are just now being found.

It may be that the reason these packages weren’t discovered until now, is that these packages aren’t looking to exfiltrate data, or steal bitcoin, or load other malware. Instead, these packages have a trigger date, and just sabotage the systems they’re installed on — sometimes in rather subtle ways. If a web application you were writing was experiencing intermittent failures, how long would it take you to suspect malware in one of your JavaScript libraries?

Where Are You Calling From?

Phone phreaking isn’t dead, it has just gone digital. One of the possibly apocryphal origins of phone phreaking was a toy bo’sun whistle in boxes of cereal, that just happened to play a 2600 Hz tone. More serious phreakers used more sophisticated, digital versions of the whistle, calling them blue boxes. In modern times, apparently, the equivalent of the blue box is a rooted Android phone. [Daniel Williams] has the story of playing with Voice over LTE (VoLTE) cell phone calls. A bug in the app he was using forced him to look at the raw network messages coming from O2 UK, his local carrier.

And those messages were weird. VoLTE is essentially using the Session Initiation Protocol (SIP) to handle cell phone calls as Voice over IP (VoIP) calls using the cellular data network. SIP is used in telephony all over the place, from desk phones to video conferencing solutions. SIP calls have headers that work to route the call, which can contain all sorts of metadata about the call. [Daniel] took a look at the SIP headers on a VoLTE call, and noticed some strange things. For one, the International Mobile Subscriber Identity (IMSI) and International Mobile Equipment Identity (IMEI) codes for both the sender and destination were available.

He also stumbled onto an interesting header, the Cellular-Network-Info header. This header encodes way too much data about the network the remote caller is connected to, including the exact tower being used. In an urban environment, that locates a cell phone to an area not much bigger than a city block. Together with leaking the IMSI and IMEI, this is a dangerous amount of information to leak to anyone on the network. [Daniel] attempted to report the issue to O2 in late March, and was met with complete silence. However, a mere two days after this write-up was published, on May 19th, O2 finally made contact, and confirmed that the issue had finally been resolved.

ARP Spoofing in Practice

TCP has an inherent security advantage, because it’s a stateful connection, it’s much harder to make a connection from a spoofed IP address. It’s harder, but it’s not impossible. One of the approaches that allows actual TCP connections from spoofed IPs is Address Resolution Protocol (ARP) poisoning. Ethernet switches don’t look at IP addresses, but instead route using MAC addresses. ARP is the protocol that distributes the MAC Address to IP mapping on the local network.

And like many protocols from early in the Internet’s history, ARP requests don’t include any cryptography and aren’t validated. Generally, whoever claims an IP address first wins, so the key is automating this process. And hence, enter NetImposter, a new tool specifically designed to automate this process, sending spoofed ARP packets, and establishing an “impossible” TCP connection.

Impossible RCE in SSH

Over two years ago, researchers at Qualsys discovered a pre-authentication double-free in OpenSSH server version 9.1. 9.2 was quickly released, and because none of the very major distributions had shipped 9.1 yet, what could have been a very nasty problem was patched pretty quietly. Because of the now-standard hardening features in modern Linux and BSD distributions, this vulnerability was thought to be impossible to actually leverage into Remote Code Execution (RCE).

If someone get a working OpenSSH exploit from this bug, I'm switching my main desktop to Windows 98 (this bug was discovered by a Windows 98 user who noticed sshd was crashing when trying to login to a Linux server!)

— Tavis Ormandy (@taviso) February 14, 2023

The bug was famously discovered by attempting to SSH into a modern Linux machine from a Windows 98 machine, and Tavis Ormandy claimed he would switch to Windows 98 on his main machine if someone did actually manage to exploit it for RCE. [Perri Adams] thought this was a hilarious challenge, and started working an exploit. Now we have good and bad news about this effort. [Perri] is pretty sure it is actually possible, to groom the heap and with enough attempts, overwrite an interesting pointer, and leak enough information in the process to overcome address randomization, and get RCE. The bad news is that the reward of dooming [Tavis] to a Windows 98 machine for a while wasn’t quite enough to be worth the pain of turning the work into a fully functional exploit.

But that’s where [Perri’s] OffensiveCon keynote took an AI turn. How well would any of the cutting-edge AIs do at finding, understanding, fixing, and exploiting this vulnerability? As you probably already guessed, the results were mixed. Two of the three AIs thought the function just didn’t have any memory management problems at all. Once informed of the problem, the models had more useful analysis of the code, but they still couldn’t produce any remotely useful code for exploitation. [Perri’s] takeaway is that AI systems are approaching the threshold of being useful for defensive programming work. Distilling what code is doing, helping in reverse engineering, and working as a smarter sort of spell checker are all wins for programmers and security researchers. But fortunately, we’re not anywhere close to a world where AI is developing and deploying exploitations.

Bits and Bytes

There are a pair of new versions of reverse engineering/forensic tools released very recently. Up first is Frida, a runtime debugger on steroids, that is celebrating its 17th major version release. One of the major features is migrating to pluggable runtime bridges, and moving away from strictly bundling them. We also have Volatility 3, a memory forensics framework. This isn’t the first Volatility 3 release, but it is the release where version three officially has parity with the version two of the framework.

The Foscam X5 security camera has a pair of buffer overflows, each of which can be leveraged to acieve arbitrary RCE. One of the proof-of-concepts has a very impressive use of a write-null-anywhere primitive to corrupt a return pointer, and jump into a ROP gadget. The concerning element of this disclosure is that the vendor has been completely unresponsive, and the vulnerabilities are still unaddressed.

And finally, one of the themes that I’ve repeatedly revisited is that airtight attribution is really difficult. [Andy Gill] walks us through just one of the many reasons that’s difficult. Git cryptographically signs the contents of a commit, but not the timestamps. This came up when looking through the timestamps from “Jia Tan” in the XZ compromise. Git timestamps can be trivially rewritten. Attestation is hard.

Saw what you want about the wisdom of keeping a 50-year-old space mission going, but the dozen or so people still tasked with keeping the Voyager mission running are some major studs. That’s our conclusion anyway, after reading about the latest heroics that revived a set of thrusters on Voyager 1 that had been offline for over twenty years. The engineering aspects of this feat are interesting enough, but we’re more interested in the social engineering aspects of this exploit, which The Register goes into a bit. First of all, even though both Voyagers are long past their best-by dates, they are our only interstellar assets, and likely will be for centuries to come, or perhaps forever. Sure, the rigors of space travel and the ravages of time have slowly chipped away at what these machines can so, but while they’re still operating, they’re irreplaceable assets.

That makes the fix to the thruster problem all the more ballsy, since the Voyager team couldn’t be 100% sure about the status of the primary thrusters, which were shut down back in 2004. They thought it might have been that the fuel line heaters were still good, but if they actually had gone bad, trying to switch the primary thrusters back on with frozen fuel lines could have resulted in an explosion when Voyager tried to fire them, likely ending in a loss of the spacecraft. So the decision to try this had to be a difficult one, to say the least. Add in an impending shutdown of the only DSN antenna capable of communicating with the spacecraft and a two-day communications round trip, and the pressure must have been unbearable. But they did it, and Voyager successfully navigated yet another crisis. But what we’re especially excited about is discovering a 2023 documentary about the current Voyager mission team called “It’s Quieter in the Twilight.” We know what we’ll be watching this weekend.

Speaking of space exploration, one thing you don’t want to do is send anything off into space bearing Earth microbes. That would be a Very Bad Thing, especially for missions designed to look for life anywhere else but here. But, it turns out that just building spacecraft in cleanrooms might not be enough, with the discovery of 26 novel species of bacteria growing in the cleanroom used to assemble a Mars lander. The mission in question was Phoenix, which landed on Mars in 2008 to learn more about the planet’s water. In 2007, while the lander was in the Payload Hazardous Servicing Facility at Kennedy Space Center, biosurveillance teams collected samples from the cleanroom floor. Apparently, it wasn’t very clean, with 215 bacterial strains isolated, 26 of which were novel. What’s more, genomic analysis of the new bugs suggests they have genes that make them especially tough, both in their resistance to decontamination efforts on Earth and in their ability to survive the rigors of life in space. We’re not really sure if these results say more about NASA’s cleanliness than they do about the selective pressure that an extreme environment like a cleanroom exerts on fast-growing organisms like bacteria. Either way, it doesn’t bode well for our planetary protection measures.

Closer to home but more terrifying is video from an earthquake in Myanmar that has to be seen to be believed. And even then, what’s happening in the video is hard to wrap your head around. It’s not your typical stuff-falling-off-the-shelf video; rather, the footage is from an outdoor security camera that shows the ground outside of a gate literally ripping apart during the 7.7 magnitude quake in March. The ground just past the fence settles a bit while moving away from the camera a little, but the real action is the linear motion — easily three meters in about two seconds. The motion leaves the gate and landscaping quivering but largely intact; sadly, the same can’t be said for a power pylon in the distance, which crumples as if it were made from toothpicks.

And finally, “Can it run DOOM?” has become a bit of a meme in our community, a benchmark against which hacking chops can be measured. If it has a microprocessor in it, chances are someone has tried to make it run the classic first-person shooter video game. We’ve covered dozens of these hacks before, everything from a diagnostic ultrasound machine to a custom keyboard keycap, while recent examples tend away from hardware ports to software platforms such as a PDF file, Microsoft Word, and even SQL. Honestly, we’ve lost count of the ways to DOOM, which is where Can It Run Doom? comes in handy. It lists all the unique platforms that hackers have tortured into playing the game, as well as links to source code and any relevant video proof of the exploit. Check it out the next time you get the urge to port DOOM to something cool; you wouldn’t want to go through all the work to find out it’s already been done, would you?

On the podcast, [Tom] and I were talking about the continuing saga of the libogc debacle. [Tom] has been interviewing some of the principals involved, so he’s got some first-hand perspective on it all – you should really go read his pieces. But the short version is that an old library that many Nintendo game emulators use appears to have cribbed code from both and open-source real-time operating system called RTEMS, and the Linux kernel itself.

You probably know Linux, but RTEMS is a high-reliability RTOS for aerospace. People in the field tell me that it’s well-known in those circles, but it doesn’t have a high profile in the hacker world. Still, satellites run RTEMS, so it’s probably also a good place to draw inspiration from, or simply use the library as-is. Since it’s BSD-licensed, you can also borrow entire functions wholesale if you attribute them properly.

In the end, an RTOS is an RTOS. It doesn’t matter if it’s developed for blinking LEDs or for guiding ICBMs. This thought got [Tom] and I to thinking about what other high-reliability open-source code is out there, hidden away in obscurity because of the industry that it was developed for. NASA’s core flight system came instantly to mind, but NASA makes much of its code available for you to use if you’re interested. There are surely worse places to draw inspiration!

What other off-the-beaten-path software sources do you know of that might be useful for our crowd?

Spectre lives. We’ve got two separate pieces of research, each finding new processor primitives that allow Spectre-style memory leaks. Before we dive into the details of the new techniques, let’s quickly remind ourselves what Spectre is. Modern CPUs use a variety of clever tricks to execute code faster, and one of the stumbling blocks is memory latency. When a program reaches a branch in execution, the program will proceed in one of two possible directions, and it’s often a value from memory that determines which branch is taken. Rather than wait for the memory to be fetched, modern CPUs will predict which branch execution will take, and speculatively execute the code down that branch. Once the memory is fetched and the branch is properly evaluated, the speculatively executed code is rewound if the guess was wrong, or made authoritative if the guess was correct. Spectre is the realization that incorrect branch prediction can change the contents of the CPU cache, and those changes can be detected through cache timing measurements. The end result is that arbitrary system memory can be leaked from a low privileged or even sandboxed user process.

In response to Spectre, OS developers and CPU designers have added domain isolation protections, that prevent branch prediction poisoning in an attack process from affecting the branch prediction in the kernel or another process. Training Solo is the clever idea from VUSec that branch prediction poisoning could just be done from within the kernel space, and avoid any domain switching at all. That can be done through cBPF, the classic Berkeley Packet Filter (BPF) kernel VM. By default, all users on a Linux system can run cBPF code, throwing the doors back open for Spectre shenanigans. There’s also an address collision attack where an unrelated branch can be used to train a target branch. Researchers also discovered a pair of CVEs in Intel’s CPUs, where prediction training was broken in specific cases, allowing for a wild 17 kB/sec memory leak.

Also revealed this week is the Branch Privilege Injection research from COMSEC. This is the realization that Intel Branch Prediction happens asynchronously, and in certain cases there is a race condition between the updates to the prediction engine, and the code being predicted. In short, user-mode branch prediction training can be used to poison kernel-mode prediction, due to the race condition.

(Editor’s note: Video seems down for the moment. Hopefully YouTube will get it cleared again soon. Something, something “hackers”.)

Both of these Spectre attacks have been patched by Intel with microcode, and the Linux kernel has integrated patches for the Training Solo issue. Training Solo may also impact some ARM processors, and ARM has issued guidance on the vulnerability. The real downside is that each fix seems to come with yet another performance hit.

Is That Real Cash? And What Does That Even Mean?

Over at the Something From Nothing blog, we have a surprisingly deep topic, in a teardown of banknote validators. For the younger in the audience, there was a time in years gone by where not every vending machine had a credit card reader built-in, and the only option was to carefully straighten a bill and feed it into the bill slot on the machine. Bow how do those machines know it’s really a bill, and not just the right sized piece of paper?

And that’s where this gets interesting. Modern currency has multiple security features in a single bill, like magnetic ink, micro printing, holograms, watermarks, and more. But how does a bill validator check for all those things? Mainly LEDs and photodetectors, it seems. With some machines including hall effect sensors, magnetic tape heads for detecting magnetic ink, and in rare cases a full linear CCD for scanning the bill as it’s inserted. Each of those detectors (except the CCD) produces a simple data stream from each bill that’s checked. Surely it would be easy enough to figure out the fingerprint of a real bill, and produce something that looks just like the real thing — but only to a validator?

In theory, probably, but the combination of sensors presents a real problem. It’s really the same problem with counterfeiting a bill in general: implementing a single security feature is doable, but getting them all right at the same time is nearly impossible. And so with the humble banknote validator.

Don’t Trust That Phone Call

There’s a scam that has risen to popularity with the advent of AI voice impersonation. It usually takes the form of a young person calling a parent or grandparent from jail or a hospital, asking for money to be wired to make it home. It sounds convincing, because it’s an AI deepfake of the target’s loved one. This is no longer just a technique to take advantage of loving grandparents. The FBI has issued a warning about an ongoing campaign using deepfakes of US officials. The aim of this malware campaign seems to be just getting the victim to click on a malicious link. This same technique was used in a LastPass attack last year, and the technique has become so convincing, it’s not likely to go away anytime soon.

AI Searching SharePoint

Microsoft has tried not to be left behind in the current flurry of AI rollouts that every tech company seems to be engaging in. Microsoft’s SharePoint is not immune, and the result is Microsoft Copilot for SharePoint. This gives an AI agent access to a company’s SharePoint knowledge base, allowing users to query it for information. It’s AI as a better search engine. This has some ramifications for security, as SharePoint installs tend to collect sensitive data.

The first ramification is the most straightforward. The AI can be used to search for that sensitive data. But Copilot pulling data from a SharePoint file doesn’t count as a view, making for a very stealthy way to pull data from those sensitive files. Pen Test Partners found something even better on a real assessment. A passwords file hosted on SharePoint was unavailable to view, but in an odd way. This file hadn’t been locked down using SharePoint permissions, but instead the file was restricted from previewing in the browser. This was likely an attempt to keep eyes off the contents of the file. And Copilot was willing to be super helpful, pasting the contents of that file right into a chat window. Whoops.

Fuzzing Apple’s CoreAudio

Googler [Dillon Franke] has the story of finding a type confusion flaw in Apple’s CoreAudio daemon, reachable via Mach Inter-Process Communication (IPC) messages, allowing for potential arbitrary code execution from within a sandboxed process. This is a really interesting fuzzing + reverse engineering journey, and it starts with imagining the attack he wanted to find: Something that could be launched from within a sandboxed browser, take advantage of already available IPC mechanisms, and exploit a complex process with elevated privileges.

Coreaudiod ticks all the boxes, but it’s a closed source daemon. How does one approach this problem? The easy option is to just fuzz over the IPC messages. It would be a perfectly viable strategy, to fuzz CoreAudio via Mach calls. The downside is that the fuzzer would run slower, and have much less visibility into what’s happening in the target process. A much more powerful approach is to build a fuzzing harness that allows hooking directly to the library in question. There is some definite library wizardry at play here, linking into a library function that hasn’t been exported.

The vulnerability that he found was type confusion, where the daemon expected an ioctl object, but could be supplied arbitrary data. As an ioctl object contains a pointer to a vtable, which is essentially a collection of function pointers. It then attempts to call a function from that table. It’s an ideal situation for exploitation. The fix from Apple is an explicit type check on the incoming objects.

Bits and Bytes

Asus publishes the DriverHub tool, a gui-less driver updater. It communicates with driverhub.asus.com using RPC calls. The problem is that it checks for the right web URL using a wildcard, and driverhub.asus.com.mrbruh.com was considered completely valid. Among the functions DriverHub can perform is to install drivers and updates. Chaining a couple of fake updates together results in relatively easy admin code execution on the local machine, with the only prerequisites being the DriverHub software being installed, and clicking a single malicious link. Ouch.

The VirtualBox VGA driver just patched a buffer overflow that could result in VM escape. The vmsvga3dSurfaceMipBufferSize call could be manipulated so no memory is actually allocated, but VirtualBox itself believes a buffer is there and writable. This memory write ability can be leveraged into arbitrary memory read and write capability on the host system.

And finally, what’s old is new again. APT28, a Russian state actor, has been using very old-school Cross Site Scripting (XSS) attacks to gain access to target’s webmail systems. The attack here is JavaScript in an email’s HTML code. That JS then used already known XSS exploits to exfiltrate emails and contacts. The worst part of this campaign is how low-effort it was. These aren’t cutting-edge 0-days. Instead, the target’s email servers just hadn’t been updated. Keep your webmail installs up to date!

Did artificial intelligence just jump the shark? Maybe so, and it came from the legal world of all places, with this report of an AI-generated victim impact statement. In an apparent first, the family of an Arizona man killed in a road rage incident in 2021 used AI to bring the victim back to life to testify during the sentencing phase of his killer’s trial. The video was created by the sister and brother-in-law of the 37-year-old victim using old photos and videos, and was quite well done, despite the normal uncanny valley stuff around lip-syncing that seems to be the fatal flaw for every deep-fake video we’ve seen so far. The victim’s beard is also strangely immobile, which we found off-putting.

In the video, the victim expresses forgiveness toward his killer and addresses his family members directly, talking about things like what he would have looked like if he’d gotten the chance to grow old. That seemed incredibly inflammatory to us, but according to Arizona law, victims and their families get to say pretty much whatever they want in their impact statements. While this appears to be legal, we wouldn’t be surprised to see it appealed, since the judge tacked an extra year onto the killer’s sentence over what the prosecution sought based on the power of the AI statement. If this tactic withstands the legal tests it’ll no doubt face, we could see an entire industry built around this concept.

Last week, we warned about the impending return of Kosmos 482, a Soviet probe that was supposed to go to Venus when it was launched in 1972. It never quite chooched, though, and ended up circling the Earth for the last 53 years. The satellite made its final orbit on Saturday morning, ending up in the drink in the Indian Ocean, far from land. Alas, the faint hope that it would have a soft landing thanks to the probe’s parachute having apparently been deployed at some point in the last five decades didn’t come to pass. That’s a bit of a disappointment to space fans, who’d love to get a peek inside this priceless bit of space memorabilia. Roscosmos says they monitored the descent, so presumably they know more or less where the debris rests. Whether it’s worth an expedition to retrieve it remains to be seen.

Are we really at the point where we have to worry about counterfeit thermal paste? Apparently, yes, judging by the effort Arctic Cooling is putting into authenticity verification of its MX brand pastes. To make sure you’re getting the real deal, boxes will come with seals that rival those found on over-the-counter medications and scratch-off QR codes that can be scanned and cross-referenced to an online authentication site. We suppose it makes sense; chip counterfeiting is a very real thing, after all, and it’s probably as easy to put a random glob of goo into a syringe as it is to laser new markings onto a chip package. And Arctic compound commands a pretty penny, so the incentive is obvious. But still, something about this just bothers us.

Another very cool astrophotography shot this week, this time a breathtaking collection of galaxies. Taken from the Near Infrared camera on the James Webb Space Telescope with help from the Hubble Space Telescope and the XMM-Newton X-ray space observatory, the image shows thousands of galaxies of all shapes and sizes, along with the background X-ray glow emitted by all the clouds of superheated dust and gas between them. The stars with the characteristic six-pointed diffraction spikes are all located within our galaxy, but everything else is a galaxy. The variety is fascinating, and the scale of the image is mind-boggling. It’s galactic eye candy!

And finally, if you’ve ever wondered about what happens when a nuclear reactor melts down, you’re in luck with this interesting animagraphic on the process. It’s not a detailed 3D render of any particular nuclear power plant and doesn’t have a specific meltdown event in mind, although it does mention both Chernobyl and Fukushima. Rather, it’s a general look at pressurized water reactors and what can go wrong when the cooling water stops flowing. It also touches on potentially safer designs with passive safety systems that rely on natural convection to keep cooling water circulating in the event of disaster, along with gravity-fed deluge systems to cool the containment vessel if things get out of hand. It’s a good overview of how reactors work and where they can go wrong. Enjoy.

Every time we end up talking about 3D printers, Al Williams starts off on how bad he is in a machine shop. I’m absolutely sure that he’s exaggerating, but the gist is that he’s much happier to work on stuff in CAD and let the machine take care of the precision and fine physical details. I’m like that too, but with me, it’s the artwork.

I can’t draw to save my life, but once I get it into digital form, I’m pretty good at manipulating images. And then I couldn’t copy that out into the real world, but that’s what the laser cutter is for, right? So the gameplan for this year’s Mother’s Day gift (reminder!) is three-way. I do the physical design, my son does the artwork, we combine them in FreeCAD and then hand it off to the machine. Everyone is playing to their strengths.

So why does it feel a little like cheating to just laser-cut out a present? I’m not honestly sure. My grandfather was a trained architectural draftsman before he let his artistic side run wild and went off to design jewellery. He could draw a nearly perfect circle with nothing more than a pencil, but he also used a French curve set, a pantograph, and a rolling architect’s ruler when they were called for. He had his tools too, and I bet he’d see the equivalence in mine.

People have used tools since the stone age, and the people who master their tools transcend them, and produce work where the “human” shines through despite having traced a curve or having passed the Gcode off to the cutter. If you doubt this, I’ll remind you of the technological feat that is the piano, with which people nonetheless produce music that doesn’t make you think of the hammers or of the tremendous cast metal frame. The tech disappears into the creation.

I’m sure there’s a parable here for our modern use of AI too, but I’ve got a Mother’s Day present to finish.

Cryptographic messaging has been in the news a lot recently. Like the formal audit of WhatsApp (the actual PDF). And the results are good. There are some minor potential problems that the audit highlights, but they are of questionable real-world impact. The most consequential is how easy it is to add additional members to a group chat. Or to put it another way, there are no cryptographic guarantees associated with adding a new user to a group.

The good news is that WhatsApp groups don’t allow new members to read previous messages. So a user getting added to a group doesn’t reveal historic messages. But a user added without being noticed can snoop on future messages. There’s an obvious question, as to how this is a weakness. Isn’t it redundant, since anyone with the permission to add someone to a group, can already read the messages from that group?

That’s where the lack of cryptography comes in. To put it simply, the WhatsApp servers could add users to groups, even if none of the existing users actually requested the addition. It’s not a vulnerability per se, but definitely a design choice to keep in mind. Keep an eye on the members in your groups, just in case.

The Signal We Have at Home

The TeleMessage app has been pulled from availability, after it was used to compromise Signal communications of US government officials. There’s political hay to be made out of the current administration’s use and potential misuse of Signal, but the political angle isn’t what we’re here for. The TeleMessage client is Signal compatible, but adds message archiving features. Government officials and financial companies were using this alternative client, likely in order to comply with message retention laws.

While it’s possible to do long term message retention securely, TeleMessage was not doing this particularly well. The messages are stripped of their end-to-end encryption in the client, before being sent to the archiving server. It’s not clear exactly how, but those messages were accessed by a hacker. This nicely demonstrates the inherent tension between the need for transparent archiving as required by the US government for internal communications, and the need for end-to-end encryption.

The NSO Judgement

WhatsApp is in the news for another reason, this time winning a legal judgement against NSO Group for their Pegasus spyware. The $167 Million in damages casts real doubt on the idea that NSO has immunity to develop and deploy malware, simply because it’s doing so for governments. This case is likely to be appealed, and higher courts may have a different opinion on this key legal question, so hold on. Regardless, the era of NSO’s nearly unrestricted actions is probably over. They aren’t the only group operating in this grey legal space, and the other “legal” spyware/malware vendors are sure to be paying attention to this ruling as well.

The $5 Wrench

In reality, the weak point of any cryptography scheme is the humans using it. We’re beginning to see real world re-enactments of the famous XKCD $5 wrench, that can defeat even 4096-bit RSA encryption. In this case, it’s the application of old crime techniques to new technology like cryptocurrency. To quote Ars Technica:

We have reached the “severed fingers and abductions” stage of the crypto revolution

The flashy stories involve kidnapping and torture, but let’s not forget that the most common low-tech approach is simple deception. Whether you call it the art of the con, or social engineering, this is still the most likely way to lose your savings, whether it’s conventional or a cryptocurrency.

The SonicWall N-day

WatchTowr is back with yet another reverse-engineered vulnerability. More precisely, it’s two CVEs that are being chained together to achieve pre-auth Remote Code Execution (RCE) on SonicWall appliances. This exploit chain has been patched, but not everyone has updated, and the vulnerabilities are being exploited in the wild.

The first vulnerability at play is actually from last year, and is in Apache’s mod_rewrite module. This module is widely used to map URLs to source files, and it has a filename confusion issue where a url-encoded question mark in the path can break the mapping to the final filesystem path. A second issue is that when DocumentRoot is specified, instances of RewriteRule take on a weird dual-meaning. The filesystem target refers to the location inside DocumentRoot, but it first checks for that location in the filesystem root itself. This was fixed in Apache nearly a year ago, but it takes time for patches to roll out.

SonicWall was using a rewrite rule to serve CSS files, and the regex used to match those files is just flexible enough to be abused for arbitrary file read. /mnt/ram/var/log/httpd.log%3f.1.1.1.1a-1.css matches that rule, but includes the url-encoded question mark, and matches a location on the root filesystem. There are other, more interesting files to access, like the temp.db SQLite database, which contains session keys for the currently logged in users.

The other half of this attack is a really clever command injection using one of the diagnostic tools included in the SonicWall interface. Traceroute6 is straightforward, running a traceroute6 command and returning the results. It’s also got good data sanitization, blocking all of the easy ways to break out of the traceroute command and execute some arbitrary code. The weakness is that while this sanitization adds backslashes to escape quotes and other special symbols, it stores the result in a fixed-length result buffer. If the result of this escaping process overflows the result buffer, it writes over the null terminator and into the buffer that holds the original command before it’s sanitized. This overflow is repeated when the command is run, and with some careful crafting, this results in escaping the sanitization and including arbitrary commands. Clever.

The AI CVE DDoS

[Daniel Stenberg], lead developer of curl, is putting his foot down. We’ve talked about this before, even chatting with Daniel about the issue when we had him on FLOSS Weekly. Curl’s bug bounty project has attracted quite a few ambitious people, that don’t actually have the skills to find vulnerabilities in the curl codebase. Instead, these amateur security researchers are using LLMs to “find vulnerabilities”. Spoiler, LLMs aren’t yet capable of this task. But LLMs are capable of writing fake vulnerability reports that look very convincing at first read. The game is usually revealed when the project asks a question, and the fake researcher feeds the LLM response back into the bug report.

This trend hasn’t slowed, and the curl project is now viewing the AI generated vulnerability reports as a form of DDoS. In response, the curl Hackerone bounty program will soon ask a question with every entry: “Did you use an AI to find the problem or generate this submission?” An affirmative answer won’t automatically disqualify the report, but it definitely puts the burden on the reporter to demonstrate that the flaw is real and wasn’t hallucinated. Additionally, “AI slop” reports will result in permanent bans for the reporter.

It’s good to see that not all AI content is completely disallowed, as it’s very likely that LLMs will be involved in finding and describing vulnerabilities before long. Just not in this naive way, where a single prompt results in a vulnerability find and generates a patch that doesn’t even apply. Ironically, one of the tells of an AI generated report is that it’s too perfect, particularly for someone’s first report. AI is still the hot new thing, so this issue likely isn’t going away any time soon.

Bits and Bytes

A supply chain attack has been triggered against several hundred Magento e-commerce sites, via at least three software vendors distributing malicious code. One of the very odd elements to this story is that it appears this malicious code has been incubating for six years, and only recently invoked for malicious behavior.

On the WordPress side of the fence, the Ottokit plugin was updated last month to fix a critical vulnerability. That update was force pushed to the majority of WordPress sites running that plugin, but that hasn’t stopped threat actors from attempting to use the exploit, with the first attempts coming just an hour and a half after disclosure.

It turns out it’s probably not a great idea to allow control codes as part of file names. Portswigger has a report of a couple ways VS Code can do the wrong thing with such filenames.

And finally, this story comes with a disclaimer: Your author is part of Meshtastic Solutions and the Meshtastic project. We’ve talked about Meshtastic a few times here on Hackaday, and would be remiss not to point out CVE-2025-24797. This buffer overflow could theoretically result in RCE on the node itself. I’ve seen at least one suggestion that this is a wormable vulnerability, which may be technically true, but seems quite impractical in practice. Upgrade your nodes to at least release 2.6.2 to get the fix.

By now, you’ve probably heard about Kosmos 482, a Soviet probe destined for Venus in 1972 that fell a bit short of the mark and stayed in Earth orbit for the last 53 years. Soon enough, though, the lander will make its fiery return; exactly where and when remain a mystery, but it should be sometime in the coming week. We talked about the return of Kosmos briefly on this week’s podcast and even joked a bit about how cool it would be if the parachute that would have been used for the descent to Venus had somehow deployed over its half-century in space. We might have been onto something, as astrophotographer Ralf Vanderburgh has taken some pictures of the spacecraft that seem to show a structure connected to and trailing behind it. The chute is probably in pretty bad shape after 50 years of UV torture, but how cool is that?

Parachute or not, chances are good that the 495-kilogram spacecraft, built to not only land on Venus but to survive the heat, pressure, and corrosive effects of the hellish planet’s atmosphere, will at least partially survive reentry into Earth’s more welcoming environs. That’s a good news, bad news thing: good news that we might be able to recover a priceless artifact of late-Cold War space technology, bad news to anyone on the surface near where this thing lands. If Kosmos 482 does manage to do some damage, it won’t be the first time. Shortly after launch, pieces of titanium rained down on New Zealand after the probe’s booster failed to send it on its way to Venus, damaging crops and starting some fires. The Soviets, ever secretive about their space exploits until they could claim complete success, disavowed the debris and denied responsibility for it. That made the farmers whose fields they fell in the rightful owners, which is also pretty cool. We doubt that the long-lost Kosmos lander will get the same treatment, but it would be nice if it did.

Also of note in the news this week is a brief clip of a Unitree humanoid robot going absolutely ham during a demonstration — demo-hell, amiright? Potential danger to the nearby engineers notwithstanding, the footage is pretty hilarious. The demo, with a robot hanging from a hoist in a crowded lab, starts out calmly enough, but goes downhill quickly as the robot starts flailing its arms around. We’d say the movements were uncontrolled, but there are points where the robot really seems to be chasing the engineer and taking deliberate swipes at the poor guy, who was probably just trying to get to the e-stop switch. We know that’s probably just the anthropomorphization talking, but it sure looks like the bot had a beef to settle.  You be the judge.

Also from China comes a report of “reverse ATMs” that accept gold and turn it into cash on the spot (apologies for yet another social media link, but that’s where the stories are these days). The machine shown has a hopper into which customers can load their unwanted jewelry, after which it is reportedly melted down and assayed for purity. The funds are then directly credited to the customer’s account electronically. We’re not sure we fully believe this — thinking about the various failure modes of one of those fresh-brewed coffee machines, we shudder to think about the consequences of a machine with a 1,000°C furnace built into it. We also can’t help but wonder how the machine assays the scrap gold — X-ray fluorescence? Ramann spectroscopy? Also, what happens to the unlucky customer who puts some jewelry in that they thought was real gold, only to be told by the machine that it wasn’t? Do they just get their stuff back as a molten blob? The mind boggles.

And finally, the European Space Agency has released a stunning new image of the Sun. Captured by their Solar Orbiter spacecraft in March from about 77 million kilometers away, the mosaic is composed of about 200 images from the Extreme Ultraviolet Imager. The Sun was looking particularly good that day, with filaments, active regions, prominences, and coronal loops in evidence, along with the ethereal beauty of the Sun’s atmosphere. The image is said to be the most detailed view of the Sun yet taken, and needs to be seen in full resolution to be appreciated. Click on the image below and zoom to your heart’s content.

 

 

 

Dan Maloney and I were talking on the podcast about his memories of the old electronics magazines, and how they had some gonzo projects in them. One, a DIY picture phone from the 1980s, was a monster build of a hundred ICs that also required you to own a TV camera. At that time, the idea of being able to see someone while talking to them on the phone was pure science fiction, and here was a version of that which you could build yourself.

Still, we have to wonder how many of these were ever built. The project itself was difficult and expensive, but you actually have to multiply that by two if you want to talk with someone else. And then you have to turn your respective living rooms into TV studios. It wasn’t the most practical of projects.

But amazing projects did something in the old magazines that we take a little bit for granted today: they showed what was possible. And if you want to create something new, you’re not necessarily going to know how to do it, but just the idea that it’s possible at all is often enough to give a motivated hacker the drive to make it real. As skateboard hero Rodney Mullen put it, “the biggest obstacle to creativity is breaking through the barrier of disbelief”.

In the skating world, it’s seeing someone else do a trick in a video that lets you know that it’s possible, and then you can make it your own. In our world, in prehistoric times, it was these electronics magazines that showed you what was possible. In the present, it’s all over the Internet, and all over Hackaday. So when you see someone’s amazing project, even if you aren’t necessarily into it, or maybe don’t even fully understand it, your horizons of what’s possible are nonetheless expanded, and that helps us all be more creative.

Keep on pushing!

This week, Oligo has announced the AirBorne series of vulnerabilities in the Apple Airdrop protocol and SDK. This is a particularly serious set of issues, and notably affects MacOS desktops and laptops, the iOS and iPadOS mobile devices, and many IoT devices that use the Apple SDK to provide AirPlay support. It’s a group of 16 CVEs based on 23 total reported issues, with the ramifications ranging from an authentication bypass, to local file reads, all the way to Remote Code Execution (RCE).

AirPlay is a WiFi based peer-to-peer protocol, used to share or stream media between devices. It uses port 7000, and a custom protocol that has elements of both HTTP and RTSP. This scheme makes heavy use of property lists (“plists”) for transferring serialized information. And as we well know, serialization and data parsing interfaces are great places to look for vulnerabilities. Oligo provides an example, where a plist is expected to contain a dictionary object, but was actually constructed with a simple string. De-serializing that plist results in a malformed dictionary, and attempting to access it will crash the process.

Another demo is using AirPlay to achieve an arbitrary memory write against a MacOS device. Because it’s such a powerful primative, this can be used for zero-click exploitation, though the actual demo uses the music app, and launches with a user click. Prior to the patch, this affected any MacOS device with AirPlay enabled, and set to either “Anyone on the same network” or “Everyone”. Because of the zero-click nature, this could be made into a wormable exploit.

Apple has released updates for their products for all of the CVEs, but what’s going to really take a long time to clean up is the IoT devices that were build with the vulnerable SDK. It’s likely that many of those devices will never receive updates.

EvilNotify

It’s apparently the week for Apple exploits, because here’s another one, this time from [Guilherme Rambo]. Apple has built multiple systems for doing Inter Process Communications (IPC), but the simplest is the Darwin Notification API. It’s part of the shared code that runs on all of Apple’s OSs, and this IPC has some quirks. Namely, there’s no verification system, and no restrictions on which processes can send or receive messages.

That led our researcher to ask what you may be asking: does this lack of authentication allow for any security violations? Among many novel notifications this technique can spoof, there’s one that’s particularly problematic: The device “restore in progress”. This locks the device, leaving only a reboot option. Annoying, but not a permanent problem.

The really nasty version of this trick is to put the code triggering a “restore in progress” message inside an app’s widget extension. iOS loads those automatically at boot, making for an infuriating bootloop. [Guilherme] reported the problem to Apple, made a very nice $17,500 in the progress. The fix from Apple is a welcome surprise, in that they added an authorization mechanism for sensitive notification endpoints. It’s very likely that there are other ways that this technique could have been abused, so the more comprehensive fix was the way to go.

Jenkins

Continuous Integration is one of the most powerful tools a software project can use to stay on top of code quality. Unfortunately as those CI toolchains get more complicated, they are more likely to be vulnerable, as [John Stawinski] from Praetorian has discovered. This attack chain would target the Node.js repository at Github via an outside pull request, and ends with code execution on the Jenkins host machines.

The trick to pulling this off is to spoof the timestamp on a Pull Request. The Node.js CI uses PR labels to control what CI will do with the incoming request. Tooling automatically adds the “needs-ci” label depending on what files are modified. A maintainer reviews the PR, and approves the CI run. A Jenkins runner will pick up the job, compare that the Git timestamp predated the maintainer’s approval, and then runs the CI job. Git timestamps are trivial to spoof, so it’s possible to load an additional commit to the target PR with a commit timestamp in the past. The runner doesn’t catch the deception, and runs the now-malicious code.

[John] reported the findings, and Node.js maintainers jumped into action right away. The primary fix was to do SHA sum comparisons to validate Jenkins runs, rather than just relying on timestamp. Out of an abundance of caution, the Jenkins runners were re-imaged, and then [John] was invited to try to recreate the exploit. The Node.js blog post has some additional thoughts on this exploit, like pointing out that it’s a Time-of-Check-Time-of-Use (TOCTOU) exploit. We don’t normally think of TOCTOU bugs where a human is the “check” part of the equation.

2024 in 0-days

Google has published an overview of the 75 zero-day vulnerabilities that were exploited in 2024. That’s down from the 98 vulnerabilities exploited in 2023, but the Threat Intelligence Group behind this report are of the opinion that we’re still on an upward trend for zero-day exploitation. Some platforms like mobile and web browsers have seen drastic improvements in zero-day prevention, while enterprise targets are on the rise. The real stand-out is the targeting of security appliances and other network devices, at more than 60% of the vulnerabilities tracked.

When it comes to the attackers behind exploitation, it’s a mix between state-sponsored attacks, legal commercial surveillance, and financially motivated attacks. It will be interesting to see how 2025 stacks up in comparison. But one thing is for certain: Zero-days aren’t going away any time soon.

Perplexing Passwords for RDP

The world of computer security just got an interesting surprise, as Microsoft declared it not-a-bug that Windows machines will continue to accept revoked credentials for Remote Desktop Protocol (RDP) logins. [Daniel Wade] discovered the issue and reported it to Microsoft, and then after being told it wasn’t a security vulnerability, shared his report with Ars Technica.

So what exactly is happening here? It’s the case of a Windows machine login via Azure or a Microsoft account. That account is used to enable RDP, and the machine caches the username and password so logins work even when the computer is “offline”. The problem really comes in how those cached passwords get evicted from the cache. When it comes to RDP logins, it seems they are simply never removed.

There is a stark disconnect between what [Wade] has observed, and what Microsoft has to say about it. It’s long been known that Windows machines will cache passwords, but that cache will get updated the next time the machine logs in to the domain controller. This is what Microsoft’s responses seem to be referencing. The actual report is that in the case of RDP, the cached passwords will never expire, regardless of changing that password in the cloud and logging on to the machine repeatedly.

Bits and Bytes

Samsung makes a digital signage line, powered by the MagicINFO server application. That server has an unauthenticated endpoint, accepting file uploads with insufficient filename sanitization. That combination leads to arbitrary pre-auth code execution. While that’s not great, what makes this a real problem is that the report was first sent to Samsung in January, no response was ever received, and it seems that no fixes have officially been published.

A series of Viasat modems have a buffer overflow in their SNORE web interface. This leads to unauthenticated, arbitrary code execution on the system, from either the LAN or OTA interface, but thankfully not from the public Internet itself. This one is interesting in that it was found via static code analysis.

IPv6 is the answer to all of our IPv4 induced woes, right? It has Stateless Address Autoconfiguration (SLAAC) to handle IP addressing without DHCP, and Router Advertisement (RA) to discover how to route packets. And now, taking advantage of that great functionality is Spellbinder, a malicious tool to pull off SLACC attacks and do DNS poisoning. It’s not entirely new, as we’ve seen Man in the Middle attacks on IPv4 networks for years. IPv6 just makes it so much easier.

Brain-to-speech interfaces have been promising to help paralyzed individuals communicate for years. Unfortunately, many systems have had significant latency that has left them lacking somewhat in the practicality stakes.

A team of researchers across UC Berkeley and UC San Francisco has been working on the problem and made significant strides forward in capability. A new system developed by the team offers near-real-time speech—capturing brain signals and synthesizing intelligible audio faster than ever before.

New Capability

The aim of the work was to create more naturalistic speech using a brain implant and voice synthesizer. While this technology has been pursued previously, it faced serious issues around latency, with delays of around eight seconds to decode signals and produce an audible sentence. New techniques had to be developed to try and speed up the process to slash the delay between a user trying to “speak” and the hardware outputting the synthesized voice.

The implant developed by researchers is used to sample data from the speech sensorimotor cortex of the brain—the area that controls the mechanical hardware that makes speech: the face, vocal chords, and all the other associated body parts that help us vocalize. The implant captures signals via an electrode array surgically implanted into the brain itself. The data captured by the implant is then passed to an AI model which figures out how to turn that signal into the right audio output to create speech. “We are essentially intercepting signals where the thought is translated into articulation and in the middle of that motor control,” said Cheol Jun Cho, a Ph.D student at UC Berkeley. “So what we’re decoding is after a thought has happened, after we’ve decided what to say, after we’ve decided what words to use, and how to move our vocal-tract muscles.”

The AI model had to be trained to perform this role. This was achieved by having a subject, Ann, look at prompts and attempting to “speak ” the phrases. Ann has suffered from paralysis after a stroke which left her unable to speak. However, when she attempts to speak, relevant regions in her brain still lit up with activity, and sampling this enabled the AI to correlate certain brain activity to intended speech. Unfortunately, since Ann could no longer vocalize herself, there was no target audio for the AI to correlate the brain data with. Instead, researchers used a text-to-speech system to generate simulated target audio for the AI to match with the brain data during training. “We also used Ann’s pre-injury voice, so when we decode the output, it sounds more like her,” explains Cho. A recording of Ann speaking at her wedding provided source material to help personalize the speech synthesis to sound more like her original speaking voice.

To measure performance of the new system, the team compared the time it took the system to generate speech to the first indications of speech intent in Ann’s brain signals. “We can see relative to that intent signal, within one second, we are getting the first sound out,” said Gopala Anumanchipalli, one of the researchers involved in the study. “And the device can continuously decode speech, so Ann can keep speaking without interruption.” Crucially, too, this speedier method didn’t compromise accuracy—in this regard, it decoded just as well as previous slower systems.

The decoding system works in a continuous fashion—rather than waiting for a whole sentence, it processes in small 80-millisecond chunks and synthesizes on the fly. The algorithms used to decode the signals were not dissimilar from those used by smart assistants like Siri and Alexa, Anumanchipalli explains. “Using a similar type of algorithm, we found that we could decode neural data and, for the first time, enable near-synchronous voice streaming,” he says. “The result is more naturalistic, fluent speech synthesis.”

It was also key to determine whether the AI model

was genuinely communicating what Ann was trying to say. To investigate this, Ann was qsked to try and vocalize words outside the original training data set—things like the NATO phonetic alphabet, for example. “We wanted to see if we could generalize to the unseen words and really decode Ann’s patterns of speaking,” said Anumanchipalli. “We found that our model does this well, which shows that it is indeed learning the building blocks of sound or voice.”

For now, this is still groundbreaking research—it’s at the cutting edge of machine learning and brain-computer interfaces. Indeed, it’s the former that seems to be making a huge difference to the latter, with neural networks seemingly the perfect solution for decoding the minute details of what’s happening with our brainwaves. Still, it shows us just what could be possible down the line as the distance between us and our computers continues to get ever smaller.

Featured image: A researcher connects the brain implant to the supporting hardware of the voice synthesis system. Credit: UC Berkeley

Don’t you love it when the title track is the first one on the album? I had to single out this adjustable keyboard called the Protractor, because look at it! The whole thing moves, you know. Go look at the gallery.

If you use a true split, even if you never leave the house, you know the pain of losing the good angle and/or separation you had going on for whatever reason. Not only does this monoblock split solve that simply by being a monoblock split, you can always find the right angle you had via the built-in angle finder.

[BFB_Workshop] used a nice!nano v2, but you could use any ZMK-supported board with the same dimensions. This 5 x 12 has 60 Gateron KS-33 switches, which it was made for, and has custom keycaps. You can, of course, see all the nice, neat ribbon cable wiring through the clear PLA, which is a really great touch.

This bad boy is flat enough that you can use the table as your palm rest. To me, that doesn’t sound so comfortable, but then again, I like key wells and such. I’d still love to try a Protractor, because it looks quite interesting to type on. If you want to build one, the files and instructions are available on Printables.

Present Arms: the AR-60%

Yes I stole that joke, sort of. Don’t shoot! Anyway, as [Sli22ard] asks, does your keyboard have a mil-spec stock? I’m guessing no, although you might have a knife nearby. I myself have a fancy-handled butter knife for opening mail.

This is [Sli22ard]’s latest “abomination”, and the best part is that the MOE fixed carbine stock folds up so that the whole thing fits on the ever-important keyboard display. (Click to the second picture and be sure to admire the Dreamcast that was in storage for however long.)

The case is a Keysme Pic60, custom Cerakoted, with a 4pplet waffling60 PCB within its walls. That case is meant to have things hanging off the upper left corner, so that must have been a great place to start as far as connecting up the stock.

[Sli22ard] used Gateron Type R switches and a NovelKeys Cream Arc switch for the Spacebar. Most of the keycaps are GMK Striker, with the 10u Spacebar from Awekeys.

I particularly like the midnight-y keycaps along with that monster gold Spacebar. [Sli22ard] says it thocks like nobody’s business, and I believe it.

The Centerfold: the Quiet Type

[Pleasant_Dot_189] sure has a pleasant research-only battlestation, don’t they? Sure, there are four screens, but there’s no RGB, and the only plant can safely be ignored for weeks at a time. Why four screens? This way,  [Pleasant_Dot_189] doesn’t have to switch between tasks or tabs and can just write as they work on their fifth book.

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 Malling-Hansen Takygraf

The astute among you will remember that we’ve covered the Malling-Hansen Writing Ball, the more well-known offering from M-H. Well, this here is the Malling-Hansen Takygraf (or Takygraph, depending upon where you are in the world), and it was quite the writing machine. Only one was created, and its whereabouts are unknown.

Rasmus Malling-Hansen’s intention was to create a typewriter that could type at the speed of human speech. And he succeeded — the Takygraf could reach speeds of 1200 characters per minute. He hoped the Takygraf would be used for stenography.

The VP of the Malling-Hansen Society describes the function of the Takygraf as follows: “The first Takygraf from 1872 was combined with a writing ball but the bottom of each piston forms a blunt point and so it forms only impressions in the paper. The paper band was prepared to conduct electricity. Under the paper band there were metal points which were connected to electromagnets. The form impressions in the paper band are brought in contact with the fixed metal points under the paper as the paper moves along and so the corresponding electromagnets are brought into action. When the electromagnets attracted the keepers, then the types made their impressions on the paper band (through the invention of a colored or carbonized strip of paper).

In the year 1874 follows a modified Takygraf combined with a writing ball but instead of the prepared paper (to conduct electricity) and the form impressions in the paper Rasmus Malling-Hansen developed a mechanical memory-unit, which contacts the electromagnets in the right time to make the needed type impressions on the paper band. It was possible to write with this brilliant invention as fast as we talk.”

Be sure to visit this fantastic model viewer of the Takygraph on your way out.

Finally, a Keyboard for Metalheads

Actually, the Cleaver is another aluminium keyboard, not the Icebreaker from a couple Keebins ago. But they’re from the same company, and the idea is basically the same. Aluminium wherever possible, and tiny, laser-cut holes that make up the legends. At least these are more legible.

And, whereas the Icebreaker definitely doubled as bludgeoning device, the Cleaver is much slimmer and more streamlined. Both are machined from a single block of aluminium.

Much like its predecessor, the Cleaver is a Hall-effect keyboard, which I would really like to type on someday while I consider how they can never really wear out in the traditional switch sense.

Inside the metal block, the electronics are huddled away from its raw power inside of a silicone core. This is meant to enhance the typing acoustics, protect against dust, sweat, and coffee, and has the added effect of popping out the underside to be a nice, non-slip foot.

Unlike the Icebreaker, which started at $2100, the pre-order price for the Cleaver is a mere $850. And to get this one in black? Still just $850. I’m curious to know how much it weighs, since it’s much more portable-looking. The Cleaver would be an icebreaker for sure.

---

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.

Looks like the Simpsons had it right again, now that an Australian radio station has been caught using an AI-generated DJ for their midday slot. Station CADA, a Sydney-based broadcaster that’s part of the Australian Radio Network, revealed that “Workdays with Thy” isn’t actually hosted by a person; rather, “Thy” is a generative AI text-to-speech system that has been on the air since November. An actual employee of the ARN finance department was used for Thy’s voice model and her headshot, which adds a bit to the creepy factor.

The discovery that they’ve been listening to a bot for months apparently has Thy’s fans in an uproar, although we suspect that the media doing the reporting is probably more exercised about this than the general public. Radio stations have used robo-jocks for the midday slot for ages, albeit using actual human DJs to record patter to play between tunes and commercials. Anyone paying attention over the last few years probably shouldn’t be surprised by this development, and we suspect similar disclosures will be forthcoming across the industry now that the cat’s out of the bag.

Also from the world of robotics, albeit the hardware kind, is this excellent essay from Brian Potter over at Construction Physics about the sad state of manual dexterity in humanoid robots. The whole article is worth reading, not least for the link to a rogue’s gallery of the current crop of humanoid robots, but briefly, the essay contends that while humanoid robots do a pretty good job of navigating in the world, their ability to do even the simplest tasks is somewhat wanting.

Brian’s example of unwrapping and applying a Band-Aid, a task that any toddler can handle, as being unimaginably difficult for any current robot to handle is quite apt. He attributes the gap in abilities between gross movements and fine motor control partly to hardware and partly to software. We think the blame skews more to the hardware side; while the legs and torso of the typical humanoid robot offer a lot of real estate for powerful actuators, squeezing that much equipment into a hand approximately the size of a human’s is a tall order. These problems will likely be overcome, of course, and when they do, Brian’s helpful list of “Dexterity Evals” or something similar will act as a sort of Turing test for robot dexterity. Although the day a humanoid robot can start a new roll of toilet paper without tearing the first sheet is the day we head for the woods.

We recently did a story on the use of nitrogen-vacancy diamonds as magnetic sensors, which we found really exciting because it’s about the simplest way we’ve seen to play with quantum physics at home. After that story ran, eagle-eyed reader Kealan noticed that Brian over at the “Real Engineering” channel on YouTube had recently run a video on anti-submarine warfare, which includes the uses of similar quantum magnetometers to detect submarines. The magnetometers in the video are based on the Zeeman effect and use laser-pumped helium atoms to detect tiny variations in the Earth’s magnetic field due to large ferrous objects like submarines. Pretty cool video; check it out.

And finally, if you have the slightest interest in civil engineering you’ve got to check out Animagraff’s recent 3D tour of the insides of Hoover Dam. If you thought a dam was just a big, boring block of concrete dumped in the middle of a river, think again. The video is incredibly detailed and starts with accurate 3D models of Black Canyon before the dam was built. Every single detail of the dam is shown, with the “X-ray views” of the dam with the surrounding rock taken away being our favorite bit — reminds us a bit of the book Underground by David Macaulay. But at the end of the day, it’s the enormity of Hoover Dam that really comes across in this video. The way that the structure dwarfs the human-for-scale included in almost every sequence is hard to express — megalophobics, beware. We were also floored by just how much machinery is buried in all that concrete. Sure, we knew about the generators, but the gates on the intake towers and the way the spillways work were news to us. Highly recommended.

It was probably Montesquieu who coined the proto-hacker motto “the best is the mortal enemy of the good”. He was talking about compromises in drafting national constitutions for nascent democracies, of course, but I’ll admit that I do hear his voice when I’m in get-it-done mode and start cutting corners on a project. A working project is better than a gold-plated one.

But what should I do, Monte, when good enough turns out to also be the mortal enemy of the best? I have a DIY coffee roaster that is limping along for years now on a blower box that uses a fan scavenged in anger from an old Dust Buster. Many months ago, I bought a speed-controllable and much snazzier brushless blower fan to replace it, that would solve a number of minor inconveniences with the current design, but which would also require some building and another dive into the crufty old firmware.

So far, I’ve had good enough luck that the roaster will break down from time to time, and I’ll use that as an excuse to fix that part of the system, and maybe even upgrade another as long as I have it apart. But for now, it’s running just fine. I mean, I have to turn the fan on manually, and the new one could be automatic. I have only one speed for the fan, and the new one would be variable. But the roaster roasts, and a constant source of coffee is mission critical in this house. The spice must flow!

Reflecting on this situation, it seems to me that the smart thing to do is work on smoothing the transitions from good enough to best. Like maybe I could prototype up the new fan box without taking the current one apart. Mock up some new driver code on the side while I’m at it?

Maybe Montesquieu was wrong, and the good and the best aren’t opposites after all. Maybe the good enough is just the first step on the path toward the best, and a wise man spends his energy on making the two meet in the middle, or making the transition from one to the other as painless as possible.

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

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

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

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

Zyxel FLEX

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

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

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

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

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

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

Power Glitching an STM32

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

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

MCP Line Jumping

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

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

Bits and Bytes

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

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

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

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

We appear to be edging ever closer to a solid statement of “We are not alone” in the universe with this week’s announcement of the detection of biosignatures in the atmosphere of exoplanet K2-18b. The planet, which is 124 light-years away, has been the focus of much attention since it was discovered in 2015 using the Kepler space telescope because it lies in the habitable zone around its red-dwarf star. Initial observations with Hubble indicated the presence of water vapor, and follow-up investigations using the James Webb Space Telescope detected all sorts of goodies in the atmosphere, including carbon dioxide and methane. But more recently, JWST saw signs of dimethyl sulfide (DMS) and dimethyl disulfide (DMDS), organic molecules which, on Earth, are strongly associated with biological processes in marine bacteria and phytoplankton.

The team analyzing the JWST data says that the data is currently pretty good, with a statistical significance of 99.7%. That’s a three-sigma result, and while it’s promising, it’s not quite good enough to seal the deal that life evolved more than once in the universe. If further JWST observations manage to firm that up to five sigma, it’ll be the most important scientific result of all time. To our way of thinking, it would be much more significant than finding evidence of ancient or even current life in our solar system, since cross-contamination is so easy in the relatively cozy confines of the Sun’s gravity well. K2-18b is far enough away from our system as to make that virtually impossible, and that would say a lot about the universality of biochemical evolution. It could also provide an answer to the Fermi Paradox, since it could indicate that the galaxy is actually teeming with life but under conditions that make it difficult to evolve into species capable of making detectable techno-signatures. It’s hard to build a radio or a rocket when you live on a high-g water world, after all.

Closer to home, there’s speculation that the famous Antikythera mechanism may not have worked at all in its heyday. According to researchers from Universidad Nacional de Mar del Plata in Argentina, “the world’s first analog computer” could not have worked due to the accumulated mechanical error of its gears. They blame this on the shape of the gear teeth, which appear triangular on CT scans of the mechanism, and which they seem to attribute to manufacturing defects. Given the 20-odd centuries the brass-and-iron device spent at the bottom of the Aegean Sea and the potential for artifacts in CT scans, we’re not sure it’s safe to pin the suboptimal shape of the gear teeth on the maker of the mechanism. They also seem to call into question the ability of 1st-century BCE craftsmen to construct a mechanism with sufficient precision to serve as a useful astronomical calculator, a position that Chris from Clickspring has been putting the lie to with his ongoing effort to reproduce the Antikythera mechanism using ancient tools and materials. We’re keen to hear what he has to say about this issue.

Speaking of questionable scientific papers, have you heard about “vegetative electron microscopy”? It’s all the rage, having been mentioned in at least 22 scientific papers recently, even though no such technique exists. Or rather, it didn’t exist until around 2017, when it popped up in a couple of Iranian scientific papers. How it came into being is a bit of a mystery, but it may have started with faulty scans of a paper from the 1950s, which had the terms “vegetative” and “electron microscopy” printed in different columns but directly across from each other. That somehow led to the terms getting glued together, possibly in one of those Iranian papers because the Farsi spelling of “vegetative” is very similar to “scanning,” a much more sensible prefix to “electron microscopy.” Once the nonsense term was created, it propagated into subsequent papers of dubious scientific provenance by authors who didn’t bother to check their references, or perhaps never existed in the first place. The wonders of our AI world never cease to amaze.

And finally, from the heart of Silicon Valley comes a tale of cyber hijinks as several crosswalks were hacked to taunt everyone’s favorite billionaires. Twelve Palo Alto crosswalks were targeted by persons unknown, who somehow managed to gain access to the voice announcement system in the crosswalks and replaced the normally helpful voice messages with deep-fake audio of Elon Musk and Mark Zuckerberg saying ridiculous but plausible things. Redwood City and Menlo Park crosswalks may have also been attacked, and soulless city officials responded by disabling the voice feature. We get why they had to do it, but as cyberattacks go, this one seems pretty harmless.

This week, the hackerverse was full of “vibe coding”. If you’re not caught up on your AI buzzwords, this is the catchy name coined by [Andrej Karpathy] that refers to basically just YOLOing it with AI coding assistants. It’s the AI-fueled version of typing in what you want to StackOverflow and picking the top answers. Only, with the current state of LLMs, it’ll probably work after a while of iterating back and forth with the machine.

It’s a tempting vision, and it probably works for a lot of simple applications, in popular languages, or generally where the ground is already well trodden. And where the stakes are low, as [Al Williams] pointed out while we were talking about vibing on the podcast. Can you imagine vibe-coded ATM software that probably gives you the right amount of money? Vibe-coding automotive ECU software?

While vibe coding seems very liberating and hands-off, it really just changes the burden of doing the coding yourself into making sure that the LLM is giving you what you want, and when it doesn’t, refining your prompts until it does. It’s more like editing and auditing code than authoring it. And while we have no doubt that a stellar programmer like [Karpathy] can verify that he’s getting what he wants, write the correct unit tests, and so on, we’re not sure it’s the panacea that is being proclaimed for folks who don’t already know how to code.

Vibe coding should probably be reserved for people who already are expert coders, and for trivial projects. Just the way you wouldn’t let grade-school kids use calculators until they’ve mastered the basics of math by themselves, you shouldn’t let junior programmers vibe code: It simultaneously demands too much knowledge to corral the LLM, while side-stepping any of the learning that would come from doing it yourself.

And then there’s the security side of vibe coding, which opens up a whole attack surface. If the LLM isn’t up to industry standards on simple things like input sanitization, your vibed code probably shouldn’t be anywhere near the Internet.

So should you be vibing? Sure! If you feel competent overseeing what [Dan] described as “the worst summer intern ever”, and the states are low, then it’s absolutely a fun way to kick the tires and see what the tools are capable of. Just go into it all with reasonable expectations.

The sky is falling. Or more specifically, it was about to fall, according to the security community this week. The MITRE Corporation came within a hair’s breadth of running out of its contract to maintain the CVE database. And admittedly, it would be a bad thing if we suddenly lost updates to the central CVE database. What’s particularly interesting is how we knew about this possibility at all. An April 15 letter sent to the CVE board warned that the specific contract that funds MITRE’s CVE and CWE work was due to expire on the 16th. This was not an official release, and it’s not clear exactly how this document was leaked.

Many people made political hay out of the apparent imminent carnage. And while there’s always an element of political maneuvering when it comes to contract renewal, it’s worth noting that it’s not unheard of for MITRE’s CVE funding to go down to the wire like this. We don’t know how many times we’ve been in this position in years past. Regardless, MITRE has spun out another non-profit, The CVE Foundation, specifically to see to the continuation of the CVE database. And at the last possible moment, CISA has announced that it has invoked an option in the existing contract, funding MITRE’s CVE work for another 11 months.

Android Automatic Reboots

Mobile devices are in their most secure state right after boot, before the user password is entered to unlock the device for the first time. Tools like Cellebrite will often work once a device has been unlocked once, but just can’t exploit a device in the first booted state. This is why Google is rolling out a feature, where Android devices that haven’t been unlocked for three days will automatically reboot.

Once a phone is unlocked, the encryption keys are stored in memory, and it only takes a lock screen bypass to have full access to the device. But before the initial unlock, the device is still encrypted, and the keys are safely stored in the hardware security module. It’s interesting that this new feature isn’t delivered as an Android OS update, but as part of the Google Play Services — the closed source libraries that run on official Android phones.

4chan

4chan has been hacked. It turns out, running ancient PHP code and out-of-date libraries on a controversial site is not a great idea. A likely exploit chain has been described, though this should be considered very unofficial at this point: Some 4chan boards allow PDF uploads, but the server didn’t properly vet those files. A PostScript file can be uploaded instead of a PDF, and an old version of Ghostscript processes it. The malicious PostScript file triggers arbitrary code execution in Ghostscript, and a SUID binary is used to elevate privileges to root.

PHP source code of the site has been leaked, and the site is still down as of the time of writing. It’s unclear how long restoration will take. Part of the fallout from this attack is the capture and release of internal discussions, pictures of the administrative tools, and even email addresses from the site’s administration.

Recall is Back

Microsoft is back at it, working to release Recall in a future Windows 11 update. You may remember our coverage of this, castigating the security failings, and pointing out that Recall managed to come across as creepy. Microsoft wisely pulled the project before rolling it out as a full release.

If you’re not familiar with the Recall concept, it’s the automated screenshotting of your Windows machine every few seconds. The screenshots are then locally indexed with an LLM, allowing for future queries to be run against the data. And once the early reviewers got over the creepy factor, it turns out that’s genuinely useful sometimes.

On top of the security hardening Microsoft has already done, this iteration of Recall is an opt-in service, with an easy pause button to temporarily disable the snapshot captures. This is definitely an improvement. Critics are still sounding the alarm, but for a much narrower problem: Recall’s snapshots will automatically extract information from security focused applications. Think about Signal’s disappearing messages feature. If you send such a message to a desktop user, that has Recall enabled, the message is likely stored in that user’s Recall database.

It seems that Microsoft has done a reasonably good job of cleaning up the Recall feature, particularly by disabling it by default. It seems like the privacy issues could be furthered addressed by giving applications and even web pages a way to opt out of Recall captures, so private messages and data aren’t accidentally captured. As Recall rolls out, do keep in mind the potential extra risks.

16,000 Symlinks

It’s been recently discovered that over 16,000 Fortinet devices are compromised with a trivial backdoor, in the form of a symlink making the root filesystem available inside the web-accessible language folder. This technique is limited to devices that have the SSL VPN enabled. That system exposes a web interface, with multiple translation options. Those translation files live in a world-accessible folder on the web interface, and it makes for the perfect place to hide a backdoor like this one. It’s not a new attack, and Fortinet believes the exploited devices have harbored this backdoor since the 2023-2024 hacking spree.

Vibes

We’re a little skeptical on the whole vibe coding thing. Our own [Tyler August] covered one of the reasons why. LLMs are likely to hallucinate package names, and vibe coders may not check closely, leading to easy typosquatting (LLMsquatting?) attacks. Figure out the likely hallucinated names, register those packages, and profit.

But what about Vibe Detections? OK, we know, letting an LLM look at system logs for potentially malicious behavior isn’t a new idea. But [Claudio Contin] demonstrates just how easy it can be, with the new EDV tool. Formally not for production use, this new gadget makes it easy to take Windows system events, and feed them into Copilot, looking for potentially malicious activity. And while it’s not perfect, it did manage to detect about 40% of the malicious tests that Windows Defender missed. It seems like LLMs are going to stick around, and this might be one of the places they actually make sense.

Bits and Bytes

Apple has pushed updates to their entire line, fixing a pair of 0-day vulnerabilities. The first is a wild vulnerability in CoreAudio, in that playing audio from a malicious audio file can lead to arbitrary code execution. The chaser is the flaw in the Pointer Authentication scheme, that Apple uses to prevent memory-related vulnerabilities. Apple has acknowledged that these flaws were used in the wild, but no further details have been released.

The Gnome desktop has an interesting problem, where the yelp help browser can be tricked into reading the contents of arbitrary filesystem files. Combined with the possibility of browser links automatically opening in yelp, this makes for a much more severe problem than one might initially think.

And for those of us following along with Google Project Zero’s deep dive into the Windows Registry, part six of that series is now available. This installment dives into actual memory structures, as well as letting us in on the history of why the Windows registry is called the hive and uses the 0xBEE0BEE0 signature. It’s bee themed, because one developer hated bees, and another developer thought it would be hilarious.