Reggaeton-Be-Gone Disconnects Obnoxious Bluetooth Speakers

If you’re currently living outside of a Spanish-speaking country, it’s possible you’ve only heard of the music genre Reggaeton in passing, if at all. In places with large Spanish populations, though, it would be more surprising if you hadn’t heard it. It’s so popular especially in the Carribean and Latin America that it’s gotten on the nerves of some, most notably [Roni] whose neighbor might not do anything else but listen to this style of music, which can be heard through the walls. To solve the problem [Roni] is now introducing the Reggaeton-Be-Gone. (Google Translate from Spanish)

Inspired by the TV-B-Gone devices which purported to be able to turn off annoying TVs in bars, restaurants, and other places, this device can listen to music being played in the surrounding area and identify whether or not it is hearing Reggaeton. It does this using machine learning, taking samples of the audio it hears and making decisions based on a trained model. When the software, running on a Raspberry Pi, makes a positive identification of one of these songs, it looks for Bluetooth devices in the area and attempts to communicate with them in a number of ways, hopefully rapidly enough to disrupt their intended connections.

In testing with [Roni]’s neighbor, the device seems to show promise although it doesn’t completely disconnect the speaker from its host, instead only interfering with it enough for the neighbor to change locations. Clearly it merits further testing, and possibly other models trained for people who use Bluetooth speakers when skiing, hiking, or working out. Eventually the code will be posted to this GitHub page, but until then it’s not the only way to interfere with your neighbor’s annoying stereo.

Thanks to [BaldPower] and [Alfredo] for the tips!

Diagram from the blog post, showing how GATT communication capture works

Hacking BLE To Liberate Your Exercise Equipment

It’s a story we’ve heard many times before: if you want to get your data from the Domyos EL500 elliptical trainer, you need to use a proprietary smartphone application that talks to the device over Bluetooth Low-Energy (BLE). To add insult to injury, the only way to the software will export your workout information is by producing a JPG image of a graph. This just won’t do, so [Juan Carlos Jiménez] gives us yet another extensive write-up, which provides an excellent introduction to practical BLE hacking.

He walks us through BLE GATT (Generic Attribute Profile), the most common way such devices work, different stages of the connection process, and the tools you can use for sniffing an active connection. Then [Juan] shows us a few captured messages, how to figure out packet types, and moves into the tastiest part — using an ESP32 to man-in-the-middle (MITM) the connection.

Continue reading “Hacking BLE To Liberate Your Exercise Equipment”

A 360° View Of A Classic Drive-In Speaker

Readers of a certain vintage no doubt have pleasant memories of drive-in theaters, and we are chuffed to see that a few hundred of these cinematic institutions endure today. While most theaters broadcast the audio on an FM station these days, the choice is still yours to use the chunky, often crackly speaker that attaches to the car window.

Seeking to relive the drive-in audio experience at home, [codemakesitgo] picked up a drive-in theater speaker on eBay and turned it into a Bluetooth device that sounds much better than it did in its weather-beaten days outside.

There isn’t a whole lot to this build — it’s essentially a new speaker cone, a Bluetooth receiver, an amp, and a battery. The real story is in the way that [codemakesitgo] uses Fusion360 to bring it all together.

After 3D scanning the case, [codemakesitgo] made sure each piece would fit, using a custom-built model of the new speaker and a 3D model of a custom PCB. Good thing, too, because there is barely enough clearance for the speaker. Be sure to check out the brief demo video after the break.

Continue reading “A 360° View Of A Classic Drive-In Speaker”

The Dark Side Of Hacking XMas Lights, Literally

When looking at the piles of cheap RGB, Bluetooth-controlled LED strips you can find for sale just about anywhere these days, integrating them into a home-automation setup is very tempting. Normally these strips are controlled via a special smartphone app, that speaks whatever dodgy protocol was thrown together for the LED strip controller in question. Reverse-engineering this Bluetooth protocol is fairly easy these days, as [Will Cooke] describes in a recent tutorial, although for him there was a bit of a tragic ending with one particular RGB set.

With previous experiences reverse-engineering the Bluetooth protocol with Wireshark under his belt and having published the BJ_LED repository for LED strips that use the MohuanLED app, reverse-engineering this new LED strip with the associated “iDeal LED” app seemed fairly routine. Initially it was indeed routine, with just a curveball in the form of some encryption that the Jadx decompiler used on the app couldn’t help with. Fortunately the key ended up floating around on the internet, and the protocol was wide open. That’s when disaster struck.

While trying to throw payloads at the LED controller to find hidden modes and settings, [Will] found that he could indeed increase the brightness beyond what the app supported, but poking at lighting modes beyond the 10 presets gave a nasty shock. Modes 1 through 10 worked fine, 11 also did something new, but when the controller was asked to switch to mode 12, it shut off. Permanently. Whether this corrupted the firmware or caused some other issue is unknown, but it’s a clear warning that reverse-engineering comes with potentially fried hardware.

We hope that [Will] can get an autopsy performed on this controller to see the cause of this seemingly permanent failure that persisted across hard resets and disconnecting from power overnight. The protocol for this controller has been published on GitHub for those who’d like to take their chances.

LED lights: LadyAda, CC BY-SA 4.0.

Bluetooth As Proxy For Occupancy

During [Matt]’s first year of college, he found in a roundabout way that he could avoid crowds in the dining hall by accessing publicly available occupancy data that the dining hall collected. Presumably this was data for the dining hall to use internally, but with the right API calls anyone could use the information to figure out the best times to eat. But when the dining hall switched providers, this information feed disappeared. Instead of resigning himself to live in a world without real-time data on the state of the dining hall, he recreated the way the original provider counted occupancy: by using Bluetooth as a proxy for occupancy.

Bluetooth devices like smartphones, fitness sensors, and other peripherals often send out advertising packets into the aether, to alert other devices to their presence and help initiate connections between devices. By sniffing these advertising packets, it’s possible to get a rough estimate of the number of people in one particular place, assuming most people in the area will be carrying a smartphone or something of that nature. [Matt]’s Bluetooth-sniffing device is based on the ESP32 set up to simply count the number of unique devices it finds. He had some trouble with large crowds, though, as the first ESP32 device he chose didn’t have enough RAM to store more than a few hundred IDs and would crash once the memory filled. Switching to a more robust module seems to have solved that issue, and with a few rounds of testing he has a workable prototype that can run for long periods and log at least as many Bluetooth devices passing by as there are within its range.

While [Matt] hasn’t deployed this to the dining hall yet, with this framework in place most of the work has been done that, at least in theory, one of these modules could be easily placed anywhere someone was interested in collecting occupancy data. He has plans to submit his project to the university, to research the topic further, and potentially sell these to businesses interested in that kind of data. This isn’t an idea limited to the ESP32, either. We’ve seen similar projects built using the Raspberry Pi’s wireless capabilities that perform similar tasks as this one.

Thanks to [Adrian] for the tip!

Update On The BLUFFS Bluetooth Vulnerability

As we first reported in yesterday’s weekly security post, researchers at EURECOM have revealed the details (PDF, references) of a new man-in-the-middle (MITM) attack on Bluetooth 4.2 through 5.4, which has been assigned CVE-2023-24023. Like preceding CVEs, it concerns the session authentication between Bluetooth devices, where the attacker uses spoofed paired or bonded devices to force the use of a much shorter encryption key length.

The name of this newly discovered vulnerability is BLUFFS (Bluetooth Forward and Future Secrecy), where forward and future secrecy are important terms that refer to the protection of secure sessions against compromise in the past (forward, FoS) and future (FuS). The CVE presentation notes that the Bluetooth specification does not cover either FuS or FoS. In total two new architectural vulnerabilities were discovered, both of which attack the security key.

The Bluetooth SIG has released a statement regarding this attack method. Although serious, it would seem that the core issue is that some implementations allow for encryption key lengths below 7 octets:

Continue reading “Update On The BLUFFS Bluetooth Vulnerability”

This Week In Security: Owncloud, NXP, 0-Days, And Fingerprints

We’re back! And while the column took a week off for Thanksgiving, the security world didn’t. The most pressing news is an issue in Owncloud, that is already under active exploitation.

The problem is a library that can be convinced to call phpinfo() and include the results in the page response. That function reveals a lot of information about the system Owncloud is running on, including environment variables. In something like a Docker deployment, those environment variables may contain system secrets like admin username and password among others.

Now, there is a bit of a wrinkle here. There is a public exploit, and according to research done by Greynoise Labs, that exploit does not actually work against default installs. This seems to describe the active exploitation attempts, but the researcher that originally found the issue has stated that there is a non-public exploit that does work on default installs. Stay tuned for this other shoe to drop, and update your Owncloud installs if you have them. Continue reading “This Week In Security: Owncloud, NXP, 0-Days, And Fingerprints”