Forgotten Internet: Giving (or Getting) The Finger

January 30, 2025 by 27 Comments

Hey, you know that guy in accounting, Marco? If you want to find out more about him, you’d probably go surf LinkedIn or maybe a social media site. Inside a company, you might look on instant messaging for a profile and even find out if he is at his desk or away. But back in the 1970s, those weren’t options. But if Marco was on the computer system, maybe you could finger him. While that sounds strange to say today, Finger was a common service provided by computer services at the time. It was like a LinkedIn profile page for the 1970s.

Based on RFC 742, Finger was the brainchild for [Les Earnest]. From a user’s point of view, you put a few files in your home directory (usually .project and .plan; both hidden files), and when someone “fingered” you, they’d see some human-friendly output about your account like your name and office location, if you were logged in or not, and the contents of your project and plan files.

Modern versions may also show your public PGP key and other data. You could usually put a file in your home directory called .nofinger if you wanted to stop people from fingering you.

Continue reading “Forgotten Internet: Giving (or Getting) The Finger” →

Networking History Lessons

January 25, 2025 by 34 Comments

Do they teach networking history classes yet? Or is it still too soon?

I was reading [Al]’s first installment of the Forgotten Internet series, on UUCP. The short summary is that it was a system for sending files across computers that were connected, intermittently, by point-to-point phone lines. Each computer knew the phone numbers of a few others, but none of them had anything like a global routing map, and IP addresses were still in the future. Still, it enabled file transfer and even limited remote access across the globe. And while some files contained computer programs, others files contained more human messages, which makes UUCP also a precursor to e-mail.

What struck me is how intuitively many of this system’s natural conditions and limitations lead to the way we network today. From phone numbers came the need for IP addresses. And from the annoyance of having know how the computers were connected, and to use the bang notation to route a message from one computer to another through intermediaries, would come our modern routing protocols, simply because computer nerds like to automate hassles wherever possible.

But back to networking history. I guess I learned my networking on the mean streets, by running my own Linux system, and web servers, and mail servers. I knew enough networking to get by, but that mostly focused on the current-day application, and my beard is not quite grey enough to have been around for the UUCP era. So I’m only realizing now that knowing how the system evolved over time helps a lot in understanding why it is the way it is, and thus how it functions. I had a bit of a “eureka” moment reading about UUCP.

In physics or any other science, you learn not just the status quo in the field, but also how it developed over the centuries. It’s important to know something about the theory of the aether to know what special relativity was up against, for instance, or the various historical models of the atom, to see how they inform modern chemistry and physics. But these are old sciences with a lot of obsolete theories. Is computer science old enough that they teach networking history? They should!

This article is part of the Hackaday.com newsletter, delivered every seven days for each of the last 200+ weeks. It also includes our favorite articles from the last seven days that you can see on the web version of the newsletter. Want this type of article to hit your inbox every Friday morning? You should sign up!

This Week In Security: ClamAV, The AMD Leak, And The Unencrypted Power Grid

January 24, 2025 by 10 Comments

Cisco’s ClamAV has a heap-based buffer overflow in its OLE2 file scanning. That’s a big deal, because ClamAV is used to scan file attachments on incoming emails. All it takes to trigger the vulnerability is to send a malicious file through an email system that uses ClamAV.

The exact vulnerability is a string termination check that can fail to trigger, leading to a buffer over-read. That’s a lot better than a buffer overflow while writing to memory. That detail is why this vulnerability is strictly a Denial of Service problem. The memory read results in process termination, presumably a segfault for reading protected memory. There are Proof of Concepts (PoCs) available, but so far no reports of the vulnerability being used in the wild.
Continue reading “This Week In Security: ClamAV, The AMD Leak, And The Unencrypted Power Grid” →

Shellcode Over MIDI? Bad Apple On A PSR-E433, Kinda

January 23, 2025 by 6 Comments

If hacking on consumer hardware is about figuring out what it can do, and pushing it in directions that the manufacturer never dared to dream, then this is a very fine hack indeed. [Portasynthica3] takes on the Yamaha PSR-E433, a cheap beginner keyboard, discovers a shell baked into it, and takes it from there.

[Portasynthinca3] reverse engineered the firmware, wrote shellcode for the device, embedded the escape in a MIDI note stream, and even ended up writing some simple LCD driver software totally decent refresh rate on the dot-matrix display, all to support the lofty goal of displaying arbitrary graphics on the keyboard’s dot-matrix character display.

Now, we want you to be prepared for a low-res video extravaganza here. You might have to squint a bit to make out what’s going on in the video, but keep in mind that it’s being sent over a music data protocol from the 1980s, running at 31.25 kbps, displayed in the custom character RAM of an LCD.

As always, the hack starts with research. Identifying the microcontroller CPU lead to JTAG and OpenOCD. (We love the technique of looking at the draw on a bench power meter to determine if the chip is responding to pause commands.) Dumping the code and tossing it into Ghidra lead to the unexpected discovery that Yamaha had put a live shell in the device that communicates over MIDI, presumably for testing and development purposes. This shell had PEEK and POKE, which meant that OpenOCD could go sit back on the shelf. Poking “Hello World” into some free RAM space over MIDI sysex was the first proof-of-concept.

The final hack to get video up and running was to dig deep into the custom character-generation RAM, write some code to disable the normal character display, and then fool the CPU into calling this code instead of the shell, in order to increase the update rate. All of this for a thin slice of Bad Apple over MIDI, but more importantly, for the glory. And this hack is glorious! Go check it out in full.

MIDI is entirely hacker friendly, and it’s likely you can hack together a musical controller that would wow your audience just with stuff in your junk box. If you’re at all into music, and you’ve never built your own MIDI devices, you have your weekend project.

Continue reading “Shellcode Over MIDI? Bad Apple On A PSR-E433, Kinda” →

DIY Drones Deliver The Goods With Printed Release

January 22, 2025 by 17 Comments

It seems like the widespread use of delivery drones by companies like Amazon and Wal-Mart has been perpetually just out of reach. Of course robotics is a tricky field, and producing a fleet of these machines reliable enough to be cost effective has proven to be quite a challenge. But on an individual level, turning any drone into one that can deliver a package is not only doable but is something [Iloke-Alusala] demonstrates with their latest project.

The project aims to be able to turn any drone into a delivery drone, in this case using a FPV drone as the platform. Two hitch-like parts are 3D printed, one which adds an attachment point to the drone and another which attaches to the package, allowing the drone to easily pick up the package and then drop it off quickly. The real key to this build is the control mechanism. [Iloke-Alusala] used an ESP32 to tap into the communications between the receiver and the flight controller. When the ESP32 detects a specific signal has been sent to the flight controller, it can activate the mechanism on the 3D printed hitch to either grab on to a package or release it at a certain point.

While this is a long way from a fully autonomous fleet of delivery drones, it goes a long way into showing that individuals can use existing drones to transport useful amounts of material and also sets up a way for an ESP32 to decode and use a common protocol used in drones, making it easy to expand their capabilities in other ways as well. After all, if we have search and rescue drones we could also have drones that deliver help to those stranded.

Continue reading “DIY Drones Deliver The Goods With Printed Release” →

desk with circuit schema and AirTag

Stealth AirTag Broadcasts When Moved: An Experiment

January 18, 2025 by 43 Comments

A simple yet intriguing idea is worth sharing, even if it wasn’t a flawless success: it can inspire others. [Richard]’s experiment with a motion-powered AirTag fits this bill. Starting with our call for simple projects, [Richard] came up with a circuit that selectively powers an AirTag based on movement. His concept was to use an inertial measurement unit (IMU) and a microcontroller to switch the AirTag on only when it’s on the move, creating a stealthy and battery-efficient tracker.

The setup is minimal: an ESP32 microcontroller, an MPU-6050 IMU, a transistor, and some breadboard magic. [Richard] demonstrates the concept using a clone AirTag due to concerns about soldering leads onto a genuine one. The breadboard-powered clone chirps to life when movement is detected, but that’s where challenges arise. For one, Apple AirTags are notoriously picky about batteries—a lesson learned when Duracell’s bitter coating blocks functionality. And while the prototype works initially, an unfortunate soldering mishap sadly sends the experiment off the rails.

Despite the setbacks, this project may spark a discussion on the possibilities of DIY digital camouflage for Bluetooth trackers. By powering up only when needed, such a device avoids constant broadcasting, making it harder to detect or block. Whether for tracking stolen vehicles or low-profile uses, it’s a concept rich with potential. We talked about this back in 2022, and there’s an interesting 38C3 talk that sheds quite some light on the broadcasting protocols and standards. Continue reading “Stealth AirTag Broadcasts When Moved: An Experiment” →

img showing terminal and pico

I3C Bit-banging Fun For The RP2040

January 18, 2025 by 3 Comments

The RP2040 has quickly become a hot favorite with tinkerers and makers since its release in early 2021. This is largely attributed to the low cost, fast GPIOs, and plethora of bus peripherals. [xyphro] has written the I3C Blaster firmware that helps turn the Raspberry Pi Pico into a USB to I3C converter.

The firmware is essentially a bit-bang wrapper and exposes an interactive shell with a generous command set. But it is a lot more than that. [xyphro] has taken the time to dive into the I3C implementation standard and the code is a fairly complex state-machine that is a story on its own.

[xyphro] provides a Python script in case you feel like automating things or drawing up your GUI. And finally, if you are feeling adventurous, the I3C implementation is available for your project tinkering needs.

We loved the fact there is a branch project that lets you extend a Saleae Logic Analyzer to decode I3C and associated protocols by adding a Pico on the cheap. The last update to the project log shows the addition of a MIPI I3C High Data Rate Mode which operates at 25 Mbps which is right up the RP2040s.

[xyphro] gave us the Home Brew Version Of Smart Tweezers a decade ago and we expect there is more to come. If you are interested in reading more about the I3C bus, have a look at I3C — No Typo — Wants To Be Your Serial Bus.