New Bluetooth 5 Channel Hopping Reverse Engineered For Jamming And Hijacking

Bluetooth Low Energy (BLE) 5 has been around since 2016 with the most recent version 5.2 published just this year. There’s not much hardware out there that’s using the new hotness. That didn’t stop [Damien Cauquil] from picking apart BLE 5’s new frequency hopping techniques and updating his BtleJack tool to allow sniffing, jamming and hijacking hardware using the new protocol.

As you can imagine, the BLE standard a complicated beast and just one part of it is the topic here: the PRNG-based frequency hopping scheme that is vastly different from BLE 4.x and earlier. The new standard, called Channel Selection Algorithm (CSA) #2 — uses 65535 possible channels, compared to just 37 channels used by its predecessor. Paired devices agree to follow a randomized list of all possible channels in sequence so that they remain in synchronization between hops. This was put in place to help avoid collisions, making it possible for many more BLE devices to operate in close proximity. This is important to note since it quickly becomes obvious that it’s not a robust security measure by any means.

To begin channel hopping the two devices must first agree on an order in which to hop, ensuring they’ll meet one another after each leap. To do so they both run the same 32-bit seed number through a PRNG algorithm, generating a list that will then be followed exactly in order. But it turns out this is not very difficult to figure out. All that’s needed is the access address whose top 16-bits are publicly available if you’re already sniffing packets, and the bottom 16-bits is the counter that increments the hop address list.

If you want to jam or hijack BLE 5 communication you need to establish which “randomized” channel list is being used, and the value of the counter that serves as an index to this list. To do so, [Damien] sniffs packets on two different channels. These channels will be used over and over again as it loops through the channel list, so calculating how much time occurs between each channel indicates how far apart these channels are on the list.

In practice, [Damien] first implemented a sieve (the same concept as the Sieve of Eratosthenes for finding primes) that starts with a list of all possibilities and removes those that don’t contain a matching timing between the two channels. Keep doing this, and eventually, you’ll whittle your list down to one possible channel order.

This certainly worked, but there were timing issues that sometimes meant you could learn the seed but couldn’t then sync with it after the fact. His second approach uses pattern matching. By measuring hops on 11 consecutive channels, he’s able to synchronize with target devices in a minute or less. From there, jamming or hijacking methods come into play. The randomization of this scheme is really marginal. A more robust technique would have used an internal state in both devices to generate the next hopping channel. This would have been much more difficult for an attacker to figure out. From the device perspective, CSA #2 takes very little computation power which is key for power-sipping IoT devices most often using BLE.

As mentioned before, [Damien] had trouble finding any hardware in the wild using the BLE 5 standard. His proof of concept is built on a pair of nRF52840 development boards. Because it needs more testing, the code hasn’t been merged into the main version of BtleJack, but you can still get it right now by heading over to BtleJack repo on GitHub.

Neat Smart(ish) Watch Build Uses BLE

Digital watches are a pretty neat idea, and are a great way to experiment with designing and building low-power circuits. That’s what [Eric Min] did with this neat smart watch build. It’s based around an nRF52832 SoC that does all of the heavy lifting, including connecting to a smartphone to get the time when the battery is replaced. It also has a decent quantity of blinky LEDs, which is important on any project of this type.

Continue reading “Neat Smart(ish) Watch Build Uses BLE”

Scratch Built Smartwatch Looks Pretty Darn Sharp With 3D Printed Case And Round LCD

These days, if you want a smart watch, you’re spoiled for choice. The major smartphone players all have devices on the market, and there’s plenty of third party manufacturers vying for your dollar, too. You might think it’s impossible achieve the same finish with a 3D printer and a reflow oven, but you’re wrong. [Samson March] didn’t quite fancy something off the shelf, though, and instead build an amazing smartwatch of his own.

The beautiful case is printed in a woodfilled PLA — consisting of 70% plastic and 30% sawdust. This allows it to be sanded and stained for an attractive final product. Printing artifacts actually add to the look here, creating somewhat of a woodgrain effect. There’s a round LCD for a more classical watch look, which displays various graphics and even contact photos for incoming messages. Like most smartwatches on the market, it uses Bluetooth Low Energy for communication, and has a rechargeable lithium battery inside. Estimated battery life is approximately one week, depending on the frequency of use, and the recharging base he fabricated is as beautiful as the watch itself.

It’s a tidy build that shows off [Samson]’s design skills, and files are available on GitHub if you’d like to make your own. Laying out the full design in Fusion 360 prior to the build enabled the watch to be optimized for size constraints, creating an attractive and comfortable piece. With that said, if you’re a fan of a more hardcore electronic aesthetic, perhaps something 8-bit might be more your speed.

[via reddit, thanks to Aliasmk for the tip!]

WOPR: Security Loses Some Of Its Obscurity

As we’ve seen time and time again, the word “hacker” takes on a different meaning depending on who you’re talking to. If you ask the type of person who reads this fine digital publication, they’ll probably tell you that a hacker is somebody who likes to learn how things work and who has a penchant for finding creative solutions to problems. But if you ask the average passerby on the street to describe a hacker, they might imagine somebody wearing a balaclava and pounding away at their laptop in a dimly lit abandoned warehouse. Thanks, Hollywood.

The “Hollywood Hacker” Playset

Naturally, we don’t prescribe to the idea of hackers being digital villains hell-bent on stealing your identity, but we’ll admit that there’s something of rift between what we call hacking versus what happens in the information security realm. If you see mention of Red Teams and Blue Teams on Hackaday, it’s more likely to be in reference to somebody emulating Pokemon on the ESP32 than anything to do with penetration testing. We’re not entirely sure where this fragmentation of the hacking community came from, but it’s definitely pervasive.

In an attempt bridge the gap, the recent WOPR Summit brought together talks and presentations from all sections of the larger hacking world. The goal of the event was to show that the different facets of the community have far more in common than they might realize, and featured a number of talks that truly blurred the lines. The oscilloscope toting crew learned a bit about the covert applications of their gadgets, and the high-level security minded individuals got a good look at how the silicon sausage gets made.

Two of these talks which should particularly resonate with the Hackaday crowd were Charles Sgrillo’s An Introduction to IoT Penetration Testing and Ham Hacks: Breaking into Software Defined Radio by Kelly Albrink. These two presentations dealt with the security implications of many of the technologies we see here at Hackaday on what seems like a daily basis: Bluetooth Low Energy (BLE), Software Defined Radio (SDR), home automation, embedded Linux firmware, etc. Unfortunately, the talks were not recorded for the inaugural WOPR Summit, but both presenters were kind of enough to provide their slides for reference.

Continue reading “WOPR: Security Loses Some Of Its Obscurity”

Lightsaber Uses Pogo Pins To Make Assembly A Breeze

There was an endless supply of fantastic projects at Supercon this year, but one whose fit and finish really stood out was [Scott]’s lightsaber. If you were walking around and saw someone with a very bright RGB device with a chromed-out handle hanging off their belt it was probably this, though it may have been hard to look at directly. On the outside, the saber looks like a well-polished cosplay prop, and it is! But when Scott quickly broke down the device into component pieces it was apparent that extra care had been put into the assembly of the electronics.

Like any good lightsaber replica the blade is lit, and wow is it bright. The construction is fairly simple, it’s a triplet of WS2812B LED strips back to back on a triangular core, mounted inside a translucent polycarbonate tube with a diffuser. Not especially unusual. But the blade can be popped off the hilt at a moments notice for easy transport and storage, so the strips can’t be soldered in. Connectors would have worked, but who wants flying wires when they’re disconnecting their lightsaber blade. The answer? Pogo pins! Scott runs the power, ground, and data lines out of the strips and into a small board with slip ring-style plated rings. On the hilt, there is a matching array of pogo pins to pass along power and data. The data lines from all the strips are tied together minimizing the number of connections to make, and the outer two power rings have more than one pin for better current-carrying capacity. A handy side effect is that there is nowhere on the blade where there aren’t LEDs; the strips go down to the very end of the blade where it meets the main board inside the hilt.

The hilt is filled with an assembly of 18650’s and a Teensy mounted with a custom shield, all fit inside a printed midframe. The whole build is all about robust design that’s easy to assemble. The main board is book-ended by perpendicular PCBs mounted to the ends, one at the top to connect to the blade and one at the bottom to connect to a speaker. Towards the bottom there is space for an optional Bluetooth radio to allow remote RGB control.

Scott is selling this as a product but also provides detailed instructions and parts lists for each component. Assembly instructions for the blade are here. The hilt is here. And pogo adapters are on OSH Park here. An overview of the firmware with links to GitHub is here. Check out a walkthrough of the handle assembly and blade attachment after the break!

Continue reading “Lightsaber Uses Pogo Pins To Make Assembly A Breeze”

Which Wireless Is Right Wireless?

Back in the early days of Arduino proliferation (and before you ask, yes we realize there was a time before that too), wireless was a strange and foreign beast. IR communication was definitely a thing. And if you had the funds there was this cool technology called ZigBee that was available, often in funny blue house-shaped XBee boards. With even more funds and a stomach for AT commands you could even bolt on a 2G cell radio for unlimited range. WiFi existed too, but connecting it to a hobbyist ecosystem of boards was a little hairier (though maybe not for our readership).

But as cell phones pushed demand for low power wireless forward and the progression of what would become the Internet of marking Terms (the IoT, of course) began, a proliferation of options appeared for wireless communication. Earlier this week we came across a great primer on some of the major wireless technologies which was put together by Digikey earlier in the year. Let’s not bury the lede. This table is the crux of the piece:

There are some neat entries here that are a little less common (and our old friend, the oft-maligned and never market-penetrating ZigBee). It’s actually even missing some entries. Let’s break it down:

  • Extremely short range: Just NFC. Very useful for transferring small amount of sensitive information slowly, or things with high location-relevance (like between phones that are touching).
  • Short range: BLE, Zigbee, Z-Wave, etc. Handy for so-called Personal Area Networks and home-scale systems.
  • Medium/long range: Wifi, Bluetooth, Zigbee, Z-Wave, LoRaWAN: Sometimes stretching for a kilometer or more in open spaces. Useful for everything from emitting tweets to stitching together a mesh network across a forrest, as long as there are enough nodes. Some of these are also useful at shorter range.
  • Very Long range/rangeless: Sigfox, NB-IoT, LTE Category-0. Connect anywhere, usually with some sort of subscription for network access. Rangeless in the sense that range is so long you use infrastructure instead of hooking a radio up to a Raspberry Pi under your desk. Though LoRa can be a fun exception to that.

You’re unlikely to go from zero to custom wireless solution without getting down into the mud with the available dev boards for a few different common protocols, but which ones? The landscape has changed so rapidly over the years, it’s easy to get stuck in one comfortable technology and miss the appearance of the next big thing (like how LoRaWAN is becoming new cool kid these days). This guide is a good overview to help catch you up and help decide which dev kits are worth a further look. But of course we still want to hear from you below about your favorite wireless gems — past, present, and future — that didn’t make it into the list (we’re looking at you 433 MHz).

How To Mash Up BLE, NodeJS, And MQTT To Get Internet Of Things

We’re living in the world of connected devices. It has never been easier to roll your own and implement the functionality you actually want, rather than live with the lowest common denominator that the manufacture chose.

In a previous article I walked though a small python script to talk to a BLE light and used it to cycle through some colors. Now I want to delve deeper into the world of Internet Connected BLE devices and how to set up a simple Internet-Of-Things light. With this example in hand the sky’s the limit on what you can build and what it will be able to do.

Join me after the break as I demonstrate how to use NodeJS to bridge the digital world with the physical world.

Continue reading “How To Mash Up BLE, NodeJS, And MQTT To Get Internet Of Things”