Showing a Raspberry Pi 4 board connected to an ESP32 devboard using jumper wires for the purposes of this project

ESP-Hosted Turns ESP32 Into Linux WiFi/BT Adapter

While we are used to USB WiFi adapters, embedded devices typically use SDIO WiFi cards, and for good reasons – they’re way more low-power, don’t take up a USB port, don’t require a power-sipping USB hub, and the SDIO interface is widely available. However, SDIO cards and modules tend to be obscure and proprietary beyond reason. Enter ESP-Hosted – Espressif’s firmware and driver combination for ESP32 (press release)(GitHub), making your ESP32 into a WiFi module for either your Linux computer (ESP-Hosted-NG) or MCU (ESP-Hosted-FG). In particular, ESP-Hosted-NG his turns your SPI- or SDIO-connected ESP32 (including -S2/S3/C2/C3/C6 into a WiFi card, quite speedy and natively supported by the Linux network stack, as opposed to something like an AT command mode.

We’ve seen this done with ESP8266 before – repurposing an ESP8089 driver from sources found online, making an ESP8266 into a $2 WiFi adapter for something like a Pi. The ESP-Hosted project is Espressif-supported, and it works on the entire ESP32 lineup, through an SDIO or even SPI interface! It supports 802.11b/g/n and even Bluetooth, up to BLE5, either over an extra UART channel or the same SDIO/SPI channel; you can even get BT audio over I2S. If you have an SPI/SDIO port free and an ESP32 module handy, this might just be the perfect WiFi card for your Linux project!

There are some limitations – for instance, you can’t do AP mode in the NG (Linux-compatible) version. Also, part of the firmware has blobs in it, but a lot of the firmware and all of the driver are modifiable in case you need your ESP32 to do even more than Espressif has coded in – this is not fully open-source firmware, but it’s definitely way more than the Broadcom’s proprietary onboard Raspberry Pi WiFi chip. There’s plenty of documentation, and even some fun features like raw transport layer access. Also, of note is that this project supports ESP32-C6, which means you can equip your project with a RISC-V-based WiFi adapter.

Title image from [zhichunlee].

Harmonic Table Keyboard Brings Old Idea Back To Life

If you missed the introduction of the Axis-49 and Axis-64 keyboards by C-Thru Music, you’re definitely not alone. At the time it was a new musical instrument that was based on the harmonic table, but it launched during the Great Recession and due to its nontraditional nature and poor timing, the company went out of business. But the harmonic table layout has a number advantages for musicians over other keyboard layouts, so [Ben] has brought his own version of the unique instrument to life in his latest project.

Called the Midihex, the keyboard has a number of improvements over the version from C-Thru Music, most obviously its much larger 98 playable keys and five function keys. The keys themselves are similar to Cherry MX keys but which use Hall-effect sensors. This style of key allows the device to send continuous key position information to the host computer, and since this is a MIDI instrument, this capability allows it to support a MIDI protocol called MIDI Polyphonic Expression (MPE) which allows each note to be more finely controlled by the musician than a standard MIDI instrument. The PCB is powered by a Teensy 4.1 at the core.

For any musicians that haven’t tried out a harmonic table before, an instrument like this might be worth trying out. The layout provides easier chord and scale patterns, and for beginner musicians it can have a much shallower learning curve than other types of instruments. If you can’t find an original Axis-49 or Axis-64 anywhere to try out, though, we actually posted a teardown of one way back in 2009 when the company was still producing instruments.

Continue reading “Harmonic Table Keyboard Brings Old Idea Back To Life”

the Logitech receiver in question next to the mouse it's paired to

Uncovering Secrets Of Logitech M185’s Dongle

[endes0] has been hacking with USB HID recently, and a Logitech M185 mouse’s USB receiver has fallen into their hands. Unlike many Logitech mice, this one doesn’t include a Unifying receiver, though it’s capable of pairing to one. Instead, it comes with a pre-paired CU0019 receiver that, it turns out, is based on a fairly obscure TC32 chipset by Telink, the kind we’ve seen in cheap smart wristbands. If you’re dealing with a similarly obscure MCU, how do you even proceed?

In this case, GitHub had a good few tools developed by other hackers earlier — a Ghidra integration, and a tool for working with the MCU using a USB-UART and a single resistor. Unfortunately, dumping memory through the MCU’s interface was unreliable and frustrating. So it was time to celebrate when fuzzing the HID endpoints uncovered a memory dump exploit, with the memory dumper code helpfully shared in the blog post.

From a memory dump, the exploration truly began — [endes0] uncovers a fair bit of dongle’s inner workings, including a guess on which project it was based on, and even a command putting the dongle into a debug mode where a TC32-compatible debugger puts this dongle fully under your control.

Yet another hands-on course on Ghidra, and a wonderful primer on mouse dongle hacking – after all, if you treat your mouse’s dongle as a development platform, you can easily do things like controlling a small quadcopter, or pair the dongle with a SNES gamepad, or build a nifty wearable.

We thank [adistuder] for sharing this with us!

Reverse-Engineering Makita Batteries To Revive Them

Modern lithium-ion battery packs for cordless power tools contain an incredible amount of energy, which necessitates that they come with a range of safeties. Although it’s good when the battery management system (BMS) detects a fault and cuts power to prevent issues, there exist the possibility of false positives. Having an expensive battery pack brick itself for no good reason is rather annoying, as is being unable to reuse a BMS in for example a re-manufactured battery. This was the reasoning that led [Martin Jansson] down the path of reverse-engineering Makita batteries for starters.

After that initial reverse-engineering attempt involving a firmware dump of the NEC (Renesas) F0513 MCU, [Martin] didn’t get back to the project until recently, when he was contacted by [Romain] who donated a few BMS boards to the cause. One of these features an STM32 MCU, which made the task much easier. Ultimately [Martin] was able to determine the command set for the Maxim OneWire-based communication protocol, as was a hidden UART mode.

Due to the critical timing required, off-the-shelf programmers didn’t work, so an Arduino Uno-based programmer (ArduinoOBI) was created instead, which can be found on GitHub along with the Open Battery Information desktop application which provides access to these BMS features after connecting to the battery pack. Although only Makita is supported right now, [Martin] would like to see support for other brands being added as well.

A Super-Simple Standalone WSPR Beacon

We’ve said it before and we’ll say it again: being able to build your own radios is the best thing about being an amateur radio operator. Especially low-power transmitters; there’s just something about having the know-how to put something on the air that’ll reach across the planet on a power budget measured in milliwatts.

This standalone WSPR beacon is a perfect example. If you haven’t been following along, WSPR stands for “weak-signal propagation reporter,” and it’s a digital mode geared for exploring propagation that uses special DSP algorithms to decode signals that are far, far down into the weeds; signal-to-noise ratios of -28 dBm are possible with WSPR.

Because of the digital nature of WSPR encoding and the low-power nature of the mode, [IgrikXD] chose to build a standalone WSPR beacon around an ATMega328. The indispensable Si5351 programmable clock generator forms the RF oscillator, the output of which is amplified by a single JFET transistor. Because timing is everything in the WSPR protocol, the beacon also sports a GPS receiver, ensuring that signals are sent only and exactly on the even-numbered minutes. This is a nice touch and one that our similar but simpler WSPR beacon lacked.

This beacon had us beat on performance, too. [IgrikXD] managed to hit Texas and Colorado from the edge of the North Sea on several bands, which isn’t too shabby at all with a fraction of a watt.

Thanks to [STR-Alorman] for the tip.

[via r/amateurradio]

Displays We Love Hacking: DSI

We would not be surprised if DSI screens made up the majority of screens on our planet at this moment in time. If you own a smartphone, there’s a 99.9% chance its screen is DSI. Tablets are likely to use DSI too, unless it’s eDP instead, and a smartwatch of yours definitely will. In a way, DSI displays are inescapable.

This is for a good reason. The DSI interface is a mainstay in SoCs and mobile CPUs worth their salt, it allows for higher speeds and thus higher resolutions than SPI ever could achieve, comparably few pins, an ability to send commands to the display’s controller unlike LVDS or eDP, and staying low power while doing all of it.

There’s money and power in hacking on DSI – an ability to equip your devices with screens that can’t be reused otherwise, building cooler and cooler stuff, tapping into sources of cheap phone displays. What’s more, it’s a comparably underexplored field, too. Let’s waste no time, then!

Decently Similar Internals

DSI is an interface defined by the MIPI Alliance, a group whose standards are not entirely open. Still, nothing is truly new under the sun, and DSI shares a lot of concepts with interfaces we’re used to. For a start, if you remember DisplayPort internals, there are similarities. When it comes to data lanes, DSI can have one, two or four lanes of a high-speed data stream; smaller displays can subsist with a single-lane, while very high resolution displays will want all four. This is where the similarities end. There’s no AUX to talk to the display controller, though – instead, the data lanes switch between two modes.

Continue reading “Displays We Love Hacking: DSI”

This Week In Security: Recall, Modem Mysteries, And Flipping Pages

Microsoft is racing to get into the AI game as part of Windows 11 on ARM, calling it Copilot+. It’s an odd decision, but clearly aimed at competing with the Apple M series of MacBooks. Our focus of interest today is Recall, a Copilot+ feature that not only has some security problems, but also triggers a sort of visceral response from regular people: My computer is spying on me? Eww.

Yes, it really sort of is. Recall is a scheme to take screen shots of the computer display every few seconds, run them through character recognition, and store the screenshots and results in a database on the local machine hard drive. There are ways this could be useful. Can’t remember what website had that recipe you saw? Want to revisit a now-deleted tweet? Is your Google-fu failing you to find a news story you read last week? Recall saw it, and Recall remembers. But what else did Recall see? Every video you watched, ever website you visited, and probably some passwords and usernames you typed in.

Continue reading “This Week In Security: Recall, Modem Mysteries, And Flipping Pages”