Software Hacks Unlock Cheap Spectrometer

A spectrometer is one of those tools that many of us would love to have, but just can’t justify the price of. Sure there are some DIY options out there, but few of them have the convenience or capability of what’s on the commercial market. [Chris] from Zoid Technology recently found a portable spectrometer complete with Android application for just $150 USD on AliExpress which looked very promising…at least at first.

The problem is that the manufacturer, Torch Bearer, offers more expensive models of this spectrometer. In an effort to push users into those higher-priced models, arbitrary features such as data export are blocked in the software. [Chris] first thought he could get around this by reverse engineering the serial data coming from the device (interestingly, the spectrometer ships with a USB-to-serial adapter), but while he got some promising early results, he found that the actual spectrometer data was obfuscated — a graph of the results looked like stacks of LEGOs.

Continue reading “Software Hacks Unlock Cheap Spectrometer”

I2C Sniffing Comes To The Bus Pirate 5

While the Bus Pirate 5 is an impressive piece of hardware, the software is arguably where the project really shines. Creator [Ian Lesnet] and several members of the community are constantly working to add new features and capabilities to the hardware hacking multi-tool, to the point that if your firmware is more than a few days old there’s an excellent chance there’s a fresher build available for you to try out.

One of the biggest additions from the last week or so of development has been the I2C sniffer — a valuable tool for troubleshooting or reverse engineering devices using the popular communications protocol. [Ian] has posted a brief demo video of it in action.

It’s actually a capability that was available in the “classic” versions of the Bus Pirate, but rather than porting the feature over from the old firmware, [Ian] decided to fold the MIT licensed pico_i2c_sniffer from [Juan Schiavoni] into the new codebase. Thanks to the RP2040’s PIO, the sniffer works at up to 500 kHz, significantly outperforming its predecessor.

Admittedly, I2C sniffing isn’t anything you couldn’t do with a cheap logic analyzer. But that means dealing with captures and making sure the protocol decoder is setup properly, among other bits of software tedium. In comparison, once you start the sniffer program on the Bus Pirate 5, I2C data will be dumped out to the terminal in real-time for as long as you care to see it. For reverse engineering, it’s also very easy to move quickly from sniffing I2C packets to replaying or modifying them within the Bus Pirate’s interface.

If you already have a Bus Pirate 5, all you need to do is flash the latest firmware from the automated build system, and get sniffing. On the fence about picking one up? Perhaps our hands-on review will help change your mind.

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!