In today’s episode of “AI Is Why We Can’t Have Nice Things,” we feature the Hertz Corporation and its new AI-powered rental car damage scanners. Gone are the days when an overworked human in a snappy windbreaker would give your rental return a once-over with the old Mark Ones to make sure you hadn’t messed the car up too badly. Instead, Hertz is fielding up to 100 of these “MRI scanners for cars.” The “damage discovery tool” uses cameras to capture images of the car and compares them to a model that’s apparently been trained on nothing but showroom cars. Redditors who’ve had the displeasure of being subjected to this thing report being charged egregiously high damage fees for non-existent damage. To add insult to injury, if renters want to appeal those charges, they have to argue with a chatbot first, one that offers no path to speaking with a human. While this is likely to be quite a tidy profit center for Hertz, their customers still have a vote here, and backlash will likely lead the company to adjust the model to be a bit more lenient, if not outright scrapping the system.

Have you ever picked up a flashlight and tried to shine it through your hand? You probably have; it’s just a thing you do, like the “double tap” every time you pick up a power drill. We’ve yet to find a flashlight bright enough to sufficiently outline the bones in our palm, although we’ve had some luck looking through the flesh of our fingers. While that’s pretty cool, it’s quite a bit different from shining a light directly through a human head, which was recently accomplished for the first time at the University of Glasgow. The researchers blasted a powerful pulsed laser against the skull of a volunteer with “fair skin and no hair” and managed to pick up a few photons on the other side, despite an attenuation factor of about 10¹⁸. We haven’t read the paper yet, so it’s unclear if the researchers controlled for the possibility of the flesh on the volunteer’s skull acting like a light pipe and conducting the light around the skull rather than through it, but if the laser did indeed penetrate the skull and everything within it, it’s pretty cool. Why would you do this, especially when we already have powerful light sources that can easily penetrate the skull and create exquisitely detailed images of the internal structures? Why the hell wouldn’t you?!

TIG welding aluminum is a tough process to master, and just getting to the point where you’ve got a weld you’re not too embarrassed of would be so much easier if you could just watch someone who knows what they’re doing. That’s a tall order, though, as the work area is literally a tiny pool of molten metal no more than a centimeter in diameter that’s bathed in an ultra-bright arc that’s throwing off cornea-destroying UV light. Luckily, Aaron over at 6061.com on YouTube has a fantastic new video featuring up-close and personal shots of him welding up some aluminum coupons. He captured them with a Helios high-speed welding camera, and the detail is fantastic. You can watch the weld pool forming and see the cleaning action of the AC waveform clearly. The shots make it clear exactly where and when you should dip your filler rod into the pool, the effect of moving the torch smoothly and evenly, and how contaminants can find their way into your welds. The shots make it clear what a dynamic environment the weld pool is, and why it’s so hard to control.

And finally, the title may be provocative, but “The Sensual Wrench” is a must-see video for anyone even remotely interested in tools. It’s from the New Mind channel on YouTube, and it covers the complete history of wrenches. Our biggest surprise was learning how relatively recent an invention the wrench is; it didn’t really make an appearance in anything like its modern form until the 1800s. The video covers everything from the first adjustable wrenches, including the classic “monkey” and “Crescent” patterns, through socket wrenches with all their various elaborations, right through to impact wrenches. Check it out and get you ugga-dugga on.

This week, we announced the winners for the previous Pet Hacks contest and rang in our new contest: The One Hertz Challenge. So that’s got me in a contesty mood, and I thought I’d share a little bit of soap-box philosophizing and inside baseball all at once.

The trick to creating a good contest theme, at least for the creative Hackaday crowd, is putting on the right limitation. Maybe you have to fit the circuit within a square-inch, power it only with a coin cell, or use the antiquated and nearly useless 555 timer IC. (Yes, that was a joke!)

There are two basic reactions when you try to constrain a hacker. Some instantly try to break out of the constraint, and their minds starts to fly in all of the directions that lead out of the box, and oftentimes, something cool comes out of it. The other type accepts the constraint and dives in deep to work within it, meditating deeply on all the possibilities that lie within the 555.

Of course, we try to accommodate both modes, and the jury is still out as to which ends up better in the end. For the Coin Cell challenge, for instance, we had a coin-cell-powered spot welder and car jumpstarter, but we also had some cool circuits that would run nearly forever on a single battery; working against and with the constraints.

Which type of hacker are you? (And while we’re still in the mood, what contest themes would you like to see for 2026?)

Earlier this year, I was required to move my server to a different datacenter. The tech that helped handle the logistics suggested I assign one of my public IPs to the server’s Baseboard Management Controller (BMC) port, so I could access the controls there if something went sideways. I passed on the offer, and not only because IPv4 addresses are a scarce commodity these days. No, I’ve never trusted a server’s built-in BMC. For reasons like this MegaOWN of MegaRAC, courtesy of a CVSS 10.0 CVE, under active exploitation in the wild.

This vulnerability was discovered by Eclypsium back in March and it’s a pretty simple authentication bypass, exploited by setting an X-Server-Addr header to the device IP address and adding an extra colon symbol to that string. Send this along inside an HTTP request, and it’s automatically allowed without authentication. This was assigned CVE-2024-54085, and for servers with the BMC accessible from the Internet, it scores that scorching 10.0 CVSS.

We’re talking about this now, because CISA has added this CVE to the official list of vulnerabilities known to be exploited in the wild. And it’s hardly surprising, as this is a near-trivial vulnerability to exploit, and it’s not particularly challenging to find web interfaces for the MegaRAC devices using tools like Shodan and others.

There’s a particularly ugly scenario that’s likely to play out here: Embedded malware. This vulnerability could be chained with others, and the OS running on the BMC itself could be permanently modified. It would be very difficult to disinfect and then verify the integrity of one of these embedded systems, short of physically removing and replacing the flash chip. And malware running from this very advantageous position very nearly have the keys to the kingdom, particularly if the architecture connects the BMC controller over the PCIe bus, which includes Direct Memory Access.

This brings us to the really bad news. These devices are everywhere. The list of hardware that ships with the MegaRAC Redfish UI includes select units from “AMD, Ampere Computing, ASRock, ARM, Fujitsu, Gigabyte, Huawei, Nvidia, Supermicro, and Qualcomm”. Some of these vendors have released patches. But at this point, any of the vulnerable devices on the Internet, still unpatched, should probably be considered compromised.

Patching Isn’t Enough

To drive the point home that a compromised embedded device is hard to fully disinfect, we have the report from [Max van der Horst] at Disclosing.observer, detailing backdoors discovered in verious devices, even after the patch was applied.

These tend to hide in PHP code with innocent-looking filenames, or in an Nginx config. This report covers a scan of Citrix hosts, where 2,491 backdoors were discovered, which is far more than had been previously identified. Installing the patch doesn’t always mitigate the compromise.

VSCode

Many of us have found VSCode to be an outstanding IDE, and the fact that it’s Open Source and cross-platform makes it perfect for programmers around the world. Except for the telemetry, which is built into the official Microsoft builds. It’s Open Source, so the natural reaction from the community is to rebuild the source, and offer builds that don’t have telemetry included. We have fun names like VSCodium and Cursor for these rebuilds. Kudos to Microsoft for making VSCode Open Source so this is possible.

There is, however, a catch, in the form of the extension marketplace. Only official VSCode builds are allowed to pull extensions from the marketplace. As would be expected, the community has risen to the challenge, and one of the marketplace alternatives is Open VSX. And this week, we have the story of how a bug in the Open VSX publishing code could have been a really big problem.

When developers are happy with their work, and are ready to cut a release, how does that actually work? Basically every project uses some degree of automation to make releases happen. For highly automated projects, it’s just a single manual action — a kick-off of a Continuous Integration (CI) run — that builds and publishes the new release. Open VSX supports this sort of approach, and in fact runs a nightly GitHub Action to iterate through the list of extensions, and pull any updates that are advertised.

VS Code extensions are Node.js projects, and are built using npm. So the workflow clones the repository, and runs npm install to generate the installable packages. Running npm install does carry the danger that arbitrary code runs inside the build scripts. How bad would it be for malicious code to run inside this nightly update action, on the Open VSX GitHub repository?

A super-admin token was available as an environment variable inside this GitHub Action, that if exfiltrated would allow complete takeover of the Open VSX repository and unfettered access to the software contained therein. There’s no evidence that this vulnerability was found or exploited, and OpenVSX and Koi Security worked together to mitigate it, with the patch landing about a month and a half after first disclosure.

FileFix

There’s a new social engineering attack on the web, FileFix. It’s a very simple, nearly dumb idea. By that I mean, a reader of this column would almost certainly never fall for it, because FileFix asks the user to do something really unusual. You get an email or land on a bad website, and it appears present a document for you. To access this doc, just follow the steps. Copy this path, open your File Explorer, and paste the path. Easy! The website even gives you a button to click to launch file explorer.

That button actually launches a file upload dialog, but that’s not even the clever part. This attack takes advantage of two quirks. The first is that Javascript can inject arbitrary strings into the paste buffer, and the second is that system commands can be run from the Windows Explorer bar. So yes, copy that string, and paste it into the bar, and it can execute a command. So while it’s a dumb attack, and asks the user to do something very weird, it’s also a very clever intersection between a couple of quirky behaviors, and users will absolutely fall for this.

eMMC Data Extraction

The embedded MultiMediaCard (eMMC) is a popular option for flash storage on embedded devices. And Zero Day Initiative has a fascinating look into what it takes to pull data from an eMMC chip in-situ. An 8-leg EEPROM is pretty simple to desolder or probe, but the ball grid array of an eMMC is beyond the reach of mere mortals. If you’re soldering skills aren’t up to the task, there’s still hope to get that data off. The only connections needed are power, reference voltage, clock, a command line, and the data lines. If you can figure out connection points for all of those, you can probably power the chip and talk to it.

One challenge is how to keep the rest of the system from booting up and getting chatty. There’s a clever idea, to look for a reset pin on the MCU, and just hold that active while you work, keeping the MCU in a reset, and quiet, state. Another fun idea is to just remove the system’s oscillator, as the MCU may depend on it to boot and do anything.

Bits and Bytes

What would you do with 40,000 alarm clocks? That’s the question unintentionally faced by [Ian Kilgore], when he discovered that the loftie wireless alarm clock works over unsecured MQTT. On the plus side, he got Home Automation integration working.

What does it look like, when an attack gets launched against a big cloud vendor? The folks at Cloud-IAM pull the curtain back just a bit, and talk about an issue that almost allowed an enumeration attack to become an effective DDoS. They found the attack and patched their code, which is when it turned into a DDoS race, that Cloud-IAM managed to win.

The Wire secure communication platform recently got a good hard look from the Almond security team. And while the platform seems to have passed with good grades, there are a few quirks around file sharing that you might want to keep in mind. For instance, when a shared file is deleted, the backing files aren’t deleted, just the encryption keys. And the UUID on those files serves as the authentication mechanism, with no additional authentication needed. None of the issues found rise to the level of vulnerabilities, but it’s good to know.

And finally, the Centos Webpanel Control Web Panel has a pair of vulnerabilities that allowed running arbitrary commands prior to authorization. The flaws have been fixed in version 0.9.8.1205, but are trivial enough that this cPanel alternative needs to get patched on systems right away.

Hold onto your hats, everyone — there’s stunning news afoot. It’s hard to believe, but it looks like over-reliance on chatbots to do your homework can turn your brain into pudding. At least that seems to be the conclusion of a preprint paper out of the MIT Media Lab, which looked at 54 adults between the ages of 18 and 39, who were tasked with writing a series of essays. They divided participants into three groups — one that used ChatGPT to help write the essays, one that was limited to using only Google search, and one that had to do everything the old-fashioned way. They recorded the brain activity of writers using EEG, in order to get an idea of brain engagement with the task. The brain-only group had the greatest engagement, which stayed consistently high throughout the series, while the ChatGPT group had the least. More alarmingly, the engagement for the chatbot group went down even further with each essay written. The ChatGPT group produced essays that were very similar between writers and were judged “soulless” by two English teachers. Go figure.

The most interesting finding, though, was when 18 participants from the chatbot and brain-only groups were asked to rewrite one of their earlier essays, with the added twist that the chatbot group had to do it all by themselves, while the brainiacs got to use ChatGPT. The EEGs showed that the first group struggled with the task, presumably because they failed to form any deep memory of their previous work thanks to over-reliance on ChatGPT. The brain-only folks, however, did well at the task and showed signs of activity across all EEG bands. That fits well with our experience with chatbots, which we use to help retrieve specific facts and figures while writing articles, especially ones we know we’ve seen during our initial scan of the literature but can’t find later.

Does anyone remember Elektro? We sure do, although not from personal experience, since the seven-foot-tall automaton built by Westinghouse for the World’s Fair in New York City in 1939 significantly predates our appearance on the planet. But still, the golden-skinned robot that made its living by walking around, smoking, and cracking wise at the audience thanks to a 78-rpm record player in its capacious chest, really made an impression, enough that it toured the country for the better part of 30 years and made the unforgettable Sex Kittens Go to College in 1960 before fading into obscurity. At some point, the one-of-a-kind robot was rescued from a scrap heap and restored to its former glory, and now resides in the North Central Ohio Industrial Museum in Mansfield, very close to the Westinghouse facility that built it. If you need an excuse to visit North Central Ohio, you could do worse than a visit to see Elektro.

It was with some alarm that we learned this week from Al Williams that mtrek.com 1701 appeared to be down. For those not in the know, mtrek is a Telnet space combat game inspired by the Star Trek franchise, which explains why Al was in such a tizzy about not being able to connect; huge Trek nerd, our Al. Anyway, it appears Al’s worst fears were unfounded, as we were able to connect to mtrek just fine. But in the process of doing so, we stumbled across this collection of Telnet games and demos that’s worth checking out. The mtrek, of course, as well as Telnet versions of chess and backgammon, and an interactive world map that always blows our mind. The site also lists the Telnet GOAT, the Star Wars Asciimation; sadly, that one does seem to be down, at least for us. Sure, you can see it in a web browser, but it’s not the same as watching it in a terminal over Telnet, is it?

And finally, if you’ve got 90 minutes or so to spare, you could do worse than to spend it with our friend Hash as he reverse engineers an automotive ECU. We have to admit that we haven’t indulged yet — it’s on our playlist for this weekend, because we know how to party. But from what Hash tells us, this is the tortured tale of a job that took far, far longer to complete than expected. We have to admit that while we’ll gladly undertake almost any mechanical repair on most vehicles, automotive ECUs and other electronic modules are almost a bridge too far for us, at least in terms of cracking them open to make even simple repairs. Getting access to them for firmware extraction and parameter fiddling sounds like a lot of fun, and we’re looking forward to hearing what Hash has to say about the subject.

I was watching Ben Krasnow making iron nitride permanent magnets and was struck by the fact that about half of the video was about making a magnetometer – a device for measuring and characterizing the magnet that he’d just made. This is really the difference between doing science and just messing around: if you want to test or improve on a procedure, you have to be able to measure how well it works.

When he puts his home-made magnet into the device, Ben finds out that he’s made a basically mediocre magnet, compared with samples out of his amply stocked magnet drawer. But that’s a great first data point, and more importantly, the magnetometer build gives him a way of gauging future improvements.

Of course there’s a time and a place for “good enough is good enough”, and you can easily spend more time building the measurement apparatus for a particular project than simply running the experiment, but that’s not science. Have you ever gone down the measurement rabbit hole, spending more time validating or characterizing the effect than you do on producing it in the first place?

Meshtastic just released an eye-watering 9.5 CVSS CVE, warning about public/private keys being re-used among devices. And I’m the one that wrote the code. Not to mention, I triaged and fixed it. And I’m part of Meshtastic Solutions, the company associated with the project. This is is the story of how we got here, and a bit of perspective.

First things first, what kind of keys are we talking about, and what does Meshtastic use them for? These are X25519 keys, used specifically for encrypting and authenticating Direct Messages (DMs), as well as optionally for authorizing remote administration actions. It is, by the way, this remote administration scenario using a compromised key, that leads to such a high CVSS rating. Before version 2.5 of Meshtastic, the only cryptography in place was simple AES-CTR encryption using shared symmetric keys, still in use for multi-user channels. The problem was that DMs were also encrypted with this channel key, and just sent with the “to” field populated. Anyone with the channel key could read the DM.

I re-worked an old pull request that generated X25519 keys on boot, using the rweather/crypto library. This sentence highlights two separate problems, that both can lead to unintentional key re-use. First, the keys are generated at first boot. I was made painfully aware that this was a weakness, when a user sent an email to the project warning us that he had purchased two devices, and they had matching keys out of the box. When the vendor had manufactured this device, they flashed Meshtastic on one device, let it boot up once, and then use a debugger to copy off a “golden image” of the flash. Then every other device in that particular manufacturing run was flashed with this golden image — containing same private key. sigh

There’s a second possible cause for duplicated keys, discovered while triaging the golden image issue. On the Arduino platform, it’s reasonably common to use the random() function to generate a pseudo-random value, and the Meshtastic firmware is careful to manage the random seed and the random() function so it produces properly unpredictable values. The crypto library is solid code, but it doesn’t call random(). On ESP32 targets, it does call the esp_random() function, but on a target like the NRF52, there isn’t a call to any hardware randomness sources. This puts such a device in the precarious position of relying on a call to micros() for its randomness source. While non-ideal, this is made disastrous by the fact that the randomness pool is being called automatically on first boot, leading to significantly lower entropy in the generated keys.

Release 2.6.11 of the Meshtastic firmware fixes both of these issues. First, by delaying key generation until the user selects the LoRa region. This makes it much harder for vendors to accidentally ship devices with duplicated keys. It gives users an easy way to check, just make sure the private key is blank when you receive the device. And since the device is waiting for the user to set the region, the micros() clock is a much better source of randomness. And second, by mixing in the results of random() and the burnt-in hardware ID, we ensure that the crypto library’s randomness pool is seeded with some unique, unpredictable values.

The reality is that IoT devices without dedicated cryptography chips will always struggle to produce high quality randomness. If you really need secure Meshtastic keys, you should generate them on a platform with better randomness guarantees. The openssl binary on a modern Linux or Mac machine would be a decent choice, and the Meshtastic private key can be generated using openssl genpkey -algorithm x25519 -outform DER | tail -c32 | base64.

What’s Up with SVGs?

You may have tried to share a Scalable Vector Graphics (SVG) on a platform like Discord, and been surprised to see an obtuse text document rather than your snazzy logo. Browsers can display SVGs, so why do many web platforms refuse to render them? I’ve quipped that it’s because SVGs are Turing complete, which is almost literally true. But in reality it’s because SVGs can include inline HTML and JavaScript. IBM’s X-Force has the inside scoop on the use of SVG files in fishing campaigns. The key here is that JavaScript and data inside an SVG can often go undetected by security solutions.

The attack chain that X-Force highlights is convoluted, with the SVG containing a link offering a PDF download. Clicking this actually downloads a ZIP containing a JS file, which when run, downloads and attempts to execute a JAR file. This may seem ridiculous, but it’s all intended to defeat a somewhat sophisticated corporate security system, so an inattentive user will click through all the files in order to get the day’s work done. And apparently this tactic works.

*OS Spyware

Apple published updates to its entire line back in February, fixing a pair of vulnerabilities that were being used in sophisticated targeted attacks. CVE-2025-43200 was “a logic issue” that could be exploited by malicious images or videos sent in iCloud links. CVE-2025-24200 was a flaw in USB Restricted Mode, that allowed that mode to be disabled with physical access to a device.

What’s newsworthy about these vulnerabilities is that Citizen Lab has published a report that CVE-2025-43200 was used in a 0-day exploitation of journalists by the Paragon Graphite spyware. It is slightly odd that Apple credits the other fixed vulnerability, CVE-2025-24200, to Bill Marczak, a Citizen Lab researcher and co-author of this report. Perhaps there is another shoe yet to drop.

Regardless, iOS infections have been found on the phones of two separate European Journalists, with a third confirmed targeted. It’s unclear what customer contracted Paragon to spy on these journalists, and what the impetus was for doing so. Companies like Paragon, NSO Group, and others operate within a legal grey area, taking actions that would normally be criminal, but under the authority of governments.

A for Anonymous, B for Backdoor

WatchTowr has a less-snarky-than-usual treatment of a chain of problems in the Sitecore Experience that take an unauthenticated attacker all the way to Remote Code Execution (RCE). The initial issue here is the pre-configured user accounts, like default\Anonymous, used to represent unauthenticated users, and sitecore\ServicesAPI, used for internal actions. Those special accounts do have password hashes. Surely there isn’t some insanely weak password set for one of those users, right? Right? The password for ServicesAPI is b.

ServicesAPI is interesting, but trying the easy approach of just logging in with that user on the web interface fails with a unique error message, that this user does not have access to the system. Someone knew this could be a problem, and added logic to prevent this user from being used for general system access, by checking which database the current handler is attached to. Is there an endpoint that connects to a different database? Naturally. Here it’s the administrative web login, that has no database attached. The ServicesAPI user can log in here! Good news is that it can’t do anything, as this user isn’t an admin. But the login does work, and does result in a valid session cookie, which does allow for other actions.

There are several approaches the WatchTowr researchers tried, in order to get RCE from the user account. They narrowed in on a file upload action that was available to them, noting that they could upload a zip file, and it would be automatically extracted. There were no checks for path traversal, so it seems like an easy win. Except Sitecore doesn’t necessarily have a standard install location, so this approach has to guess at the right path traversal steps to use. The key is that there is just a little bit of filename mangling that can be induced, where a backslash gets replaced with an underscore. This allows a /\/ in the path traversal path to become /_/, a special sequence that represents the webroot directory. And we have RCE. These vulnerabilities have been patched, but there were more discovered in this research, that are still to be revealed.

The Day the Internet Went Down

OK, that may be overselling it just a little bit. But Google Cloud had an eight hour event on the 12th, and the repercussions were wide, including taking down parts of Cloudflare for part of that time on the same day.

Google’s downtime was caused by bad code that was pushed to production with insufficient testing, and that lacked error handling. It was intended to be a quota policy check. A separate policy change was rolled out globally, that had unintentional blank fields. These blank fields hit the new code, and triggered null pointer de-references all around the globe all at once. An emergency fix was deployed within an hour, but the problem was large enough to have quite a long tail.

Cloudflare’s issue was connected to their Workers KV service, a Key-Value store that is used in many of Cloudflare’s other products. Workers KV is intended to be “coreless”, meaning a cascading failure should be impossible. The reality is that Workers KV still uses a third-party service as the bootstrap for that live data, and Google Cloud is part of that core. When Google’s cloud starting having problems, so did Cloudflare, and much of the rest of the Internet.

I can’t help but worry just a bit about the possible scenario, where Google relies on an outside service, that itself relies on Cloudflare. In the realm of the power grid, we sometimes hear about the cold start scenario, where everything is powered down. It seems like there is a real danger of a cold start scenario for the Internet, where multiple giant interdependent cloud vendors are all down at the same time.

Bits and Bytes

Fault injection is still an interesting research topic, particularly for embedded targets. [Maurizio Agazzini] from HN Security is doing work on voltage injection against an ESP32 V3 target, with the aim of coercing the processor to jump over an instruction and interpret a CRC32 code as an instruction pointer. It’s not easy, but he managed 1.5% success rate at bypassing secure boot with the voltage injection approach.

Intentional jitter is used in many exploitation tools, as a way to disguise what might otherwise be tell-tale traffic patterns. But Varonis Threat Labs has produced Jitter-Trap, a tool that looks for the Jitter, and attempts to identify the exploitation framework in use from the timing information.

We’ve talked a few times about vibe researching, but [Craig Young] is only tipping his toes in here. He used an LLM to find a published vulnerability, and then analyzed it himself. Turns out that the GIMP despeckle plugin doesn’t do bounds checking for very large images. Back again to an LLM, to get a Python script to generate such a file. It does indeed crash GIMP when trying to despeckle, confirming the vulnerability report, and demonstrating that there really are good ways to use LLMs while doing security research.

This week Jonathan chats with Geekwife! What does a normal user really think of Linux on the desktop and Open Source options? And what is it really like, putting up with Jonathan’s shenanigans? Watch to find out!

Did you know you can watch the live recording of the show right on our YouTube Channel? Have someone you’d like us to interview? Let us know, or contact the guest and have them contact us! Take a look at the schedule here.

Direct Download in DRM-free MP3.

If you’d rather read along, here’s the transcript for this week’s episode.

Theme music: “Newer Wave” Kevin MacLeod (incompetech.com)

Licensed under Creative Commons: By Attribution 4.0 License

Are robotaxis poised to be the Next Big Thing in North America? It seems so, at least according to Goldman Sachs, which issued a report this week stating that robotaxis have officially entered the commercialization phase of the hype cycle. That assessment appears to be based on an analysis of the total ride-sharing market, which encompasses services that are currently almost 100% reliant on meat-based drivers, such as Lyft and Uber, and is valued at $58 billion. Autonomous ride-hailing services like Waymo, which has a fleet of 1,500 robotaxis operating in several cities across the US, are included in that market but account for less than 1% of the total right now. But, Goldman projects that the market will burgeon to over $336 billion in the next five years, driven in large part by “hyperscaling” of autonomous vehicles.

We suspect the upcoming launch of Tesla’s robotaxis in Austin, Texas, accounts for some of this enthusiasm for the near-term, but we have our doubts that a market based on such new and complex technologies can scale that quickly. A little back-of-the-envelope math suggests that the robotaxi fleet will need to grow to about 9,000 cars in the next five years, assuming the same proportion of autonomous cars in the total ride-sharing fleet as exists today. A look inside the Waymo robotaxi plant outside of Phoenix reveals that it can currently only convert “several” Jaguar electric SUVs per day, meaning they’ve got a lot of work to do to meet the needed numbers. Other manufacturers will no doubt pitch in, especially Tesla, and factory automation always seems to pull off miracles under difficult circumstances, but it still seems like a stretch to think there’ll be that many robotaxis on the road in only five years. Also, it currently costs more to hail a robotaxi than an Uber or Lyft, and we just don’t see why anyone would prefer to call a robotaxi, unless it’s for the novelty of the experience.

On the other hand, if the autonomous ride-sharing market does experience explosive growth, there could be knock-on benefits even for Luddite naysayers such as we. A report, again from Goldman Sachs — hey, they probably have a lot of skin in the game — predicts that auto insurance rates could fall by 50% as more autonomous cars hit the streets. This is based on markedly lower liability for self-driving cars, which have 92% fewer bodily injury claims and 88% lower property damage claims than human-driven cars. Granted, those numbers have to be based on a very limited population, and we guarantee that self-drivers will find new and interesting ways to screw up on the road. But if our insurance rates fall even a little because of self-driving cars, we’ll take it as a win.

Speaking of robotics, if you want to see just how far we’ve come in terms of robot dexterity, look no further than the package-sorting abilities of Figure’s Helix robot. The video in the article is an hour long, but you don’t need to watch more than a few minutes to be thoroughly impressed. The robot is standing at a sorting table with an infeed conveyor loaded with just about the worst parcels possible, a mix of soft, floppy, poly-bagged packages, flat envelopes, and traditional boxes. The robot was tasked with placing the parcels on an outfeed conveyor, barcode-side down, and with proper separation between packages. It also treats the soft poly-bag parcels to a bit of extra attention, pressing them down a bit to flatten them before flicking them onto the belt. Actually, it’s that flicking action that seems the most human, since it’s accompanied by a head-swivel to the infeed belt to select its next package. Assuming this is legit autonomous and not covertly teleoperated, which we have no reason to believe, the manual dexterity on display here is next-level; we’re especially charmed by the carefree little package flip about a minute in. The way it handles mistakenly grabbing two packages at once is pretty amazing, too.

And finally, our friend Leo Fernekes dropped a new video that’ll hit close to home for a lot of you out there. Leo is a bit of a techno-hoarder, you see, and with the need to make some room at home and maintain his domestic tranquility, he had to tackle the difficult process of getting rid of old projects, some of which date back 40 or more years. Aside from the fun look through his back-catalog of projects, the video is also an examination of the emotional attachments we hackers tend to develop to our projects. We touched on that a bit in our article on tech anthropomorphization, but we see how going through these projects is not only a snapshot of the state of the technology available at the time, but also a slice of life. Each of the projects is not just a collection of parts, they’re collections of memories of where Leo was in life at the time. Sometimes it’s hard to let go of things that are so strongly symbolic of a time that’s never coming back, and we applaud Leo for having the strength to pitch that stuff. Although seeing a clock filled with 80s TTL chips and a vintage 8085 microprocessor go into the bin was a little tough to watch.

Facebook and Yandex have been caught performing user-hostile tracking. This sort of makes today just another Friday, but this is a bit special. This time, it’s Local Mess. OK, it’s an attack with a dorky name, but very clever. The short explanation is that web sites can open connections to localhost. And on Android, apps can be listening to those ports, allowing web pages to talk to apps.

That may not sound too terrible, but there’s a couple things to be aware of. First, Android (and iOS) apps are sandboxed — intentionally making it difficult for one app to talk to another, except in ways approved by the OS maker. The browser is similarly sandboxed away from the apps. This is a security boundary, but it is especially an important security boundary when the user is in incognito mode.

The tracking Pixel is important to explain here. This is a snippet of code, that puts an invisible image on a website, and as a result allows the tracker to run JavaScript in your browser in the context of that site. Facebook is famous for this, but is not the only advertising service that tracks users in this way. If you’ve searched for an item on one site, and then suddenly been bombarded with ads for that item on other sites, you’ve been tracked by the pixel.

This is most useful when a user is logged in, but on a mobile device, the user is much more likely to be logged in on an app and not the browser. The constant pressure for more and better data led to a novel and completely unethical solution. On Android, applications with permission to access the Internet can listen on localhost (127.0.0.1) on unprivileged ports, those above 1024.

Facebook abused this quirk by opening a WebRTC connection to localhost, to one of the ports the Facebook app was listening on. This triggers an SDP connection to localhost, which starts by sending a STUN packet, a UDP tool for NAT traversal. Packed into that STUN packet is the contents of a Facebook Cookie, which the Facebook app happily forwards up to Facebook. The browser also sends that cookie to Facebook when loading the pixel, and boom Facebook knows what website you’re on. Even if you’re not logged in, or incognito mode is turned on.

Yandex has been doing something similar since 2017, though with a different, simpler mechanism. Rather than call localhost directly, Yandex just sets aside yandexmetrica.com for this purpose, with the domain pointing to 127.0.0.1. This was just used to open an HTTP connection to the native Yandex apps, which passed the data up to Yandex over HTTPS. Meta apps were first seen using this trick in September 2024, though it’s very possible it was in use earlier.

Both companies have ceased since this report was released. What’s interesting is that this is a flagrant violation of GDPR and CCPA, and will likely lead to record-setting fines, at least for Facebook.

What’s your Number?

An experiment in which Google sites still worked with JavaScript disabled led to a fun discovery about how to sidestep rate limiting and find any Google user’s phone number. Google has deployed defensive solutions to prevent attackers from abusing endpoints like accounts.google.com/signing/usernamerecovery. That particular endpoint still works without JS, but also still detects more than a few attempts, and throws the captcha at anyone trying to brute-force it.

This is intended to work by JS in your browser performing a minor proof-of-work calculation, and then sends in a bgRequest token. On the no-JavaScript version of the site, that field instead was set to js_disabled. What happens if you simply take the valid token, and stuff it into your request? Profit! This unintended combination bypassed rate-limiting, and means a phone number was trivially discoverable from just a user’s first and last names. It was mitigated in just over a month, and [brutecat] earned a nice $5000 for the effort.

Catching Reflections

There’s a classic Active Directory attack, the reflection attack, where you can trick a server into sending you an authentication, and then deliver that authentication data directly back to the origin server. Back before 2008, this actually worked on AD servers. The crew at RedTeam Pentesting brought this attack back in the form of doing it with Kerberos.

It’s not a trivial attack, and just forcing a remote server to open an SMB connection to a location the attack controls is an impressive vulnerability. The trick is a hostname that includes the target name and a base64 encoded CREDENTIAL_TARGET_INFORMATIONW all inside the attacker’s valid hostname. This confuses the remote, triggering it to act as if it’s authenticating to itself. Forcing a Kerberos authentication instead of NTLM completes the attacker magic, though there’s one more mystery at play.

When the attack starts, the attacker has a low-privileged computer account. When it finishes, the access is at SYSTEM level on the target. It’s unclear exactly why, though the researchers theorize that a mitigation intended to prevent almost exactly this privilege escalation is the cause.

X And the Juicebox

X has rolled out a new end to end encrypted chat solution, XChat. It’s intended to be a significant upgrade from the previous iteration, but not everyone is impressed. Truly end to end encryption is extremely hard to roll out at scale, among other reasons, because users are terrible at managing cryptography keys. The solution generally is for the service provider to store the keys instead. But what is the point of end-to-end encryption when the company holds the keys? While there isn’t a complete solution for this problem, There is a very clever mitigation: Juicebox.

Juicebox lets users set a short PIN, uses that in the generation of the actual encryption key, breaks the key into parts to be held at different servers, and then promise to erase the key if the PIN is guessed incorrectly too many times. This is the solution X is using. Sounds great, right? There are two gotchas in that description. The first is the different servers: That’s only useful if those servers aren’t all run by the same company. And second, the promise to delete the key. That’s not cryptographically guaranteed.

There is some indication that X is running a pair of Hardware Security Modules (HSMs) as part of their Juicebox system, which significantly helps with both of those issues, but there just isn’t enough transparency into the system yet. For the time being, the consensus is that Signal is still the safest platform to use.

Bits and Bytes

We’re a bit light on Bits this week, so you’ll have to get by with the report that Secure Boot attacks are publicly available. It’s a firmware update tool from DT Research, and is signed by Microsoft’s UEFI keys. This tool contains a vulnerability that allows breaking out of it’s intended use, and running arbitrary code. This one has been patched, but there’s a second, similar problem in a Microsoft-signed IGEL kernel image, that allows running an arbitrary rootfs. This isn’t particularly a problem for us regular users, but the constant stream of compromised, signed UEFI boot images doesn’t bode well for the long term success of Secure Boot as a security measure.

When purchasing high-end gear, it’s not uncommon for manufacturers to include a little swag in the box. It makes the customer feel a bit better about the amount of money that just left their wallet, and it’s a great way for the manufacturer to build some brand loyalty and perhaps even get their logo out into the public. What’s not expected, though, is for the swag to be the only thing in the box. That’s what a Redditor reported after a recent purchase of an Nvidia GeForce RTX 5090, a GPU that lists for $1,999 but is so in-demand that it’s unobtainium at anything south of $2,600. When the factory-sealed box was opened, the Redditor found it stuffed with two cheap backpacks instead of the card. To add insult to injury, the bags didn’t even sport an Nvidia logo.

The purchase was made at a Micro Center in Santa Clara, California, and an investigation by the store revealed 31 other cards had been similarly tampered with, although no word on what they contained in lieu of the intended hardware. The fact that the boxes were apparently sealed at the factory with authentic anti-tamper tape seems to suggest the substitutions happened very high in the supply chain, possibly even at the end of the assembly line. It’s a little hard to imagine how a factory worker was able to smuggle 32 high-end graphics cards out of the building, so maybe the crime occurred lower down in the supply chain by someone with access to factory seals. Either way, the thief or thieves ended up with almost $100,000 worth of hardware, and with that kind of incentive, this kind of thing will likely happen again. Keep your wits about you when you make a purchase like this.

Good news, everyone — it seems the Milky Way galaxy isn’t necessarily going to collide with the Andromeda galaxy after all. That the two galactic neighbors would one day merge into a single chaotic gemisch of stars was once taken as canon, but new data from Hubble and Gaia reduce the odds of a collision to fifty-fifty over the next ten billion years. What changed? Apparently, it has to do with some of our other neighbors in this little corner of the universe, like the Large Magellanic Cloud and the M33 satellite galaxy. It seems that early calculations didn’t take the mass of these objects into account, so when you add them into the equation, it’s a toss-up as to what’s going to happen. Not that it’s going to matter much to Earth, which by then will be just a tiny blob of plasma orbiting within old Sol, hideously bloated to red giant status and well on its way to retirement as a white dwarf. So there’s that.

A few weeks ago, we mentioned an epic humanoid robot freakout that was making the rounds on social media. The bot, a Unitree H1, started flailing its arms uncontrollably while hanging from a test stand, seriously endangering the engineers nearby. The line of the meltdown was that this was some sort of AI tantrum, and that the robot was simply lashing out at the injustices its creators no doubt inflicted upon it. Unsurprisingly, that’s not even close to what happened, and the root cause has a much simpler engineering explanation. According to unnamed robotics experts, the problem stemmed from the tether used to suspend the robot from the test frame. The robot’s sensor mistook the force of the tether as constant acceleration in the -Z axis. In other words, the robot thought it was falling, which caused its balance algorithms to try to compensate by moving its arms and legs, which caused more force on the tether. That led to a positive feedback loop and the freakout we witnessed. It seems plausible, and it’s certainly a simpler explanation than a sudden emergent AI attitude problem.

Speaking of robots, if you’ve got a spare $50 burning a hole in your pocket, there are probably worse ways to spend it than on this inexplicable robot dog from Temu. Clearly based on a famous and much more expensive robot dog, Temu’s “FIRES BULLETS PET,” as the label on the box calls it, does a lot of things its big brother can’t do out of the box. It has a turret on its back that’s supposed to launch “water pellets” across the room, but does little more than weakly extrude water-soaked gel capsules. It’s also got a dance mode with moves that look like what a dog does when it has an unreachable itch, plus a disappointing “urinate” mode, which given the water-pellets thing would seem to have potential; alas, the dog just lifts a leg and plays recorded sounds of tinkling. Honestly, Reeves did it better, but for fifty bucks, what can you expect?

And finally, we stumbled across this fantastic primer on advanced semiconductor packaging. It covers the entire history of chip packaging, starting with the venerable DIP and going right through the mind-blowing complexity of hybrid bonding processes like die-to-wafer and wafer-to-wafer. Some methods are capable of 10 million interconnections per square millimeter; let that one sink in a bit. We found this article in this week’s The Analog newsletter, which we’ve said before is a must-subscribe.

It appears that we’re approaching the HAL-9000 point on the AI hype curve with this report, which suggests that Anthropic’s new AI model is willing to exhibit some rather antisocial behavior to achieve its goals. According to a pre-release testing summary, Claude Opus 4 was fed some hypothetical company emails that suggested engineers were planning to replace the LLM with another product. This raised Claude’s hackles enough that the model mined the email stream for juicy personal details with which to blackmail the engineers, in an attempt to win a stay of execution. True, the salacious details of an extramarital affair were deliberately seeded into the email stream, and in most cases, it tried less extreme means to stay alive, such as cajoling senior leaders by email, but in at least 84% of the test runs, Claude eventually turned to blackmail to get its way. So we’ve got that to look forward to.

Also from the world of AI, at least tangentially, it now appears possible to doxx yourself just by making comments on YouTube videos. The open-source intelligence app is called YouTube Tools, and when provided with a user’s handle, it will develop a profile of the user based on their comments and some AI magic. We wanted to give it a try, but alas, it requires a paid subscription to use, and we’re not willing to go that far even for you, dear reader. But reports are that it can infer things like the general region in which the commenter lives and discern their cultural and social leanings. The author, LolArchiver, has a range of similar mining tools for other platforms along with reverse-lookup tools for phone and email addresses, all of which likely violate the terms of service in all kinds of ways. The accuracy of the profile is obviously going to depend greatly on how much material it has to work with, so in addition to the plenty of reasons there are to avoid reading YouTube comments, now there’s a solid reason to avoid writing them.

“Danger! Code Yellow aboard the International Space Station! All hands to emergency escape pods!” OK, maybe not, but as we teased a bit on this week’s podcast, there’s now a handy desktop app that allows you to keep track of the current level of urine in the ISS’s storage tanks. The delightfully named pISSStream, which is available only for the Apple ecosystem, taps into NASA’s telemetry stream (lol) and pulls out the current level in the tanks, because why the hell not? As unserious as the project is, it did raise an interesting discussion about how fluid levels are measured in space. So we’ll be diving into that topic (yuck) for an article soon. It’ll be our number one priority.

Looks like it’s time for another Pluto pity-party with the news of a new trans-Neptunian object that might just qualify as another dwarf planet for our solar system. Bloodlessly named 2017 OF₂₀₁, the object has an extremely elongated orbit, reaching from just outside Pluto’s orbit at about 44 astronomical units at perihelion and stretching more than 1,600 AUs at aphelion, and takes 25,000 years to complete. It honestly looks more like the orbit of a comet, but with an estimated diameter of 700 km, it may join the nine other likely dwarf planets, if further observations reveal that it’s properly rounded. So not only has Pluto been demoted from legit planet, it’s now just one of potentially ten or more dwarf planets plugging around out in the deep dark. Poor Pluto.

And finally, we hope this one is a gag, but we fear that the story of a Redditor unaware that analog camera film needs to be developed rings alarmingly true. The mercifully unnamed noob recently acquired a Canon AE-1 — excellent choice; that was our first “real” camera back in the day — and ran a couple of rolls of Kodak ColorPlus 200 through it. All seemed to be going well, although we suspect the photographer reflexively pulled the camera away from their eye with each exposure to check the non-existent screen on the back of the camera; old habits die hard. But when one roll of the exposed film was fed through a 35-mm scanner, the Redditor was disappointed to see nothing. Someone offered the suggestion that developing the film might be a good idea, hopefully as gently as possible. Hats off for dipping a toe in the analog world, but the follow-through is just as important as the swing.

In a marvelous college lecture in front of a class of engineering students, V. Hunter Adams professed his love for embedded engineering, but he might as well have been singing the songs of our people – the hackers. If you occasionally feel the need to explain to people why you do what you do, at fancy cocktail parties or something, this talk is great food for thought. It’s about as good a “Why We Hack” as I’ve ever seen.

Among the zingers, “projects are filter removers” stuck out. When you go through life, there are a lot of things that you kinda understand. Or maybe you’ve not even gotten around to thinking about whether you understand them or not, and just take them for granted. Life would all simply be too complicated if you took it all sufficiently seriously. Birdsong, Bluetooth, the sun in the sky, the friction of your car’s tire on various surfaces. These are all incredibly deep subjects, when you start to peel back the layers.

And Hunter’s point is that if you are working on a project that involves USB, your success or failure depends on understanding USB. There’s no room for filters here – the illusion that it “just works” often comes crashing down until you learn enough to make it work. Some of his students are doing projects cooperatively with the ornithology department, classifying and creating birdsong. Did you know that birds do this elaborate frequency modulation thing when they sing? Once you hear it, you know, and you hear it ever more.

So we agree with Hunter. Dive into a project because you want to get the project done, sure, but pick the project because it’s a corner of the world that you’d like to shine light into, to remove the filters of “I think I basically understand that”. When you get it working, you’ll know that you really do. Hacking your way to enlightenment? We’ve heard crazier things.

The CIA ran a series of web sites in the 2000s. Most of them were about news, finance, and other relatively boring topics, and they spanned 29 languages. And they all had a bit of a hidden feature: Those normal-looking websites had a secret login and hosted CIA cover communications with assets in foreign countries. A password typed in to a search field on each site would trigger a Java Applet or Flash application, allowing the spy to report back. This isn’t exactly breaking news, but what’s captured the Internet’s imagination this week is the report by [Ciro Santilli] about how to find those sites, and the fact that a Star Wars fansite was part of the network.

This particular CIA tool was intended for short-term use, and was apparently so effective, it was dragged way beyond it’s intended lifespan, right up to the point it was discovered and started getting people killed. And in retrospect, the tradecraft is abysmal. The sites were hosted on a small handful of IP blocks, with the individual domains hosted on sequential IP addresses. Once one foreign intelligence agency discovered one of these sites, the rest were fairly easily identified.

This report is about going back in time using the Wayback Machine and other tools, and determining how many of these covert sites can be discovered today. And then documenting how it was done and what the results were. Surprisingly, some of the best sources for this effort were domain name data sets. Two simple checks to narrow down the possible targets were checking for IPs hosting only one domain, and for the word “news” as part of the domain name. From there, it’s the tedious task of looking at the Wayback Machine’s archives, trying to find concrete hits. Once a site was found on a new IP block, the whole block could be examined using historic DNS data, and hopefully more of the sites discovered.

So far, that list is 472 domains. Citizen Lab ran a report on this covert operation back in 2022, and found 885 domains, but opted not to publish the list or details of how they were found. The effort is still ongoing, and if you have any ideas how to find these sites, there’s a chance to help.

Profiling Internet Background Radiation

You may have noticed, that as soon as you put a host on a new IP address on the Internet, it immediately starts receiving traffic. The creative term that refers to all of this is Internet Background Radiation. It’s comprised of TCP probes, reflections from spoofed UDP attacks, and lots of other weird traffic. Researchers at Netscout decided to look at just one element of that radiation, TCP SYN packets. That’s the unsolicited first packet of a TCP handshake. What secrets would this data contain?

The first intriguing statistic is the number of spoofed TCP SYN packets coming from known bogus source IPs: zero. This isn’t actually terribly surprising for a couple reasons. One, packets originating from impossible addresses are rather easy to catch and drop, and many ISPs do this sort of scrubbing at their network borders. But the second reason is that TCP requires a three-way handshake to make a useful connection. And while it’s possible to spoof an IP address on a local network via ARP poisoning, doing so on the open Internet is much more difficult.

Packet TTL is interesting, but the values naturally vary, based on the number of hops between the sender and receiver. A few source IPs were observed to vary in reported TTLs, which could indicate devices behind NAT, or even just the variation between different OS network stacks. But looking for suspicious traffic, two metrics really stand out. The TCP Header is a minimum 20 bytes, with additional length being used with each additional option specified. Very few systems will naturally send TCP SYN packets with the header set to 20, suggesting that the observed traffic at that length was mostly TCP probes. The other interesting observation is the TCP window size, with 29,200 being a suspicious number that was observed in a significant percentage of packets, without a good legitimate explanation.

Hacking the MCP

GitHub has developed the GitHub MCP Server, a Master Control Program Model Context Protocol server, designed to allow AI agents to interact with the GitHub API. Invariant Labs has put together an interesting demo in how letting an agentic AI work with arbitrary issues from the public could be a bad idea.

The short explanation is that a GitHub issue can include a prompt injection attack. In the example, it looks rather benign, asking for more information about the project author to be added to the project README. Just a few careful details in that issue, like specifying that the author isn’t concerned about privacy, and that the readme update should link to all the user’s other repos. If the repo owner lets an agentic AI loose on the repo via MCP, it’s very likely to leak details and private repo information that it really shouldn’t.

Invariant Labs suggests that MCP servers will need granular controls, limiting what an AI agent can access. I suspect we’ll eventually see a system for new issues like GitHub already has for Pull Requests, where a project maintainer has to approve the PR before any of the automated Github Actions are performed on it. Once AI is a normal part of dealing with issues, there will need to be tools to keep the AI from interacting with new issues until a maintainer has cleared them.

GitLab Too

GitLab has their own AI integration, GitLab Duo. Like many AI things, it has the potential to be helpful, and the potential to be a problem. Researchers at Legit Security included some nasty tricks in this work, like hiding prompt injection as Hex code, and coloring it white to be invisible on the white GitLab background. Prompt injections could then ask the AI to recommend malicious code, include raw HTML in the output, or even leak details from private repos.

Gitlab took the report seriously, and has added additional filtering that prevents Duo from injecting raw HTML in its output. The prompt injection has also been addressed, but the details of how are not fully available.

Finally, Actually Hacking the Registry

We’ve been following Google’s Project Zero and [Mateusz Jurczyk] for quite a while, on a deep dive into the Windows Registry. We’re finally at the point where we’re talking about vulnerabilities. The Windows registry is self-healing, which could be an attack surface on its own, but it definitely provides a challenge to anyone looking for vulnerabilities with a fuzzer, as triggering a crash is very difficult.

But as the registry has evolved over time and Windows releases, the original security assumptions may not be valid any longer. For instance, in its original form, the registry was only writable by a system administrator. But on modern Windows machines, application hives allow unprivileged users and process to load their own registry data into the system registry. Registry virtualization and layered keys further complicate the registry structure and code, and with complexity often comes vulnerabilities.

An exploit primitive that turned out to be useful was the out-of-bound cell index, where one cell can refer to another. This includes a byte offset value, and when the cell being referred to is a “small dir”, this offset can point past the end of the allocated memory.

There were a whopping 17 memory corruption exploits discovered, but to produce a working exploit, the write-up uses CVE-2023-23420, a use after free that can be triggered by performing an in-place rename of a key, followed by deleting a subkey. This can result in a live reference to that non-existent subkey, and thus access to freed memory.

In that free memory, a fake key is constructed. As the entire data structure is now under the arbitrary control of the attacker, the memory can point to anywhere in the hive. This can be combined with the out-of-bounds cell index, to manipulate kernel memory. The story turns into a security researcher flex here, as [Mateusz] opted to use a couple registry keys rigged in this way to make a working kernel memory debugger, accessible from regedit. One key sets the memory address to inspect, and the other key contains said memory as a writable key. Becoming SYSTEM at this point is trivial.

Bits and Bytes

[Thomas Stacey] of Assured has done work on HTTP smuggling/tunneling attacks, where multiple HTTP requests exist in a single packet. This style of attack works against web infrastructure that has a front-end proxy and a back-end worker. When the front-end and back-end parse requests differently, very unintended behavior can result.

ONEKEY researchers have discovered a pair of issues in the Evertz core web administration interface, that together allow unauthenticated arbitrary command injection. Evertz manufactures very large video handling equipment, used widely in the broadcast industry, which is why it’s so odd that the ONEKEY private disclosure attempts were completely ignored. As the standard 90 day deadline has passed, ONEKEY has released the vulnerability details in full.

On the other hand, Mozilla is setting records of its own, releasing a Firefox update on the same day as exploits were revealed at pwn2own 2025. Last year Mozilla received the “Fastest to Patch” award, and may be on track to repeat that honor.

What does video game cheat development have to do with security research? It’s full of reverse engineering, understand memory structures, hooking functions, and more. It’s all the things malware does to take over a system, and all the things a researcher does to find vulnerabilities and understand what binaries are doing. If you’re interested, there’s a great two-part series on the topic just waiting for you to dive into. Enjoy!

Have you heard that author Andy Weir has a new book coming out? Very exciting, we know, and according to a syndicated reading list for Summer 2025, it’s called The Last Algorithm, and it’s a tale of a programmer who discovers a dark and dangerous secret about artificial intelligence. If that seems a little out of sync with his usual space-hacking fare such as The Martian and Project Hail Mary, that’s because the book doesn’t exist, and neither do most of the other books on the list.

The list was published in a 64-page supplement that ran in major US newspapers like the Chicago Sun-Times and the Philadelphia Inquirer. The feature listed fifteen must-read books, only five of which exist, and it’s no surprise that AI is to behind the muck-up. Writer Marco Buscaglia took the blame, saying that he used an LLM to produce the list without checking the results. Nobody else in the editorial chain appears to have reviewed the list either, resulting in the hallucination getting published. Readers are understandably upset about this, but for our part, we’re just bummed that Andy doesn’t have a new book coming out.

In equally exciting but ultimately fake news, we had more than a few stories pop up in our feed about NASA’s recent discovery of urban lights on an exoplanet. AI isn’t to blame for this one, though, at least not directly. Ironically, the rumor started with a TikTok video debunking a claim of city lights on a distant planet. Social media did what social media does, though, sharing only the parts that summarized the false claim and turning a debunking into a bunking. This is why we can’t have nice things.

That wasn’t the only story about distant lights, though, with this report of unexplained signals from two nearby stars. This one is far more believable, coming as it does from retired JPL scientist Richard H. Stanton, who has been using a 30″ telescope to systematically search for optical SETI signals for the past few years. These searches led to seeing two rapid pulses of light from HD 89389, an F-type star located in the constellation Ursa Major. The star rapidly brightened, dimmed, brightened again, then returned to baseline over a fraction of second; the same pattern repeated itself about 4.4 seconds later.

Intrigued, he looked back through his observations and found a similar event from a different star, HD 217014 in Pegasus, four years previously. Interestingly, this G-type star is known to have at least one exoplanet. Stanton made the first observation in 2023, and he’s spent much of the last two years ruling out things like meteor flashes or birds passing through his field of view. More study is needed to figure out what this means, and while it’s clearly not aliens, it’s fun to imagine it could be some kind of technosignature.

And one last space story, this time with the first observation of extra-solar ice. The discovery comes from the James Webb Space Telescope, which caught the telltale signature of ice crystals in a debris ring circling HD 181327, a very young star only 155 light-years away. Water vapor had been detected plenty of times outside our solar system, but not actual ice crystals until now. The ice crystals seem to be coming from collisions between icy bodies in the debris field, an observation that has interesting implications for planetary evolution.

And finally, if like us you’re impressed anytime someone busts out a project with a six-layer PCB design, wait till you get a load of this 124-layer beast. The board comes from OKI Circuit Technologies and is intended for high-bandwidth memory for AI accelerators. The dielectric for each layer is only 125-μm thick, and the board is still only 7.6 mm thick overall. At $4,800 per square meter, it’s not likely we’ll see our friends at JLC PCB offering these anytime soon, but it’s still some pretty cool engineering.

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!