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

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”

A Die-Level Look At The Pentium FDIV Bug

The early 1990s were an interesting time in the PC world, mainly because PCs were entering the zeitgeist for the first time. This was fueled in part by companies like Intel and AMD going head-to-head in the marketplace with massive ad campaigns to build brand recognition; remember “Intel Inside”?

In 1993, Intel was making some headway in that regard. The splashy launch of their new Pentium chip in 1993 was a huge event. Unfortunately an esoteric bug in the floating-point division module came to the public’s attention. [Ken Shirriff]’s excellent account of that kerfuffle goes into great detail about the discovery of the bug. The issue was discovered by [Dr. Thomas R. Nicely] as he searched for prime numbers. It’s a bit of an understatement to say this bug created a mess for Intel. The really interesting stuff is how the so-called FDIV bug, named after the floating-point division instruction affected, was actually executed in silicon.

We won’t presume to explain it better than [Professor Ken] does, but the gist is that floating-point division in the Pentium relied on a lookup table implemented in a programmable logic array on the chip. The bug was caused by five missing table entries, and [Ken] was able to find the corresponding PLA defects on a decapped Pentium. What’s more, his analysis suggests that Intel’s characterization of the bug as a transcription error is a bit misleading; the pattern of the missing entries in the lookup table is more consistent with a mathematical error in the program that generated the table.

The Pentium bug was a big deal at the time, and in some ways a master class on how not to handle a complex technical problem. To be fair, this was the first time something like this had happened on a global scale, so Intel didn’t really have a playbook to go by. [Ken]’s account of the bug and the dustup surrounding it is first-rate, and if you ever wanted to really understand how floating-point math works in silicon, this is one article you won’t want to miss.

close up hands holding lighting pcb

Circuit Secrets: Exploring A $5 Emergency Light

Who would’ve thought a cheap AliExpress emergency light could be packed with such crafty design choices? Found for about $5, this unit uses simple components yet achieves surprisingly sophisticated behaviors. Its self-latching feature and decisive illumination shut-off are just the beginning. A detailed analysis by [BigCliveDotCom] reveals a smart circuit that defies its humble price.

The circuit operates via a capacitive dropper, a cost-effective way to power low-current devices. What stands out, though, is its self-latching behavior. During a power failure, transistors manage to keep the LEDs illuminated until the battery voltage drops below a precise threshold, avoiding the dreaded fade-to-black. Equally clever is the automatic shut-off when the voltage dips too low, sparing the battery from a full drain.

Modifications are possible, too. For regions with 220V+ mains, swapping the dropper capacitor with a 470nF one can reduce heat dissipation. Replacing the discharge resistor (220k) with a higher value improves longevity by running cooler. What remarkable reverse engineering marvels have you come across? Share it in the comments!  After all, it is fun to hack into consumer stuff. Even if it is just a software hack.

Continue reading “Circuit Secrets: Exploring A $5 Emergency Light”

Stream Deck Plus Reverse Engineered

[Den Delimarsky] had a Stream Deck and wanted to be free of the proprietary software, so he reverse-engineered it. Now, he has a Stream Deck Plus, and with the same desire, he reverse-engineered it as well.

The device has eight buttons, a narrow screen, and four encoder dials. The device looks like a generic HID device to the host machine, and once it has been configured, doesn’t need any special software to function. By configuring the device using the official software in a virtual machine under the watchful eye of Wireshark, it was possible to figure out how that initial setup worked and recreate it using a different software stack.

If you’ve never done this kind of thing before, there is a lot of information about how to find USB data and draw inferences from it. The buttons send messages when pressed, of course. But they also accept a message that tells them what to display on their tiny screen. The device screen itself isn’t very big at 800×100.

[Den] packages everything up in the DeckSurf SDK, an open source project that lets you control Stream Decks. So if you just want to control the Deck, you don’t need to know all these details. But, for us, that’s where the fun is.

Way back in 2015, we covered some guy who had sniffed out a USB signal generator. That was easy since it was a serial port. However, you can go pretty far down the rabbit hole.

Learning About The Flume Water Monitor

The itch to investigate lurks within all us hackers. Sometimes, you just have to pull something apart to learn how it works. [Stephen Crosby] found himself doing just that when he got his hands on a Flume water monitor.

[Stephen] came by the monitor thanks to a city rebate, which lowered the cost of the Flume device. It consists of two main components: a sensor which is strapped to the water meter, and a separate “bridge” device that receives information from the sensor and delivers it to Flume servers via WiFi. There’s a useful API for customers, and it’s even able to integrate with a Home Assistant plugin. [Stephen] hoped to learn more about the device so he could scrape raw data himself, without having to rely on Flume’s servers.

Through his reverse engineering efforts, [Stephen] was able to glean how the system worked. He guides us through the basic components of the battery-powered magnetometer sensor, which senses the motion of metering components in the water meter. He also explains how it communicates with a packet radio module to the main “bridge” device, and elucidates how he came to decompile the bridge’s software.

When he sent this one in, [Stephen] mentioned the considerable effort that went into reverse engineering the system was “a very poor use” of his time — but we’d beg to differ. In our book, taking on a new project is always worthwhile if you learned something along the way. Meanwhile, if you’ve been pulling apart some weird esoteric commercial device, don’t hesitate to let us know what you found!

Unexpectedly Interesting Payphone Gives Up Its Secrets

Reverse engineering a payphone doesn’t sound like a very interesting project, at least in the United States, where payphones were little more than ruggedized versions of residential phones with a coin mechanism attached. Phones in other parts of the world were far more interesting, though, as this look at the mysteries of a payphone from Israel reveals (in Hebrew; English translation here.)

This is a project [Inbar Raz] worked on quite a while ago, but only got around to writing up recently. The payphone in question was sourced from the usual surplus market channels, and appears to have been removed from service by Israeli telecommunications company Bezeq only shortly before he found it. It was in pretty good shape, and was even still locked tight, making some amateur locksmithing the first order of the day. The internals of the phone are surprisingly complex, with a motherboard that looks more like something from a PC. Date codes on the chips and through-hole construction date the device to the early- to mid-1990s.

With physical access gained, [Inbar] turned to the firmware. An Atmel flash chip seemed a good place to look, and indeed he was able to pull code off the chip. That’s where things took a turn thanks to the CPU the code was written for — the CDP1806, a later version of the more popular but still fringe CDP1802. This required [Inbar] to fall down the rabbit hole of writing a new processor definition file for Ghidra so that the firmware could be reverse-engineered. This got him to the point of understanding 1806 assembly well enough that he was able to re-flash the phone to print debugging messages on the built-in 16×2 LCD screen, which allowed him to figure out which routines were being called under various error conditions.

It doesn’t appear that [Inbar] ever completed the reverse engineering project, but as he points out, what does that even mean? He got inside, took a look around, and made the phone do some cool things it couldn’t do before, and in the process made things easier for anyone working with 1806 processors in Ghidra. That’s a pretty complete win in our books.

PlayStation Motherboard Sanded And Scanned, But There’s More To Do

If you want to reverse engineer the boards in a modern console, you’d better have a lab, a lot of fancy gear, and a good few months to dedicate to the task. The humble PlayStation, on the other hand, is more accessible in this regard. [Lawrence Brode] pulled one apart and started documenting it as part of a grander quest for console understanding.

[Lawrence’s] ultimate goal is to create a portable PlayStation using original hardware. That is, rather than cannibalizing an existing console, he wants to build an original portable from scratch. He needed to understand the PlayStation to recreate it, so he started by analyzing the original hardware.

The first part of [Lawrence’s] quest was to try and reverse engineer the PlayStation motherboard itself. The 1990s console has the benefit of only using a two-layer PCB, meaning it’s far easier to trace out than more modern multi-layer designs. [Lawrence] started with a damaged console, pulled out the motherboard, and stripped off all the components. He then cleaned the board, scanned it, and then sandblasted it to remove the solder mask.

He’s begun the work of tracing out signals, and next on the agenda is to create a new custom PCB that’s compatible with the original PlayStation hardware. You can grab his work via GitHub if you’re interested. [Lawrence] is also excited about the possibilities of grabbing the 24-bit RGB signal heading into the GPU and using it for an HDMI output conversion in the future.

It’s always an exciting time in the PlayStation community; we see lots of great hacks on the regular. If you’re cooking up your own, don’t hesitate to drop us a line!