Bit-Banging Bluetooth Low Energy
dmitry.gr
dmitry.gr
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?
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.
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.
Send it in encrypted Morse code.
Probably illegal but Morse code is itself legal and who out there would even know if some doo-dah-dahs were in fact encrypted anyway?
But LoRa is the more legitimate long-range module for home made digital comms (encrypted) in any case. And should be easier to do.
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.
LoRA is the LLM / deep learning stuff. LoRa is the radio. Hurrah, overloaded terms!
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.
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
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
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.
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)
Also bit timing and phase are NOT software. They are very much hardware state machines in all implementations.
Yes, WiFi uses the same radio, although IDK about balun.
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.
Anyone who has read anything about them can tell they are almost like day and night.
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 neat!
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.
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.
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.
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.
Could probably be a shell one liner.