A render of the Melodio Self Mate music player with it's front plate removed. It's a grey device with a small screen and navigation wheel, similar to a chunky iPod. It has an IR blaster LED in the top and various exposed screw holes letting everyone know that this is a device you can open.

Melodio Self Mate

While the proliferation of the smartphone has caused the personal music player (PMP) market to mostly evaporate, there are still those who prefer a standalone device for their music. The Melodio Self-Mate is one such spiritual successor to the iPod.

Music-only devices really benefit from the wheel interface pioneered by Apple, so we still see it in many of the new Open Source PMPs including this one and the Tangara. The Melodio uses the ubiquitous ESP32 for its brains coupled with a TI PCM5102A DAC and TI TPA6130A2 headphone amp for audio. A slider on the side of the device allows you to switch it between mass storage mode and programming mode for the ESP32.

Since this device packs a little more horsepower and connectivity than the original iPods, things like listening to Spotify are doable once assembled, instead of having to completely rebuild the device. Speaking of building, there are only renders on the GitHub, so we’re not sure if this project has made the jump IRL yet. With more people concerned about the distractions of smartphones, maybe this renaissance of open PMPs will lead to a new golden age of music on the go?

Miss the halcyon days of the iPod? They’re easier to hack now than ever, and if you really want to go old school, how about a podcast on a floppy?

IoT Air Purifier Makes A Great Case Study In Reverse Engineering

Here at Hackaday, about the only thing we like more than writing up tales of reverse engineering heroics is writing up tales of reverse engineering heroics that succeed in jailbreaking expensive widgets from their needless IoT dependency. It’s got a real “stick it to the man” vibe that’s hard to resist.

The thing is, we rarely see a reverse engineering write-up as thorough as the one [James Warner] did while integrating an IoT air purifier into Home Assistant, so we just had to make sure we called this one out. Buckle up; it’s a long, detailed post that really gets down into the weeds, but not unnecessarily so. [James] doesn’t cloud-shame the appliance manufacturer, so we can’t be sure who built this, but it’s someone who thought it’d be a swell idea to make the thing completely dependent on their servers for remote control via smartphone. The reverse engineering effort started with a quick look at the phone app, but when that didn’t pay off in any useful way, [James] started snooping on what the device was talking about using Wireshark.

One thing led to another, wires were soldered to the serial pins on the ESP32 on the purifier’s main board, and with the help of a FlipperZero as a UART bridge, the firmware was soon in hand. This gave [James] clues about the filesystem, which led to a whole Ghidra side quest into learning how to flash the firmware. [James] then dug into the meat of the problem: figuring out the packet structure used to talk to the server, and getting the private key used to encrypt the packets. This allowed a classic man-in-the-middle attack to figure out the contents of each packet and eventually, an MQTT bridge to let Home Assistant control the purifier.

If it sounds like we glossed over a lot, we know — this article is like a master class on reverse engineering. [James] pulled a lot of tools out of his kit for this, and the write-up is clear and concise. You may not have the same mystery fan to work with, but this would be a great place to start reverse engineering just about anything.

Thanks to [ThoriumBR] for the tip.

A General-Purpose PID Controller

For those new to fields like robotics or aerospace, it can seem at first glance that a problem like moving a robot arm or flying an RC airplane might be simple problems to solve. It turns out, however, that control of systems like these can get complicated quickly; so much so that these types of problems have spawned their own dedicated branch of engineering. As controls engineers delve into this field, one of their initial encounters with a control system is often with the PID controller, and this open source project delivers two of these general-purpose controllers in one box.

The dual-channel PID controller was originally meant as a humidity and temperature controller and was based on existing software for an ATmega328. But after years of tinkering, adding new features, and moving the controller to an ESP32 platform, [knifter] has essentially a brand new piece of software for this controller. Configuring the controller itself is done before the software is compiled, and it includes a GUI since one of the design goals of the project was ease-of-use. He’s used it to control humidity, temperature and CO2 levels in his own work at the University of Amsterdam, but imagines that it could see further use outside of his use cases in things like reflow ovens which need simple on/off control or for motors which can be controlled through an H-bridge.

The PID controller itself seems fairly robust, and includes a number of features that seasoned controls engineers would look for in their PID controllers. There are additionally some other open-source PID controllers to take a look at like this one built for an Arduino, and if you’re still looking for interesting use cases for these types of controllers one of our favorites is this PID controller built into a charcoal grill.

Alarm Panel Hack Defeats Encryption By Ignoring It

As frustrating as it may be for a company to lock you into its ecosystem by encrypting their protocols, you have to admit that it presents an enticing challenge. Cracking encryption can be more trouble than it’s worth, though, especially when a device gives you all the tools you need to do an end-run around their encryption.

We’ll explain. For [Valdez], the encrypted communication protocols between a DSC alarm panel and the control pads on the system were serious impediments to integration into Home Assistant. While there are integrations available for these alarm panels, they rely on third-party clouds, which means that not only is your security system potentially telling another computer all your juicy details, but there’s also the very real possibility that the cloud system can either break or be shut down; remember the Chamberlain MyQ fiasco?

With these facts in mind, [Valdez] came up with a clever workaround to DSC encryption by focusing on physically interfacing with the keypad. The device has a common 16×2 LCD and a 25-key keypad, and a little poking around with a multimeter and a $20 logic analyzer eventually showed that the LCD had an HD44780 controller, and revealed all the lines needed to decode the display with an ESP32. Next up was interfacing with the keypad, which also involved a little multimeter work to determine that the keys were hooked up in a 5×5 matrix. Ten GPIOs on the ESP32 made it possible to virtually push any key; however, the ten relays [Valdez] originally used to do the switching proved unwieldy. That led to an optocoupler design, sadly not as clicky but certainly more compact and streamlined, and enabling complete control over the alarm system from Home Assistant.

We love this solution because, as [Valdez] aptly points out, the weakest point in any system is the place where it can’t be encrypted. Information has to flow between the user and the control panel, and by providing the electronic equivalents to eyes and fingers, the underlying encryption is moot. Hats off to [Valdez] for an excellent hack, and for sharing the wealth with the HA community.

Breaking The Flash Encryption Feature Of Espressif’s Microcontrollers

Espressif’s ESP32 microcontrollers come with a Flash encryption feature that when enabled ensures that the data and code stored on the (usually external) Flash chip is encrypted with AES-256 (ESP32) or better (ESP32-C3, -C6). For the ESP32 this encryption feature has been shown to be vulnerable to side channel attacks (SCA), leading [courk] to not only replicate this result with a custom ESP Correlation Power Analysis (CPA) board (pictured) that captures power usage of the MCU, but also to try his luck with the ESP32-C3 and ESP32-C6 parts that should be tougher nuts to crack.

Whereas the ESP32 uses a fairly straightforward AES-256 encryption routine that together with the exposed Flash communication lines on the QSPI bus make for a textbook SCA example, the ESP32-C3 ups the encryption to XTS-AES, which uses two 128-bit keys on the -C3 part (XTS-256). This particular MCU is still susceptible to the same SCA attack with CPA, making it somewhat harder to attack than the ESP32, but by no means impossible.

Continue reading “Breaking The Flash Encryption Feature Of Espressif’s Microcontrollers”

Reverse-Engineering The ESP32’s WiFi Binary Blob With A Faraday Cage

The Faraday cage constructed by Jasper Devreker.
The Faraday cage constructed by Jasper Devreker.

As part of a team reverse-engineering the binary blob driver for the ESP32’s WiFi feature at Ghent University, [Jasper Devreker] saw himself faced with the need to better isolate the network packets coming from the ESP32-under-test. This is a tough call in today’s WiFi and 2.4 GHz flooded airwaves. To eliminate all this noise, [Jasper] had to build a Faraday cage, but ideally without racking up a massive invoice and/or relying on second-hand parts scavenged from eBay.

We previously reported on this reverse-engineering project, which has since seen an update. Although progress has been made, filtering out just the packets they were interested in was a big challenge. The solution was a Faraday cage, but on a tight budget.

Rather than relying on exotic power filters, [Jasper] put a battery inside a Faraday cage he constructed out of wood and conductive fabric. To get Ethernet data in and out, a fiber link was used inside a copper tube. Initial testing was done using a Raspberry Pi running usbip and a WiFi dongle.  The Faraday cage provided enough attenuation that the dongle couldn’t pick up any external WiFi signals in listening mode.

The total cost of this build came down to a hair over €291, which makes it feasible for a lot of RF experiments by hobbyists and others. We wish [Jasper] and the rest of the team a lot of luck in figuring out the remaining secrets of Espressif’s binary WiFi blob using this new tool.

No DAC? Try PDM

Ever notice that the ESP32-S3 doesn’t have a digital-to-analog converter? [Chris] did and asserts that he doesn’t care because he can just use the PDM system to get the same result. PDM — pulse density modulation — is similar to PWM and, like PWM, requires a filter that could range from a simple RC network to an active filter. You can see the result in the video below.

There are several ways [Chris] could produce the output he wanted. PWM was one choice, and some example code uses a timer to do PDM. However, that is not very efficient. The other alternative is to use the I2S output. However, this does require a few workarounds.

In particular, the I2S output is always stereo and incorporates a clock output that isn’t needed for this application. [Chris] simply output the same value on both channels and routed the clock to some pins that are normally used for startup options. That means they can’t easily be used for your own inputs, but it’s OK to use them for unimportant outputs.

We always enjoy seeing solutions like this because it can give you ideas for use in your own projects. Of course, this won’t apply to every project where you need a DAC, but it still might give you some ideas.

We have looked at PDM before. You could, too, build your own DAC hardware.

Continue reading “No DAC? Try PDM”