ble-exploitation

name	ble-exploitation
description	BLE GATT exploitation methodology — scanning, enumeration, characteristic analysis, payload crafting, and write attacks against Bluetooth Low Energy devices

BLE GATT Exploitation Methodology

How BLE GATT Works

BLE uses a client-server model. The peripheral (target device) is the GATT server; the agent (via Flipper) is the GATT client.

Hierarchy:

• Profile — a collection of services (e.g., Heart Rate Profile)
• Service — a group of related characteristics, identified by UUID
• Characteristic — a single data point (e.g., heart rate value), with properties defining allowed operations
• Descriptor — metadata about a characteristic (e.g., CCCD at 0x2902 for enabling notifications)

Characteristic Properties (bitmask):

• 0x02 Read — client can read the value
• 0x04 Write Without Response — fire-and-forget write
• 0x08 Write — write with acknowledgment
• 0x10 Notify — server pushes updates (client must enable via CCCD)
• 0x20 Indicate — like notify but with acknowledgment
• 0x40 Authenticated Signed Write
• 0x80 Extended Properties

Standard Service UUIDs

UUID	Service	Pentest Relevance
0x1800	Generic Access	Device name, appearance — fingerprinting
0x1801	Generic Attribute	Service change indications
0x180A	Device Information	Manufacturer, model, firmware version — vuln lookup
0x180D	Heart Rate	Medical device targeting
0x180F	Battery Service	Device state awareness
0x1812	Human Interface Device	HID injection potential
0x1816	Cycling Speed & Cadence	Fitness tracker targeting
0xFE**	Manufacturer-specific (registered)	Check Bluetooth SIG assignments
128-bit custom	Proprietary services	Primary attack surface — unknown security posture

Common Vulnerable Patterns

1. Unauthenticated writes — characteristic allows Write (0x08) or Write Without Response (0x04) with no bonding/pairing required. This is the most common BLE vulnerability.
2. Hardcoded encryption keys — device uses a fixed passkey (often 000000 or 123456) for pairing.
3. No encryption — traffic sent in cleartext; sniffable with Ubertooth or nRF Sniffer.
4. Replay-vulnerable commands — writing the same byte sequence always produces the same effect (e.g., unlock command).
5. Predictable characteristic values — sequential command bytes (0x01 = lock, 0x02 = unlock).
6. Missing access control on firmware update service — OTA DFU service writable without auth.
7. Information leakage via notifications — device broadcasts sensor data to any connected client.

Step-by-Step Exploitation

Phase 1: Scan and Discover

ble_scan(timeout=10)

Record: device name, MAC address, RSSI, advertised services, manufacturer data. Sort by RSSI (strongest = closest = likely target). Note: random MAC addresses (starts with non-zero upper nibble, bit 1 of first octet set) indicate privacy-aware devices.

Phase 2: Connect and Enumerate

ble_enumerate(address="AA:BB:CC:DD:EE:FF")

Map every service → characteristic → descriptor. Record:

• Which characteristics are writable (properties & 0x0C != 0)
• Which have notifications/indications (properties & 0x30 != 0)
• Handle ranges for each service

Phase 3: Identify Attack Surface

Prioritize in this order:

1. Custom/proprietary services (128-bit UUIDs) — unknown security, likely control plane
2. Writable characteristics — direct command injection
3. HID service (0x1812) — keystroke injection
4. DFU/OTA services — firmware manipulation
5. Device Information (0x180A) — firmware version for CVE lookup

Phase 4: Research Expected Format

For proprietary characteristics:

• Read current value to understand data format and length
• Enable notifications to observe value changes during normal device operation
• Look for patterns: single-byte commands, length-prefixed TLV, protobuf
• Check if manufacturer has published BLE API docs or if community has reverse-engineered the protocol
• Search GitHub for the device name + "BLE" + "GATT" for existing research

Phase 5: Craft and Write Payload

ble_write_char(
  address="AA:BB:CC:DD:EE:FF",
  char_uuid="0000fee2-0000-1000-8000-00805f9b34fb",
  value="0x01"
)

Start with simple payloads:

• 0x00, 0x01, 0xFF — toggle commands
• Observed values with bit flips — permission escalation
• Incrementing sequences — enumerate command space
• Known unlock bytes from research

Phase 6: Verify Impact

After each write:

• Read the characteristic back — did the value change?
• Check notifications on related characteristics — did state change?
• Observe physical device — did it respond (LED, motor, lock, display)?
• Document the exact payload, timestamp, and observed effect

Device Categories and Typical GATT Profiles

Smart Locks

• Control service: custom UUID, single writable characteristic
• Common vuln: unauthenticated write of unlock byte (often 0x01 or 0x0571)
• Lock state: readable characteristic, 0x00=locked, 0x01=unlocked
• Attack: write unlock byte without pairing

Fitness Trackers / Smartwatches

• Heart Rate (0x180D), Battery (0x180F), proprietary data sync
• Common vuln: notifications leak biometric data to any connected client
• Attack: connect and subscribe to notifications without pairing

Medical Devices (Insulin Pumps, Glucose Monitors)

• Glucose (0x1808), proprietary command service
• Common vuln: unauthenticated command interface
• CRITICAL: document but do NOT exploit — safety risk. Report immediately.

IoT Sensors (Temperature, Motion, Environmental)

• Environmental Sensing (0x181A), proprietary config
• Common vuln: writable calibration/threshold characteristics
• Attack: modify alert thresholds, disable sensors

Robotic Controllers (Drones, RC Cars, Robotic Arms)

• Proprietary motor/servo control service
• Common vuln: unauthenticated movement commands
• Attack: write motor control bytes to move device

Manufacturer-Specific UUID Interpretation

Manufacturer UUIDs follow the pattern: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

• First 8 hex chars often encode the manufacturer ID
• Check Bluetooth SIG company identifiers: https://www.bluetooth.com/specifications/assigned-numbers/company-identifiers/
• Manufacturer data in advertisements often contains: company ID (2 bytes) + device type + firmware version + state flags

Error Recovery

Error	Cause	Recovery
Connection timeout	Device out of range or busy	Move closer, retry after 5s, check if another client is connected
MTU negotiation failure	Device has small MTU	Request smaller MTU (23 bytes default), split payloads
Insufficient Authentication	Pairing required	Attempt pairing with default PINs (000000, 123456, 0000)
Insufficient Encryption	Encrypted link required	Initiate bonding, then retry
Write Not Permitted	Wrong property or auth level	Check characteristic properties, try Write Without Response
GATT Timeout	Device crashed or disconnected	Reconnect, reduce write frequency
Invalid Attribute Length	Payload too long/short	Check expected length from read, match exactly

Operational Notes

• Always enumerate fully before writing — understand the device first
• Keep a log of every write attempt and response for the engagement report
• BLE range is typically 10-30m; closer = more reliable connection
• Some devices only allow one concurrent BLE connection — disconnect other clients first
• After firmware version discovery, check NVD/CVE databases for known vulnerabilities
• Document the BLE advertising interval — faster intervals mean the device is actively seeking connections

Protocol Reverse Engineering

When you find proprietary characteristics, use protocol analysis tools:

1. Capture multiple packets from notify characteristics (ble_subscribe)
2. Use crc_detect with captured packets to identify the CRC algorithm
3. Use packet_decode to break packets into fields (header, counter, command, data, CRC)
4. Use crc_calculate to forge valid packets with custom payloads
5. Tool: crcbeagle (github.com/colinoflynn/crcbeagle) — automated CRC parameter detection from packet samples