You wake up in the morning, and check Hackaday over breakfast. Then it’s off to work or school, where you’ve already had to explain the Jolly Wrencher to your shoulder-surfing colleagues. And then to a hackspace or back to your home lab, stopping by the skull-and-cross-wrenches while commuting, naturally. You don’t bleed red, but rather #F3BF10. It’s time we talked.

The Hackaday writing crew goes to great lengths to cover all that is interesting to engineers and enthusiasts. We find ourselves stretched a bit thin and it’s time to ask for help. Want to lend a hand while making some extra dough to plow back into your projects? We’re looking for contributors to write a few articles per week and keep the Hackaday flame burning.

Contributors are hired as private contractors and paid for each article. You should have the technical expertise to understand the projects you write about, and a passion for the wide range of topics we feature. You’ll have access to the Hackaday Tips Line, and we count on your judgement to help us find the juicy nuggets that you’d want to share with your hacker friends.

If you’re interested, please email our jobs line (jobs at hackaday dot com) and include:

• One example article written in the voice of Hackaday. Include a banner image, between 150 and 300 words, the link to the project, and any in-links to related and relevant Hackaday features. We need to know that you can write.
• Details about your background (education, employment, interests) that make you a valuable addition to the team. What do you like, and what do you do?
• Links to your blog/project posts/etc. that have been published on the Internet, if any.

Questions? Don’t hesitate to ask below. Ladies and Gentlemen, start your applications!

Okay, you have to see the gallery to appreciate it, but this keyboard was designed to resemble a red cedar tree with the green shell and wood bottom and the copper PCB showing through the tree cutouts on the sides.

Oh, and are those Nintendo Switch joysticks above the PS2 buttons? Those are for the mouse and vertical/horizontal scrolling. Honestly, this seems like a great amount of thumb controls. The basics are there (presumably), and there isn’t any thumb-extending excess, like keys on the insides by the mouse.

This bad mama jama runs on an RP2040 and has 50 hand-wired Cherry Brown switches plus the PS2 buttons. In the build guide, you can read all about [WesternRedCdar]’s troubles with integrating those. The Nintendo Switch joysticks weren’t terribly easy, either, since the ribbon connector can’t be soldered directly.

The final issue was one of weight. Since many of the switches stand quite tall, it sort of jostles the keyboard to actuate them. [WesternRedCdar] opined that that the ideal solution would have been to use metal base plates instead of wood, but took care of the issue by adding layers of 1/8″ steel flat bar inside the case.

Gone in 60 Seconds: the Micro Journal Rev. 7 From Tindie

Don’t know what took me so long to find r/writerDeck, but here we go! [WorkingAmbition7014] was quite excited to announce there that [Background_Ad_1810] aka [Un Kyu Lee]’s Micro Journal rev. 7 was up on Tindie. It’s already sold out, but that’s okay because previous versions are already open-source, and it’s just a matter of time before this new revision makes its way to the ole GitHub.

This distraction-free machine is based on the ESP32-S3 microcontroller. It starts up right away, and you can start typing pretty much immediately on the ePaper screen. There are a pair of knobs that go a long way toward its typewriter looks; the left one wipes the screen and puts the machine to sleep, and the right knob clears the screen in the case of too much ghosting.

Files are saved on the SD card that sits behind the screen, or you can send them to Google Drive. Now, it doesn’t come with that cool clip light, but it doesn’t have a backlight, either, so you’ll probably want to bring your own. You will also have to source your own 18650. Be sure to check out the overview after the break.

The Centerfold: Purple Paradise

I love these setup pictures, but I have to wonder, does anyone really keep their desk this clean and tidy? Of course not, it’s for the shot, you’re saying. But that’s my point. Why does everyone always tidy up so hard first? I want to see battle stations in their true forms sometimes. I feel like we got sorta close last week in the one with all the screens. So do I need to inspire centerfold submissions by showing my own battle station one of these times? I don’t know if y’all really want that.

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

Historical Clackers: the Ford Typewriter

Isn’t this machine a beauty? And no, inventor Eugene A. Ford bore no relation to Henry Ford the automobile maker. But wouldn’t this look grand while perched briefly on the running board of your Model T for a quick daguerreotype?

Lovely as she was, the 1895 Ford was no fun for the typist. The Space bar-placed Shifts required real pressure to properly operate, and the keys are evidently springy and wobbly. “Springy” sounds intriguing; “wobbly” does not.

Additionally, the advancing lever doesn’t allow going backwards or forwards a line at a time. But the one great thing about the Ford was that it’s a visible writer, whereas most machines of the time were blind writers, meaning you were unable to see what you were typing without stopping and doing something first. It wasn’t the first visible writer, but it might be the easiest to look at.

What it did do first is use aluminium in its construction, although there were two versions, one with an all-aluminium frame and carriage, and the other with a black, enameled cast iron frame and and an aluminium carriage. The cast iron went for $75, and the lighter-weight aluminium machine for $85. Both were lateral thrust machines, which means that the type bars are spread out like a fan and move horizontally to strike the platen.

Eugene Ford had quite the career. After putting his typewriter on the market in 1895, he worked with IBM for the rest of his life, and became chief development engineer of the New York laboratories in 1911. During his tenure, he developed improvements to various punched card accounting machines, sorters, and counters.

Finally, a Keyboard for Cat Lovers

Cats and keyboards go together like peanut butter and jelly. When they’re not straight up walking across it, they’re fluffing it up. Well, why not admit defeat and get this cozy cat-themed keyboard?

This is the Dry Studio Petbrick 65, which comes in calico and black, which is called the odd-eyed design, presumably because the kitty on the Escape key has heterochromia.

Now that’s just the keyboard itself that comes in calico and black; soon you’ll be able to get all kinds of fuzzy bezels, which attach with magnets and are hand-washable, thankfully.

The Petbrick 65 isn’t just some cutesy little thing. This is a serious mechanical keyboard with a sandblasted POM plate, a specially-tuned (what? how?) cotton poron switch pad, PET film for the sake of acoustics, and two layers of sound-dampening foam.

The switches are custom-made ‘crystal pinks’ that were developed in-house and look pretty slick. If you don’t like them, the PCB is hot-swappable. And they didn’t stop there — the keycaps have dye-sublimated legends for longevity.

Would I type on this? I would, at least until it became uncomfortable for my RSI situation. I’m interested to try these crystal pink switches and feel the fluffiness of the frame on the heels of my hands.

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

Ho-hum — another week, another high-profile bricking. In a move anyone could see coming, Humane has announced that their pricey AI Pin widgets will cease to work in any meaningful way as of noon on February 28. The company made a splash when it launched its wearable assistant in April of 2024, and from an engineering point of view, it was pretty cool. Meant to be worn on one’s shirt, it had a little bit of a Star Trek: The Next Generation comm badge vibe as the primary UI was accessed through tapping the front of the thing. It also had a display that projected information onto your hand, plus the usual array of sensors and cameras which no doubt provided a rich stream of user data. Somehow, though, Humane wasn’t able to make the numbers work out, and as a result they’ll be shutting down their servers at the end of the month, with refunds offered only to users who bought their AI Pins in the last 90 days.

How exactly Humane thought that offering what amounts to a civilian badge cam was going to be a viable business model is a bit of a mystery. Were people really going to be OK walking into a meeting where Pin-wearing coworkers could be recording everything they say? Wouldn’t wearing a device like that in a gym locker room cause a stir? Sure, the AI Pin was a little less obtrusive than something like the Google Glass — not to mention a lot less goofy — but all wearables seem to suffer the same basic problem: they’re too obvious. About the only one that comes close to passing that hurdle is the Meta Ray-Ban smart glasses, and those still have the problem of obvious cameras built into their chunky frames. Plus, who can wear Ray-Bans all the time without looking like a tool?

Good news for everyone worried about a world being run by LLMs and chatbots. It looks like all we’re going to have to do is wait them out, if a study finding that older LLMs are already showing signs of cognitive decline pans out. To come to that conclusion, researchers gave the Montreal Cognitive Assessment test to a bunch of different chatbots. The test uses simple questions to screen for early signs of impairment; some of the questions seem like something from a field sobriety test, and for good reason. Alas for the tested chatbots, the general trend was that the older the model, the poorer they did on the test. The obvious objection here is that the researchers aren’t comparing each model’s current score with results from when the model was “younger,” but that’s pretty much what happens when the test is used for humans.

You’ve got to feel sorry for astronomers. Between light pollution cluttering up the sky and an explosion in radio frequency interference, astronomers face observational challenges across the spectrum. These challenges are why astronomers prize areas like dark sky reserves, where light pollution is kept to a minimum, and radio quiet zones, which do the same for the RF part of the spectrum. Still, it’s a busy world, and noise always seems to find a way to leak into these zones. A case in point is the recent discovery that TV signals that had been plaguing the Murchison Wide-field Array in Western Australia for five years were actually bouncing off airplanes. The MWA is in a designated radio quiet zone, so astronomers were perplexed until someone had the bright idea to use the array’s beam-forming capabilities to trace the signal back to its source. The astronomers plan to use the method to identify and exclude other RFI getting into their quiet zone, both from terrestrial sources and from the many satellites whizzing overhead.

And finally, most of us are more comfortable posting our successes online than our failures, and for obvious reasons. Everyone loves a winner, after all, and admitting our failures publicly can be difficult. But Daniel Dakhno finds value in his failures, to the point where he’s devoted a special section of his project portfolio to them. They’re right there at the bottom of the page for anyone to see, meticulously organized by project type and failure mode. Each failure assessment includes an estimate of the time it took; importantly, Daniel characterizes this as “time invested” rather than “time wasted.” When you fall down, you should pick something up, right?

In Al Williams’s marvelous rant he points out a number of the problems with speaking to computers. Obvious problems with voice control include things like multiple people talking over each other, discerning commands from background conversations, and so on. Somehow, unlike on the bridge in Star Trek, where the computer seems to understand everyone just fine, Al sometimes can’t even get the darn thing to play his going-to-sleep playlist, which should be well within the device’s capabilities.

In the comments, [rclark] suggests making a single button that plays his playlist, no voice interaction required, and we have to admit that it’s a great solution to this one particular problem. Heck, the “bedtime button” would make fun project in and of itself, and it’s such a limited scope that it could probably only be an weekend’s work for anyone who has touched the internals of their home automation system, like Al certainly has. We love the simplicity of the idea.

But it ignores the biggest potential benefit of a voice control system: that it’s a one-size-fits-all solution for everything. Imagine how many other use cases Al would need to make a single button device for, and how many coin cell batteries he’d be signing himself up to change out over the course of the year. The trade-off is that the general purpose solution tends not to be as robust as a single-tasker like the button, but also that it can potentially simplify the overall system.

I suffer this in my own home. It’s much more a loosely-coupled web of individual hacks than an overall system, and that has pros and cons. Each individual part is easier to maintain and hack on, but the overall system is less coordinated than it could be. If we change the WiFi password on the home automation router, for instance, I’m going to have to individually log into about eight ESP8266s and change their credentials. Yuck!

It’s probably a matter of preference, but I’ll still take the loose, MQTT-based system that I’ve got now over an all-in-one. Like [rclark], I value individual device simplicity and reliability above the overall system’s simplicity, but because our stereo isn’t even hooked up to the network, I can’t play myself to sleep like Al can. Or at least like he can when the voice recognition is working.

We hear a lot about how ham radio isn’t what it used to be. But what was it like? Well, the ARRL’s film “The Ham’s Wide World” shows a snapshot of the radio hobby in the 1960s, which you can watch below. The narrator is no other than the famous ham [Arthur Godfrey] and also features fellow ham and U.S. Senator [Barry Goldwater]. But the real stars of the show are all the vintage gear: Heathkit, Swan, and a very oddly placed Drake.

The story starts with a QSO between a Mexican grocer and a U.S. teenager. But it quickly turns to a Field Day event. Since the film is from the ARRL, the terminology and explanations make sense. You’ll hear real Morse code and accurate ham lingo.

Is ham radio really different today? Truthfully, not so much. Hams still talk to people worldwide and set up mobile and portable stations. Sure, hams use different modes in addition to voice. There are many options that weren’t available to the hams of the 1960s, but many people still work with old gear and older modes and enjoy newer things like microwave communications, satellite work, and even merging radio with the Internet.

In a case of history repeating itself, there is an example of hams providing communications during a California wildfire. Hams still provide emergency communication in quite a few situations. It is hard to remember that before the advent of cell phones, a significant thing hams like [Barry Goldwater] did was to connect servicemen and scientists overseas to their families via a “phone patch.” Not much of that is happening today, of course, but you can still listen in to ham radio contacts that are partially over the Internet right in your web browser.

This week Hackaday Editors Elliot Williams and Tom Nardi start things off with updates on the rapidly approaching Hackaday Europe and the saga of everyone’s favorite 3D printed boat.

From there they’ll cover an impressive method of seeing the world via WiFi, Amazon’s latest changes to the Kindle ecosystem, and an alternate reality in which USB didn’t take over the peripheral world. You’ll also hear about a multi-level hack that brings the joys of Linux into the world of Animal Crossing, 3D printed circuit components, and the imminent release of KiCAD 9.

Stick around until the end to learn about a unique hardened glass from East Germany and the disappointing reality of modern voice control systems.

Download the DRM-free MP3 for safe keeping.

Episode 309 Show Notes:

News:

• Hackaday Europe 2025: Speakers, Lightning Talks, And More!
• 3DBenchy Sets Sail Into The Public Domain

What’s that Sound?

• Know that sound? Fill out this form for a chance to win a Hackaday Podcast t-shirt!

Interesting Hacks of the Week:

• Octet Of ESP32s Lets You See WiFi Like Never Before
  • Building Your Own SDR-based Passive Radar On A Shoestring
  • Open-Source Passive Radar Taken Down For Regulatory Reasons
  • [2502.09405] ESPARGOS: An Ultra Low-Cost, Realtime-Capable Multi-Antenna WiFi Channel Sounder

• Auto-Download Your Kindle Books Before February 26th Deadline
• In A World Without USB…
• Give Your Animal Crossing Villagers The Gift Of Linux
  • Because You Can: Linux On An Arduino Uno
• A Unique Linear Position Sensor Using Magnetostriction
  • 2024 :: fischertechnik Community

• MIT Demonstrates Fully 3D Printed, Active Electronic Components

Quick Hacks:

• Elliot’s Picks:
  • You Know This Font, But You Don’t Really Know It
  • Measuring Local Variances In Earth’s Magnetic Field
  • Probably The Most Esoteric Commodore 64 Magazine
• Tom’s Picks:
  • Get Ready For KiCAD 9!
  • Vacuum Forming With 3D Printed Moulds And Sheets
  • Belfry OpenSCAD Library (BOSL2) Brings Useful Parts And Tools Aplenty

Can’t-Miss Articles:

• The “Unbreakable” Beer Glasses Of East Germany
  • The High-Tech Valor Glass Vials Used To Deliver The Coronavirus Vaccine

• Be Careful What You Ask For: Voice Control

OpenSSH has a newly fixed pair of vulnerabilities, and while neither of them are lighting the Internet on fire, these are each fairly important.

The central observation made by the Qualsys Threat Research Unit (TRU) was that OpenSSH contains a code paradigm that could easily contain a logic bug. It’s similar to Apple’s infamous goto fail; SSL vulnerability. The setup is this: An integer, r, is initialized to a negative value, indicating a generic error code. Multiple functions are called, with r often, but not always, set to the return value of each function. On success, that may set r to 0 to indicate no error. And when one of those functions does fail, it often runs a goto: statement that short-circuits the rest of the checks. At the end of this string of checks would be a return r; statement, using the last value of r as the result of the whole function.

1387 int
1388 sshkey_to_base64(const struct sshkey *key, char **b64p)
1389 {
1390         int r = SSH_ERR_INTERNAL_ERROR;
....
1398         if ((r = sshkey_putb(key, b)) != 0)
1399                 goto out;
1400         if ((uu = sshbuf_dtob64_string(b, 0)) == NULL) {
1401                 r = SSH_ERR_ALLOC_FAIL;
1402                 goto out;
1403         }
....
1409         r = 0;
1410  out:
....
1413         return r;
1414 }

The potential bug? What if line 1401 was missing? That would mean setting r to the success return code of one function (1398), then using a different variable in the next check (1400), without re-initializing r to a generic error value (1401). If that second check fails at line 1400, the code execution jumps to the return statement at the end, but instead of returning an error code, the success code from the intermediary check is returned. The TRU researchers arrived at this theoretical scenario just through the code smell of this particular goto use, and used the CodeQL code analysis tool to look for any instances of this flaw in the OpenSSH codebase.

The tool found 50 results, 37 of which turned out to be false positives, and the other 13 were minor issues that were not vulnerabilities. Seems like a dead end, but while manually auditing how well their CodeQL rules did at finding the potentially problematic code, the TRU team found a very similar case, in the VerifyHostKeyDNS handling, that could present a problem. The burning question on my mind when reaching this point of the write-up was what exactly VerifyHostKeyDNS was.

SSH uses public key cryptography to prevent Man in the Middle (MitM) attacks. Without this, it would be rather trivial to intercept an outgoing SSH connection, and pretend to be the target server. This is why SSH will warn you The authenticity of host 'xyz' can't be established. upon first connecting to a new SSH server. And why it so strongly warns that IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! when a connection to a known machine doesn’t verify properly. VerifyHostKeyDNS is an alternative to trusting a server’s key on first connection, instead getting the cryptographic fingerprint in a DNS lookup.

So back to the vulnerability. TRU found one of these goto out; cases in the VerifyHostKeyDNS handling that returned the error code from a function on failure, but the code a layer up only checked for a -1 value. On one layer of code, only a 0 was considered a success, and on the other layer, only a -1 was considered a failure. Manage to find a way to return an error other than -1, and host key verification automatically succeeds. That seems very simple, but it turns out the only other practical error that can be returned is an out of memory error. This leads to the second vulnerability that was discovered.

OpenSSH has its own PING mechanism to determine whether a server is reachable, and what the latency is. When it receives a PING, it sends a PONG message back. During normal operation, that’s perfectly fine. The messages are sent and the memory used is freed. But during key exchange, those PONG packets are simply queued. There are no control mechanisms on how many messages to queue, and a malicious server can keep a client in the key exchange process indefinitely. In itself it’s a denial of service vulnerability for both the client and server side, as it can eat up ridiculous amount of memory. But when combined with the VerifyHostKeyDNS flaw explained above, it’s a way to trigger the out of memory error, and bypass server verification.

The vulnerabilities were fixed in the 9.9p2 release of OpenSSH. The client attack (the more serious of the two) is only exploitable if your client has the VerifyHostKeyDNS option set to “yes” or “ask”. Many systems default this value to “no”, and are thus unaffected.

JumbledPath

We now have a bit more insight into how Salt Typhoon recently breached multiple US telecom providers, and deployed the JumbledPath malware. Hopefully you weren’t expecting some sophisticated chain of zero-day vulnerabilities, because so far the answer seems to be simple credential stealing.

Cisco Talos has released their report on the attacks, and the interesting parts are what the attackers did after they managed to access target infrastructure. The JumbledPath malware is a Go binary, running on x86-64 Linux machines. Lateral movement was pulled off using some clever tricks, like changing the loopback address to an allowed IP, to bypass Access Control Lists (ACLs). Multiple protocols were abused for data gathering and further attacks, like SNMP, RADIUS, FTP, and SSH. There’s certainly more to this story, like where the captured credentials actually came from, and whose conversations were actually targeted, but so far those answers are not available.

Ivanti Warp-Speed Audit

The preferred method of rediscovering vulnerabilities is patch diffing. Vendors will often announce vulnerabilities, and even release updates to correct them, and never really dive into the details of what went wrong with the old code. Patch diffing is looking at the difference between the vulnerable release and the fixed one, figuring out what changed, and trying to track that back to the root cause. Researchers at Horizon3.ai knew there were vulnerabilities in Ivanti’s Endpoint manager, but didn’t have patches to reverse engineer. Seems like a bummer, but was actually serendipity, as the high-speed code audit looking for the known vulnerability actually resulted in four new ones being found!

They are all the same problem, spread across four API endpoints, and all reachable by an unauthenticated user. The code is designed to look at files on the local filesystem, and generate hashes for the files that are found. The problem is that the attacker can supply a file name that actually resolves to an external Universal Naming Convention (UNC) path. The appliance will happily reach out and attempt to authenticate with a remote server, and this exposes the system to credential relay attacks.

RANsacked

The Florida Institute for Cybersecurity Research have published a post and paper (PDF) about RANsacked, their research into various LTE and 5G systems. This is a challenging area to research, as most of us don’t have any spare LTE routing hardware laying around to research on. The obvious solution was to build their own, using open source software like Open5GS, OpenAirInterface, etc. The approach was to harness a fuzzer to find interesting vulnerabilities in these open implementations, and then apply that approach to closed solutions. Serious vulnerabilities were found in every target the fuzzing system was run against.

Their findings break down into three primary categories of vulnerabilities. The first is untrusted Non-Access Stratum (NAS) control messages getting handled by the “core”, the authentication, routing, and processing part of the cellular system. These messages aren’t properly sanitized before processing, leading to the expected crashes and exploits we see in every other insufficiently hardened system that processes untrusted data. The second category is the uncertainty in the protocol specifications and mismatch between what those specifications seem to indicate and the reality of cellular traffic. And finally, deserialization of ASN.1 data itself is subject to deserialization attacks. This group of research found a staggering 119 vulnerabilities in total.

Bits and Bytes

[RyotaK] at GMO Flatt Security found an interesting vulnerability in Chatwork, a popular messaging application in Japan. The desktop version of this tool is just an electron app, and it makes use of webviewTag, an obsolete Electron feature. This quirk can be combined with a dangerous method in the preload context, allowing for arbitrary remote code execution when a user clicks a malicious link in the application.

Once upon a time, Microsoft published Virtual Machines for developers to use for testing websites inside Edge and IE. Those VM images had the puppet admin engine installed, but no configuration set. And that’s not great, because in this state puppet will look for machine using the puppet hostname on the local network, and attempt to download a configuration from there. And because puppet is explicitly designed to administer machines, this automatically results in arbitrary code execution. The VMs are no longer offered, so we’re past the expiration date on this particular trick, but what an interesting quirk of these once-official images.

[Anurag] has an analysis of the Arechclient2 Remote Access Trojan (RAT). It’s a bit of .NET malware, aggressively obfuscated, that collects and exfiltrates data and credentials. There’s a browser element, in the form of a Chrome extension that reports itself as Google Docs. This is more data collection, looking for passwords and other form fills.

Signal users are getting hacked by good old fashioned social engineering. The trick is to generate a QR code from Signal that will permit the account scanning the code to log in on another device. It’s advice some of us have learned the hard way, but QR codes are just physical manifestations of URLs, and we really shouldn’t trust them lightly. Don’t click that link, and don’t scan that QR code.