Hackaday Columns

4563 Articles

This excellent content from the Hackaday writing crew highlights recurring topics and popular series like Linux-Fu, 3D-Printering, Hackaday Links, This Week in Security, Inputs of Interest, Profiles in Science, Retrotechtacular, Ask Hackaday, Teardowns, Reviews, and many more.

This Week In Security: That Time I Caused A 9.5 CVE, IOS Spyware, And The Day The Internet Went Down

June 20, 2025 by 18 Comments

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

Continue reading “This Week In Security: That Time I Caused A 9.5 CVE, IOS Spyware, And The Day The Internet Went Down” →

Hacker Tactic: ESD Diodes

June 19, 2025 by 24 Comments

A hacker’s view on ESD protection can tell you a lot about them. I’ve seen a good few categories of hackers neglecting ESD protection – there’s the yet-inexperienced ones, ones with a devil-may-care attitude, or simply those of us lucky to live in a reasonably humid climate. But until we’re able to control the global weather, your best bet is to befriend some ESD diodes before you get stuck having to replace a microcontroller board firmly soldered into your PCB with help of 40 through-hole pin headers.

Humans are pretty good at generating electric shocks, and oftentimes, you’ll shock your hardware without even feeling the shock yourself. Your GPIOs will feel it, though, and it can propagate beyond just the input/output pins inside your chip. ESD events can be a cause of “weird malfunctions”, sudden hardware latchups, chips dying out of nowhere mid-work – nothing to wish for.

Worry not, though. Want to build hardware that survives? Take a look at ESD diodes, where and how to add them, where to avoid them, and the parameters you want to keep in mind. Oh and, I’ll also talk about all the fancy ways you can mis-use ESD diodes, for good and bad alike!

Continue reading “Hacker Tactic: ESD Diodes” →

ZPUI Could Be Your Tiny Embedded GUI

June 18, 2025 by 17 Comments

One of the most frustrating things to me is looking at a freshly-flashed and just powered up single board computer. My goal with them is always getting to a shell – installing packages, driving GPIOs, testing my proof of concept code, adjusting the device tree to load peripheral drivers. Before I can do any of that, I need shell access, and getting there can be a real hassle.

Time after time, I’ve struggled trying to get to a shell on an SBC. For best results, you’d want to get yourself a keyboard, monitor, and an Ethernet cable. Don’t have those, or there’s no space to place them? Maybe a UART connection will work for you – unless it’s broken or misconfigured. Check your pinouts twice. Sure, nowadays you can put WiFi credentials into a text file in /boot/ – but good luck figuring out the IP address, or debugging any mistakes you might make formatting the file. Nowadays, Pi 4 and 5 expose a USB gadget connection on the USB-C port, and that helps… unless you’re already powering the Pi from that port. There’s really no shortage of failure modes here.

If you put a Pi on your network and it goes offline, you generally just don’t know what happened unless you reboot it, which can make debugging into a living hell. I’ve dealt with single-board computers mounted above fiberglass lifted ceilings, fleets of Pi boards at workshops I organized, pocket-carried Pi boards, and at some point, I got tired of it all. A hacker-aimed computer is meant to be accessible, not painful.

Continue reading “ZPUI Could Be Your Tiny Embedded GUI” →

Illustrated Kristina with an IBM Model M keyboard floating between her hands.

Keebin’ With Kristina: The One With The Gaming Typewriter

June 17, 2025 by 3 Comments

Can you teach an old typewriter new tricks? You can, at least if you’re [maniek-86]. And a word to all you typewriter fanatics out there — this Optima SP 26 was beyond repair, lacking several internal parts.

A sleek typewriter with a monitor and a mouse.
Image by [maniek-86] via reddit
But the fully available keyboard was a great start for a gaming typewriter. So [maniek-86] crammed in some parts that were just laying around unused, starting with a micro-ATX motherboard.

But let’s talk about the keyboard. It has a standard matrix, which [maniek-86] hooked up to an Arduino Lenoardo. Although the keyboard has a Polish layout, [maniek-86] remapped it to English-US layout.

As you’ll see in the photos of the internals, this whole operation required careful Tetris-ing of the components to avoid overheating and ensure the cover could go back on.

The graphics were a bit of a challenge, since the motherboard had no PCI-E x16 slot. To address this, [maniek-86] used a riser cable, probably connected to a PCI-E x1 slot with an adapter, in order to use an NVIDIA GT 635 GPU. It can’t run AAA games at 4k, but you can bet that it’ll play Minecraft, Fortnite, or Dota 2 just fine.

Continue reading “Keebin’ With Kristina: The One With The Gaming Typewriter” →

Hackaday Links Column Banner

Hackaday Links: June 15, 2025

June 15, 2025 by 5 Comments

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.

Continue reading “Hackaday Links: June 15, 2025” →

This Week In Security: The Localhost Bypass, Reflections, And X

June 13, 2025 by 26 Comments

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.

Continue reading “This Week In Security: The Localhost Bypass, Reflections, And X” →