34-Year-Old Macintosh ROM Bug Revealed By Emulator

December 7, 2025 by Lewin Day No comments

Generally, you’d hope that your computer manufacturer got the ROM just right before shipping your computer. As [Doug Brown] found out, Apple actually fumbled this with the release of the Macintosh Classic II several decades ago. And yet… the machines worked! That turns out to be due to a rather weird low-level quirk, as recent tinkering in an emulator revealed.

The bug was revealed when [Doug] was experimenting with the emulated Macintosh Classic II in MAME. He was exploring keyboard shortcuts for launching the debugger, but soon found a problem. He needed to load MacsBug to enable the debugging shortcut, and that required the use of 32-bit addressing. However, the emulated system wouldn’t boot in this mode at all, instead landing on a Sad Mac error screen.

Heavy debugging ensued, which makes for great reading if you love to chase problems on an instruction-by-instruction basis. Ultimately, [Doug’s] conclusion was a mindboggling one. He determined that the crash in MAME came down to a difference between the emulator’s behaviour versus the original Motorola 68030 CPU in the Classic II. There was simply a problematic undocumented instruction baked into the ROM. The real CPU runs this undocumented instruction, which modifies a certain register, allowing boot without issue. Meanwhile, the emulated CPU tries to execute the bad instruction, fails to modify the right register, and everything falls in a heap. [Doug] speculates that had the 68030 CPU hadn’t hidden the bug, Apple’s engineers might have found it many years ago. He even proved his theory by whipping up multiple custom ROMs to verify what was going on.

We love it when bugs from decades past rear their heads; we love it even more when they get fixed. If you’re chasing down issues with an Amiga or you’re ironing out the kinks in software for the Acorn Archimedes, be sure to let us know on the tips line.

[via Tom’s Hardware, thanks to Jason Morris for the tip!]

Brush Up On Your Trade Craft With This Tiny FM Bug

April 11, 2025 by Dan Maloney 19 Comments

Would-be spooks and spies, take note: this one-transistor FM transmitter is a circuit you might want to keep in mind for your bugging needs. True, field agents aren’t likely to need to build their own equipment, but how cool a spy would you be if you could?

Luckily, you won’t need too many parts to recreate [Ciprian (YO6DXE)]’s project, most of which could be found in a decently stocked junk bin, or even harvested from e-waste. On the downside, the circuit is pretty fussy, with even minor component value changes causing a major change in center frequency. [Ciprian] had to do a lot of fiddling to get the frequency in the FM band, particularly with the inductor in the LC tank circuit. Even dropping battery voltage shifted the frequency significantly, which required a zener diode to address.

[Ciprian] ran a few tests and managed to get solid copy out to 80 meters range, which is pretty impressive for such a limited circuit. The harmonics, which extend up into the ham bands and possibly beyond, are a bit of a problem; while those could be addressed with a low-pass filter, in practical terms, the power of this little fellow is probably low enough to keep you from getting into serious trouble. Still, it’s best not to push your luck.

While you’re trying your hand at one-transistor circuits, you might want to try [Ciprian]’s one-transistor CW transceiver next.

Continue reading “Brush Up On Your Trade Craft With This Tiny FM Bug” →

A Simple Robot For Learning About Robotics

December 9, 2024 by Lewin Day 6 Comments

Robots are super interesting, but you probably shouldn’t start learning about them with a full-sized industrial SCARA arm or anything. Better to learn with something smaller and simpler to understand. This simple Arduino-powered robot is called Bug, and it aims to be just that.

The design comes to us from [Joshua Stanley]. It’s based around the ubiquitous Arduino Uno, paired with a motor control and I/O shield for more connectivity. The robot uses treads for locomotion—each side has two wheels wrapped in a belt for grip. The robot has a small DC gearmotor driving each belt so it can be driven forwards, backwards, and steered differentially. To perceive the world, it uses an off-the-shelf ultrasonic transceiver module, and an NRF24L01 module for remote control. All this is wrapped up in a basic 3D-printed housing that positions the ultrasonic modules effectively as “eyes” which is kind of cute, all in all.

Despite its small size and simple construction, Bug gets around perfectly well in testing on an outdoor footpath. It even has enough torque to flip itself up at full throttle. For now, [Joshua] notes it’s a glorified remote control car, but he plans to expand it further with more functionality going forward.

We see lots of educational robots around these parts, like this nifty little robot arm. Video after the break.

Continue reading “A Simple Robot For Learning About Robotics” →

Nix + Automated Fuzz Testing Finds Bug In PDF Parser

November 9, 2024 by Donald Papp 4 Comments

[Michael Lynch]’s adventures in configuring Nix to automate fuzz testing is a lot of things all rolled into one. It’s not only a primer on fuzz testing (a method of finding bugs) but it’s also a how-to on automating the setup using Nix (which is a lot of things, including a kind of package manager) as well as useful info on effectively automating software processes.

[Michael] not only walks through how he got it all up and running in a simplified and usefully-portable way, but he actually found a buffer overflow in pdftotext in the process! (Turns out someone else had reported the same bug a few weeks before he found it, but it demonstrates everything regardless.)

[Michael] chose fuzz testing because using it to find security vulnerabilities is conceptually simple, actually doing it tends to require setting up a test environment with a complex workflow and a lot of dependencies. The result has a high degree of task specificity, and isn’t very portable or reusable. Nix allowed him to really simplify the process while also making it more adaptable. Be sure to check out part two, which goes into detail about how exactly one goes from discovering an input that crashes a program to tracking down (and patching) the reason it happened.

Making fuzz testing easier (and in a sense, cheaper) is something people have been interested in for a long time, even going so far as to see whether pressing a stack of single-board computers into service as dedicated fuzz testers made economic sense.

Bats Can No Longer Haunt Apple VR Headsets Via Web Exploit

June 26, 2024 by Donald Papp 33 Comments

Bug reporting doesn’t usually have a lot of visuals. Not so with the visionOS bug [Ryan Pickren] found, which fills a user’s area with screeching bats after visiting a malicious website. Even better, closing the browser doesn’t get rid of them! Better still? Doesn’t need to be bats, it could be spiders. Fun!

The bug has been fixed, but here’s how it worked: the Safari browser build for visionOS allowed a malicious website to fill the user’s 3D space with animated objects without interaction or permission. The code to trigger this is remarkably succinct, and is actually a new twist on an old feature: Apple AR Quick Look, an HTML-based feature for rendering 3D augmented reality content in Safari.

Leveraging this old feature is what lets an untrusted website launch an arbitrary number of animated 3D objects — complete with sound — into a user’s virtual space without any interaction from the user whatsoever. The icing on the cake is that Quick Look is a separate process, so closing Safari doesn’t get rid of the pests.

Providing immersive 3D via a web browser is a valuable way to deliver interactive content on both desktops and VR headsets; a good example is the fantastic virtual BBC Micro which uses WebXR. But on the Apple Vision Pro the user is always involved and there are privacy boundaries that corral such content. Things being launched into a user’s space in an interaction-free way is certainly not intended behavior.

The final interesting bit about this bug (or loophole) was that in a way, it defied easy classification and highlights a new sort of issue. While it seems obvious from a user experience and interface perspective that a random website spawning screeching crawlies into one’s personal space is not ideal, is this a denial-of-service issue? A privilege escalation that technically isn’t? It’s certainly unexpected behavior, but that doesn’t really capture the potential psychological impact such bugs can have. Perhaps the invasion of personal space and user boundaries will become a quantifiable aspect of bugs in these new platforms. What fun.

Hackaday Links: June 23, 2024

June 23, 2024 by Dan Maloney 9 Comments

When a ransomware attack targets something like a hospital, it quickly becomes a high-profile event that understandably results in public outrage. Hospitals are supposed to be backstops for society, a place to go when it all goes wrong, and paralyzing their operations for monetary gain by taking over their information systems is just beyond the pale. Tactically, though, it makes sense; their unique position in society seems to make it more likely that they’ll pay up.

Which is why the ongoing cyberattack against car dealerships is a little perplexing — can you think of a less sympathetic victim apart from perhaps the Internal Revenue Service? Then again, we’re not in the ransomware business, so maybe this attack makes good financial sense. And really, judging by the business model of the primary target of these attacks, a company called CDK Global, it was probably a smart move. We had no idea that there was such a thing as a “Dealer Management System” that takes care of everything from financing to service, and that shutting down one company’s system could cripple an entire industry, but there it is.

Continue reading “Hackaday Links: June 23, 2024” →

Chip Mystery: The Case Of The Purloined Pin

April 25, 2024 by Dan Maloney 29 Comments

Let’s face it — electronics are hard. Difficult concepts, tiny parts, inscrutable datasheets, and a hundred other factors make it easy to screw up in new and exciting ways. Sometimes the Magic Smoke is released, but more often things just don’t work even though they absolutely should, and no amount of banging your head on the bench seems to change things.

It’s at times like this that one questions their sanity, as [Gili Yankovitch] probably did when he discovered that not all CH32V003s are created equal. In an attempt to recreate the Linux-on-a-microcontroller project, [Gili] decided to go with the A4M6 variant of the dirt-cheap RISC-V microcontroller. This variant lives in a SOP16 package, which makes soldering a bit easier than either of the 20-pin versions, which come in either QFN or TSSOP packages.

Wisely checking the datasheet before proceeding, [Gili] was surprised and alarmed that the clock line for the SPI interface didn’t appear to be bonded out to a pin. Not believing his eyes, he turned to the ultimate source of truth and knowledge, where pretty much everyone came to the same conclusion: the vendor done screwed up.

Now, is this a bug, or is this a feature? Opinions will vary, of course. We assume that the company will claim it’s intentional to provide only two of the three pins needed to support a critical interface, while every end user who gets tripped up by this will certainly consider it a mistake. But forewarned is forearmed, as they say, and hats off to [Gili] for taking one for the team and letting the community know.