Sit Up Straight!: Open Source Bluetooth Posture Sensing

December 16, 2020 by Danie Conradie 4 Comments

As more and more people spend their working hours behind a computer, bad posture and the accompanying back pain and back problems become a growing epidemic. To combat this in his own daily life, [ImageryEel] made PosturePack, a wearable Bluetooth-enabled posture sensor.

The PosturePack is designed to fit into a small pocket sewn into the pack of an undershirt, between the shoulder blades. It consists of a custom PCB with an ATmega32U4, BNO055 IMU, Bluetooth module, small LiPo and power circuitry. Based on the orientation data from the IMU, a notification is sent over Bluetooth to a smartphone whenever the user hunches forward.

[ImageryEel] says although the mobile notifications worked, haptic feedback integrated into the unit would be a better option. This could also be used to remind the user to stand up and take a break now and then, and provide an alternative to a smartwatch for activity monitoring without sending every movement to someone else’s servers. Software will always be the hardest part for projects like these, especially as the device become “smarter”. Learning to recognize activity and postures is actually a good place for tiny machine learning models.

Compared The posture sensors we covered before had to be installed and set up at a specific workstation, like an ultrasound-based version attached to a chair, and a webcam-based version.

New Part Day: Bouffalo Labs BL602 RISC-V Wi-Fi/Bluetooth SoC

November 20, 2020 by Jenny List 20 Comments

We should all by now be used to microcontrollers with wireless hardware on board, with Espressif or Nordic Labs dominating the hacker scene. There have been several other contenders in this arena over the years that haven’t really caught the attention of our community, usually because of the opacity of their available information.

A new contender should be worth a second look though. The BL602 from Bouffalo Labs is a Wi-Fi- and Bluetooth LE-capable microcontroller with a 32-bit RISC-V derived core. If that doesn’t interest you much, perhaps news that the PINE64 folks are spearheading an effort to reverse engineer it for a fully open-source blob-free wireless implementation might sharpen your attention.

So where can you get your hands on one? Hold your horses, this chip is at an early stage in its gestation. We can see that there are some exciting possibilities in store, but we’re still figuring out the hardware interfaces and other software required to make it work. A community is hard at work reverse engineering it, which leads us back to the PINE64 story we mentioned earlier.

You can find BL602 modules from AliExpress vendors, but the PINE64 folks will offer you a free one if you join their blob reverse engineering effort. Take note though, this offer is for those prepared to show commitment to the project, so don’t spam them in the hope of free stuff if you won’t be helping deliver the goods.

We might see the BL602 gaining an open-source toolchain and internal blobs over the coming months thanks to the efforts of those working on it. Just as the ESP8266 did back in 2014, it’s starting as a black box with a relative scarcity of information. But if this hacking effort pays off, we’ll have a cheap RISC-V Wi-Fi and Bluetooth module with entirely open-source software from the silicon upwards. What a time to be alive!

Thanks [Renze] for the tip.

Custom Firmware For Cheap Bluetooth Thermometers

November 17, 2020 by Tom Nardi 52 Comments

The Xiaomi LYWSD03MMC temperature and humidity sensor is ridiculously cheap. If you’re buying a few at a time, you can expect to pay as little as $5 USD a pop for these handy Bluetooth Low Energy environmental sensors. Unfortunately, that low price tag comes with a bit of a catch: you can only read the data with the official Xiaomi smartphone application or by linking it to one of the company’s smart home hubs. Or at least, that used to be the case.

Over the past year, [Aaron Christophel] has been working on a replacement firmware for these Xiomi sensors that unlocks the data so you can use it however you see fit. In addition, it allows the user to tweak various features and settings that were previously unavailable. For example, you can disable the little ASCII-art smiley face that usually shows on the LCD to indicate the relative comfort level of the room.

The new firmware publishes the temperature, humidity, and battery level every minute through a BLE advertisement broadcast. In other words, that means client devices can read data from the sensor without having to be paired. Scraping this data is quite simple, and the GitHub page includes a breakdown of what each byte in the broadcast message means. Avoiding direct connections not only makes it easier to quickly read the values from multiple thermometers, but should keep the device’s CR2032 battery going for longer.

But perhaps the most impressive part of this project is how you get the custom firmware installed. You don’t need to crack the case or solder up a programmer. Just load the flasher page on a computer and browser combo that supports Web Bluetooth (a smartphone is probably the best bet), point it to the MAC address of the thermometer you want to flash, and hit the button. [Aaron] is no stranger to developing user-friendly OTA installers for his firmware projects, but even for him, it’s quite impressive.

Continue reading “Custom Firmware For Cheap Bluetooth Thermometers” →

Hackaday Podcast 083: Soooo Many Custom Peripherals, Leaving Bluetooth Footprints, And A Twirlybird On Mars

September 4, 2020 by Mike Szczys 3 Comments

Hackaday editors Mike Szczys and Elliot Williams ogle the greatest hacks from the past 168 hours. Did you know that Mars Rover didn’t get launched into space all alone? Nestled in it’s underbelly is a two-prop helicopter that’s a fascinating study in engineering for a different world. Fingerprinting audio files isn’t a special trick reserved for Shazam, you can do it just as easily with an ESP32. A flaw in the way Bluetooth COVID tracing frameworks chirp out their anonymized hashes means they’re not as perfectly anonymized as planned. And you’re going to love these cool ways to misuse items from those massive parts catalogs.

Take a look at the links below if you want to follow along, and as always, tell us what you think about this episode in the comments!

Direct download (60 MB or so.)

Continue reading “Hackaday Podcast 083: Soooo Many Custom Peripherals, Leaving Bluetooth Footprints, And A Twirlybird On Mars” →

COVID-tracing Framework Privacy Busted By Bluetooth

September 3, 2020 by Elliot Williams 60 Comments

[Serge Vaudenay] and [Martin Vuagnoux] released a video yesterday documenting a privacy-breaking flaw in the Apple/Google COVID-tracing framework, and they’re calling the attack “Little Thumb” after a French children’s story in which a child drops pebbles to be able to retrace his steps. But unlike Hänsel and Gretl with the breadcrumbs, the goal of a privacy preserving framework is to prevent periodic waypoints from allowing you to follow anyone’s phone around. (Video embedded below.)

The Apple/Google framework is, in theory, quite sound. For instance, the system broadcasts hashed, rolling IDs that prevent tracing an individual phone for more than fifteen minutes. And since Bluetooth LE has a unique numeric address for each phone, like a MAC address in other networks, they even thought of changing the Bluetooth address in lock-step to foil would-be trackers. And there’s no difference between theory and practice, in theory.

In practice, [Serge] and [Martin] found that a slight difference in timing between changing the Bluetooth BD_ADDR and changing the COVID-tracing framework’s rolling proximity IDs can create what they are calling “pebbles”: an overlap where the rolling ID has updated but the Bluetooth ID hasn’t yet. Logging these allows one to associate rolling IDs over time. A large network of Bluetooth listeners could then trace people’s movements and possibly attach identities to chains of rolling IDs, breaking one of the framework’s privacy guarantees.

This timing issue only affects some phones, about half of the set that they tested. And of course, it’s only creating a problem for privacy within Bluetooth LE range. But for a system that’s otherwise so well thought out in principle, it’s a flaw that needs fixing.

Why didn’t the researchers submit a patch? They can’t. The Apple/Google code is mostly closed-source, in contrast to the open-source nature of most of the apps that are running on it. This remains troubling, precisely because the difference between the solid theory and the real practice lies exactly in those lines of uninspectable code, and leaves all apps that build upon them vulnerable without any recourse other than “trust us”. We encourage Apple and Google to make the entirety of their COVID framework code open. Bugs would then get found and fixed, faster.

Continue reading “COVID-tracing Framework Privacy Busted By Bluetooth” →

Mobile Transmitter Gets Internal GPS And Bluetooth

August 23, 2020 by Tom Nardi 4 Comments

While [Selim Olcer] was relatively happy with his Kenwood TM-D710a radio, he didn’t like the fact that it needed a bulky external GPS “backpack” for APRS location data. So he decided to crack open the head unit and see if he couldn’t integrate his own GPS hardware (machine translation). Not only did he succeed, but he even threw in Bluetooth compatibility for good measure.

With the repair manual circuit diagrams in hand, it was no problem to find the GPS RX and TX lines that were being broken out to the external connector. Unfortunately, the radio’s electronics are all 5 volts and the GPS module [Selim] wanted to use was only 3.3 V. So he came up with a small PCB that included not only the voltage regulator to power the GPS module, but also some voltage-dividers to level shift those signals.

Since the Kenwood TM-D710a was already designed to accept a GPS upgrade module, he just needed to change some configuration options in the radio’s menus for it to see the new hardware. Technically the project was done at this point, but since there was still room in the case and he had a GPS module spitting out NMEA sentences, [Selim] tacked on a common Bluetooth serial module so he could see the position information on his smartphone. With an application like APRSdroid, he now has a nice moving map display using the position pulled from the radio’s GPS.

With this modification done it looks like the head unit is ready to go, but that’s only the beginning for a mobile rig. Now we want to see how he integrates the whole thing into the car.

This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes

August 21, 2020 by Jonathan Bennett 4 Comments

One of the fun things about vulnerability research is that there are so many places for bugs to hide. Modern devices have multiple processors, bits of radio hardware, and millions of lines of code. When [Veronica Kovah] of Dark Mentor LLC decided to start vulnerability research on the Bluetooth Low Energy protocol, she opted to target the link layer itself, rather than the code stack running as part of the main OS. What’s interesting is that the link layer has to process data before any authentication is performed, so if a vulnerability is found here, it’s guaranteed to be pre-authentication. Also of interest, many different devices are likely to share the same BLE chipset, meaning these vulnerabilities will show up on many different devices. [Veronica] shares some great info on how to get started, as well as the details on the vulnerabilities she found, in the PDF whitepaper. (Just a quick note, this link isn’t to the raw PDF, but pulls up a GitHub PDF viewer.) There is also a video presentation of the findings, if that’s more your speed.

The first vuln we’ll look at is CVE-2019-15948, which affects a handful of Texas Instruments BT/BLE chips. The problem is in how BLE advertisement packets are handled. An advertisement packet should always contain a data length of at least six bytes, which is reserved for the sending device address. Part of the packet parsing process is to subtract six from the packet length and do a memcpy using that value as the length. A malicious packet can have a length of less than six, and the result is that the copy length integer underflows, becoming a large value, and overwriting the current stack. To actually turn this into an exploit, a pair of data packets are sent repeatedly, to put malicious code in the place where program execution will jump to.

The second vulnerability of note, CVE-2020-15531 targets a Silicon Labs BLE chip, and uses malformed extended advertisement packets to trigger a buffer overflow. Specifically, the sent message is longer than the specification says it should be. Rather than drop this malformed message, the chip’s firmware processes it, which triggers a buffer overflow. Going a step further, this chip has non-volatile firmware, and it’s possible to modify that firmware permanently. [Veronica] points out that even embedded chips like these should have some sort of secure boot implementation, to prevent these sort of persistent attacks.
Continue reading “This Week In Security: Bluetooth Hacking, NEC Phones, And Malicious Tor Nodes” →