Hacker Playground

Bluetooth / BLE

Bluetooth Low Energy powers beacons, wearables, trackers, smart locks, and input devices. This page is a hands-on primer: how BLE talks, what to look for, common attack workflows, and how to test ethically.

Quick-start checklist

  1. Scope & permission: Only test hardware you own or have explicit written permission to assess.
  2. Baseline recon: Identify target MAC(s), device roles (Central/Peripheral), and presence of pairing/bonding.
  3. Traffic plan: Decide what you’ll capture: advertisements, connections, GATT reads/writes, notifications, HID keystrokes, etc.
  4. Tools ready: At least one sniffer (e.g., BLE-capable SDR workflow or PC+dongle sniffer), and one active tester (e.g., phone + app, or dedicated gadget).
  5. Safety: Avoid spamming in public spaces; keep RF output to minimal/necessary levels; don’t induce denial of service except in a controlled lab.

BLE signal primer

BLE operates at 2.4 GHz ISM with separate roles: a Peripheral advertises (beaconing), a Central scans and initiates connections. Data is typically exposed as GATT services → characteristics (read/write/notify).

Key channels: Three primary advertising channels (37/38/39) + data channels selected via frequency hopping once connected. Many “pop-up” style tricks rely only on advertisements.
Peripheral Advertises (Ch 37/38/39) Central Scans & Connects Connect → Pair/Encrypt → GATT
Advertising happens on 37/38/39; connections hop over data channels.

Common research workflows

1) Beaconing / presence tricks (no connection)

Craft BLE advertisements to simulate devices (e.g., iBeacon/Eddystone), trigger OS prompts, or test presence-based automations. This is low-risk and great for demos.

2) GATT exploration (read/write/notify)

After connecting, dump services/characteristics, then test permissions and behavior. Look for plaintext secrets, unsafe writes, or weakly protected control surfaces. 

# Pseudocode flow with any GATT client
discover services
discover characteristics
read characteristic 0xXXXX
write characteristic 0xYYYY value=0xDEADBEEF
subscribe notifications on char 0xZZZZ

3) HID injection (Bluetooth keyboard-style)

Emulate a BLE keyboard and send scripted keystrokes. Useful for blue-team awareness training and UX hardening (pairing prompts, trusted devices, idle locks).

4) Pairing / bonding edge cases

Assess pairing modes (Just Works, Passkey Entry, Numeric Comparison) and bonding storage. Verify that unpairing wipes keys and re-pairing follows a secure path.

5) Denial-of-service & resilience testing

Only in a closed lab. Explore behavior under advertisement floods or rapid connect/disconnect. Measure device stability, battery drain, and recovery pathways.

Hardening & defense notes

Blue-team tip: Keep a baseline map of normal BLE devices in your environment. Alert on new, high-rate advertisers or sudden bursts of connection attempts.

FAQ

Is BLE encrypted by default?

Not during advertising; encryption can apply after pairing when a connection is established. Whether your reads/writes are protected depends on characteristic permissions and pairing state.

Can I sniff BLE traffic?

You can easily see advertisements. Sniffing connected data traffic typically requires joining at the start of a connection and following channel hop parameters—use a capable sniffer or SDR-based tooling. Always stay within your authorized scope.

How far does BLE reach?

Most consumer devices are 5–30 m typical. BLE Long Range (LE Coded PHY) can extend farther with lower data rates—range depends on antennas, power, and environment.

Devices for BLE

Useful references

Ethics & law: See our Ethics page for boundaries, permission models, and safe lab setup notes.