In the movie Blackhat, the Bad Guy communicated "anonymously" with his cronies by setting up (I think) a Bluetooth hot spot in an open mall.
They all virtually crossed paths at some specific spot, where there was a radio and computer hidden in a bush.
The premise is these folks have never met, and assuming that the cronies aren't familiar with the tech and told to "go to this bench, do this workflow, enter in these codes". Rather they were told to download an app to their phone, go to this area and "start chatting", or maybe they connected to the bush server, and exchanged messages without ever having to be in the same place at the same time.
Can a modern phone contact a BT device without being manually paired (assuming it has cooperating software on the phone)? A non-hacked phone? Could they have been using just raw BLE for this?
> The premise is these folks have never met, and assuming that the cronies aren't familiar with the tech and told to "go to this bench, do this workflow, enter in these codes". Rather they were told to download an app to their phone, go to this area and "start chatting", or maybe they connected to the bush server, and exchanged messages without ever having to be in the same place at the same time.
I'm pretty sure walkie-talkies can be purchased at any street-corner and replicate this.
Even toy walkie-talkies in the USA follow the FRS standard and have roughly ~1 mile or so of range (3 to 5 miles for more expensive walkie-talkies). Meaning you can have an untrackable "virtual meetup" with strangers as long as you all coordinate a time, place, and channel to talk.
------------
If you want more smarts, you'll want to:
1. Use LoRa -- 900MHz (800ish in Europe) is superior for range. Bluetooth is 2.4GHz and attenuates too quickly, and is therefore short-range only (a few hundred meters reliably).
2. LoRa modules are cheap. Arduinos, ESP32, Beaglebone ConnectPlay, etc. etc. A ton of different microcontrollers and microprocessors exist. Slap a solar panel + lead-acid battery on a BeagleBone Play or something and now you got 24-hour always on servers with 3 to 5 miles of communication range. Add on TLS1.3 and now its encrypted to the latest and greatest specifications of encryption available.
Walkie-talkies are still unconventional technical items. Everyone has a phone - homeless people have phones. Phones are ubiquitous, and someone having one is not unusual.
They might be lower-tech, but it is odd if someone has a walkie-talkie - also easy to monitor (range == eavesdroppers have range too) and it is in fact illegal to use encryption over the available frequencies or to send digital data (so all things you could do, but which would draw attention).
The problem with committing crimes is that efforts to cover up the crime themselves are likely to create evidence of it.
Unless you're disrupting military / police / aviation frequencies, there is virtually no enforcement. The FCC does not routinely police the airwaves - they can be asked to investigate egregious disturbances, but if they do choose to respond (which is rare), that response will not start for weeks or months. Nobody is going to show up with guns drawn for an encrypted LoRa connection.
LoRA is very neat, been playing with Meshtastic lately a bit - only downside is how fucking chatty it is, which makes it very easy to perform direction finding / trilateration using something like a KrakenSDR (or just a normal SDR and a directional antenna).
At some point I’d like to mess with trying to do “burst” comms over LoRA, maybe meshtastic can be fiddled with to act in this manner - where it only actually sends RF traffic when it has something to say.
I just double-checked and I got my initial spelling (LoRA) wrong. Its actually spelled (LoRa) (lower-case a, not an upper-case). I've edited my earlier message to correct my mistake.
LoRA is the LLM / deep learning stuff. LoRa is the radio. Hurrah, overloaded terms!
You can configure the spreading factor and bandwidth to make the bursts very short, at the cost of robustness to interference etc. And transmit at sparse intervals if you want.
Yup, BLE can transmit data without pairing. That's how AirTags and the like work.
Basically, BLE is designed for lightweight sensors that periodically wake up and blindly transmit their data. It doesn't know or care if anyone receives.
The amount of data is small and necessarily unencrypted. Throughput is also very low.
For bidirectional communication, you might be able to do the reverse: have your device transmit these blind BLE packets, but I don't know offhand if that's supported in Android. There may be other ways, like packing some data into an advertisement query or something.
Again I'm not sure how well it's supported in Android, but under Windows you can silently establish a connection with an unsecured BLE device without user interaction. You don't actually pair to BLE devices most of the time, it's a different mechanism. And again this comes without encryption, but there's ways around that.
Android has a BLE scanner app that can passively read info. I don't know enough about the protocol to know if that is the same thing you are referring to.
Android allows you to initiate scanning and receive advertisements without user interaction (assuming the app has the permissions to run in the background and use Bluetooth). Advertisements are "broadcasts" or "beacons"
"Pairing" in BLE-speak is a key exchange procedure so devices can establish a secure connection without performing authentication again.
BLE communication can happen inside of a "connection", or outside of a connection.
A typical device "advertises" it's presence with beacons which are broadcast on 3 channels. These beacons are user-defined, so you can use them like UDP packets. Sensor wakes up and broadcasts the current temperature.
Your smartphone can receive advertisements while scanning. Check out the insane number of beacons present in an American apartment complex.
Note: BLE connections may be encrypted, or not. That's up to you. You do not need to "pair" (exchange keys) to communicate with a connection. There are 4 "modes" to authenticate. Without an out-of-band communication mode, all are vulnerable to MITM.
The latest BLE standard improves range with a half-data rate PHY. Range is determined by transmit power and attenuation. Most BLE radios are designed for short-range communication. I've never seen one consuming more than mW, but that does not mean you couldn't make an amplifier that transmits BLE much further
At least for BLE one could use advertising packets to transmit the data, sensor beacons tend to do this with e.g. a temperature.
There is also the scan-response mode, initiated by the device scanning for others. And you can use plain GATT without any authentication, but that would be fully unencrypted iirc.
Rangewise it might be possible to reach 100m in an open field under very good conditions, especially when utilizing coded PHY, but not with default power levels I think.
There is a lot more to know, one place to start is 'Intro to Bluetooth low energy' by Mohammed Afaneh
depending on how good of a line-of-sight you have to the transmitter, you can receive over 50+m using a well-tuned antenna
if the transmitter is hidden, range largely depends on what it's hidden inside, but even a phone at the bottom of a backpack can receive from a similarly hidden flipper zero broadcasting from another backpack at about 5-10m
> Can a modern phone contact a BT device without being manually paired (assuming it has cooperating software on the phone)?
Yes. I manage IOT apps for android and iOS that do exactly this. You can write/read data to any bluetooth device around you that is advertising as connectable and has a GATT characteristic that supports it.
And also, BLE is more than Bluetooth in name only.
There is the L2CAP layer and radio specs taken directly from Bluetooth Classic. There is also the fact that good or bad (I’ll let you guess) it is the same Special Interest Group that develops it.
> and radio specs taken directly from Bluetooth Classic
False - modulations are entirely different. Channel hopping is done differently too. L2CAP is also quite cut down in many ways, having only the same 4 byte header in common. When I wrote this article (11 years ago), this was even more true than it is today (BLE did not even have the 2mbps mode yet)
Why does that coil of wire matter? It's dictated by drive and antenna characteristics. It's an RF coupling efficiency thing, not really a BT/WiFi thing.
Back then, BLE-capable MCUs were rare and expensive. Now that you can get $0.10 MCUs out of china that speak BLE natively, this is no longer useful. I rarely take articles off my website, so it is still up. How it ended up on HN front page today, I am not sure.
BLE literally started from a Bluetooth competitor technology that was later given to the Bluetooth SIG and renamed to BLE. It is literally Bluetooth in name only.
Anyone who has read anything about them can tell they are almost like day and night.
Yes, it was given to the Bluetooth SIG in 2007ish, but it has not really evolved to be more classic/BR-like since then (or it would break compatibility). And no, it's not the same L2CAP layer -- it again shares the name and little else.
a fun BLE device that i have is a Furby Connect (2016)
https://github.com/Jeija/bluefluff ("This project aims to reverse engineer / "hack" Furby Connect's Bluetooth Low Energy protocol, graphics and audio format and eventually find a way to execute own code on Furby")
Pretty much. A similar approach of only unsolicited advertisement packets is used by a number of beacons. But that is not the only use case. A decent number of BTLE sensors out there also work exclusively by periodically sending out unsolicited advertisement frames with their data.
As long as you don't need to accept any incoming data, that is really easy to do, and allows completely shutting off the radio in between, so the radio may only be active for a few miliseconds once every few minutes. That helps keep power consumption very low, especially for battery powered devices.
If the primary sensor functions are low power, and support an interrupt signal, and you have a microprocessor with a low power timer interrupt (to allow waking up occasionally even if the sensor state has not changed), and ability to stop the clock to the rest while waiting, you can pretty easily get multiple years on a single disposable AAA or coin cell battery.
Over the summer I bought a RaceBox Mini, thinking it was a fancy GPS logger, but instead of logging it broadcasts the current location over BLE whenever there's a device connected. RaceBox makes an app, but since it's standard BLE I was able to write a systemd service that runs on a RPi and logs to a SQLite database. A lot of the standard BLE interfaces have built-in support in Bluez, so it was pretty easy to setup.
"Beacon", as in "attracts attention to a specific location"? No, not necessarily.
You could use this to broadcast GPS coordinates (and you can always try to triangulate the location of a BTLE transmitter), but the author is showing what he believes to be the simplest way for an embedded project to transmit arbitrary digital data over the air - to, for example, an iPhone.
Beacon has a pretty specific meaning in the BLE world. A BLE beacon sends a broadcast out every now and then* that says “hey I exist, here’s my ID”. Another device can scan for these “advertisement” and do something when a particular kind of device is detected.
An example use case is a museum app displaying info to a user when they walk up to a particular exhibit.
* the interval can be set from 10ms to ~10s. The radio can be turned off in between advertisements, which is where the “LE” part comes from.
How easy is it to put consumer BLE chipsets into a monitor mode? It sounds like it'd be fun to "wardrive" (more likely walking around) with a BLE "scanner".
If you only want to listen to advertising channels, it is trivial because this is the norm - this is how connections are established. If you want to listen in on data channels you'll need an SDR with a lot of bandwidth or 40 receivers to cover every channel. If you want to monitor a single connection, you can channel-hop with it in the same sequence, but if you miss out on the connection establishment message, you'll not know the channel hopping sequence and not manage.
Most BLE comms are encrypted nowadays so you'll not get much out of this anyways.
BLE is basically designed to work that way, so it’s very easy.
On Linux you can start a bluetooth device scan (using “scan on” in bluetoothcl), and all of the nearby devices will show up as DBus objects under “org.bluez”.
You can manipulate them and read their properties/attributes with any DBus interface.
They all virtually crossed paths at some specific spot, where there was a radio and computer hidden in a bush.
The premise is these folks have never met, and assuming that the cronies aren't familiar with the tech and told to "go to this bench, do this workflow, enter in these codes". Rather they were told to download an app to their phone, go to this area and "start chatting", or maybe they connected to the bush server, and exchanged messages without ever having to be in the same place at the same time.
Can a modern phone contact a BT device without being manually paired (assuming it has cooperating software on the phone)? A non-hacked phone? Could they have been using just raw BLE for this?
What kind of range does BT and BLE have?