Classic Bluetooth vs BLE: What's Actually Different Under the Hood
Bluetooth Low Energy and Classic Bluetooth both operate in the 2.4GHz band, both appear in your phone's Bluetooth settings, and both carry "Bluetooth" in the name. But they're separate radio protocols with different architectures, different frequency usage, different security models, and different use cases.
graph TD
subgraph "Classic Bluetooth BR/EDR Stack"
BT_APP["Application
(A2DP, HFP, SPP)"]
BT_L2CAP["L2CAP
(segmentation,
multiplexing)"]
BT_LMP["LMP
(link management,
pairing, encryption)"]
BT_BB["Baseband
(79 channels, 1MHz spacing,
AFH, SCO/ACL links)"]
BT_RADIO["Radio
(2.4GHz, GFSK/DQPSK,
1-3 Mbps, ~100mA)"]
end
BT_APP --> BT_L2CAP --> BT_LMP --> BT_BB --> BT_RADIO
subgraph "BLE Stack"
BLE_APP["Application
(GATT profiles,
custom services)"]
BLE_ATT["ATT / GATT
(attribute protocol,
services + characteristics)"]
BLE_SMP["SMP
(security manager,
pairing, bonding)"]
BLE_LL["Link Layer
(40 channels, 2MHz spacing,
advertising + data)"]
BLE_RADIO2["Radio
(2.4GHz, GFSK,
1-2 Mbps, ~15mA)"]
end
BLE_APP --> BLE_ATT --> BLE_SMP --> BLE_LL --> BLE_RADIO2
subgraph "BLEShark Nano Capability"
SCAN_BLE["BLE scanning
and enumeration"]
NO_BT["Classic BT not
supported (ESP32-C3
is BLE-only)"]
end
BLE_LL -.-> SCAN_BLE
BT_BB -.->|"Not available"| NO_BT
Protocol stack comparison - Classic Bluetooth and BLE share the 2.4GHz band but have entirely different layer architectures
Understanding the distinction matters for security research. Tools that work on BLE don't work on Classic Bluetooth. Vulnerabilities in one don't necessarily apply to the other. And the choice of which protocol to use in a product (like the BLEShark Nano) has real implications for what capabilities are possible.
Names and Standards
First, the terminology:
Classic Bluetooth is officially known as BR/EDR - Basic Rate/Enhanced Data Rate. It covers the original Bluetooth 1.0 through modern Bluetooth 5.x in the "classic" mode. BR is the original 1 Mbps mode. EDR added 2 Mbps (2+EDR) and 3 Mbps (3+EDR) variants.
Bluetooth Low Energy is officially LE - Low Energy. It was introduced in Bluetooth 4.0 (2010) as a completely separate air interface. It was originally marketed as "Bluetooth Smart" before the Bluetooth SIG dropped that branding.
A device described as "Bluetooth 5.0" may support BR/EDR, LE, or both. A "dual-mode" Bluetooth device supports both protocols on a single chip (the controller handles both). A "single-mode" device supports only LE (BLE-only chips are common in IoT applications).
The ESP32-C3 in the BLEShark Nano is BLE-only (LE single mode). The original ESP32 supported dual-mode (both Classic Bluetooth and BLE). The C3 dropped Classic Bluetooth to reduce chip size, power consumption, and cost - a trade-off that makes sense for the use case.
Frequency Usage: Frequency Hopping vs Fixed Channels
This is one of the most fundamental architectural differences.
Classic Bluetooth BR/EDR uses Adaptive Frequency Hopping (AFH) across 79 channels (1 MHz spacing) spanning the 2.4 GHz band (2.402 GHz to 2.480 GHz). During a connection, the devices hop between channels pseudorandomly at 1600 hops per second. The hopping sequence is based on the Bluetooth clock and master's address, making it deterministic for connected devices but appearing random to observers.
The purpose of frequency hopping: interference avoidance. If one channel is noisy (WiFi, microwave, other Bluetooth), the next hop is on a different channel. AFH makes Classic Bluetooth connections robust against narrowband interference. It also makes passive interception difficult - you'd need to predict or track the hopping sequence to follow a conversation.
BLE uses 40 channels (2 MHz spacing) from 2.402 GHz to 2.480 GHz. The channel usage is split:
- 3 advertising channels (37, 38, 39) at 2.402, 2.426, and 2.480 GHz - chosen to avoid overlap with the center of the most common WiFi channels (1, 6, 11)
- 37 data channels (0-36) used for connections
BLE connections also hop between data channels, but at a much slower rate - determined by the Connection Interval (typically 7.5ms to 4s). BLE channel hopping is less aggressive than Classic Bluetooth and uses only 37 channels rather than 79.
Throughput and Latency
Classic Bluetooth BR/EDR:
- BR: 1 Mbps raw, ~721 kbps usable asymmetric throughput
- EDR 2+: 2 Mbps raw
- EDR 3+: 3 Mbps raw
- Latency: ~100ms for connection establishment, low ongoing latency for audio
BLE 5.x:
- BLE 4.x: 1 Mbps PHY, ~270 kbps usable
- BLE 5.0 2M PHY: 2 Mbps raw, ~1.4 Mbps usable
- BLE 5.0 Coded PHY (Long Range): 125 kbps or 500 kbps, extended range at expense of throughput
- Connection establishment: ~1-3ms with direct advertising, longer with background scanning
Classic Bluetooth is faster. BLE's data throughput is lower, but BLE was never designed for bulk data transfer - it's designed for infrequent, small data exchanges at very low power consumption.
The BLEShark's Shiver mesh uses ESP-NOW with Long Range mode, which is 250 kbps. This is lower than even standard BLE data rates, but the Long Range mode extends the practical communication distance to 20-50m - useful for distributing nodes across a space.
Power Consumption
This is where BLE's name comes from. The power comparison between Classic Bluetooth and BLE is dramatic:
- Classic Bluetooth BR/EDR connection: 25-100 mA during active transmission. Piconet slaves can sleep between slots, but an active audio streaming connection consumes significant power.
- BLE advertising: 10-25 mA during transmission, but transmitting for only a few milliseconds per advertising interval (typically 100ms to several seconds). Average current for a slowly advertising sensor: under 50 microamps.
- BLE connection: 1-20 mA depending on connection interval and data rate. With long intervals (1+ second), power is very low between events.
A BLE sensor running on a coin cell battery can operate for months to years. Classic Bluetooth would drain the same battery in hours.
The trade-off: low power means low data rate and limited connection speed. BLE is good for sending a few bytes every second or few seconds. It's not suitable for streaming audio (which is why your Bluetooth headphones use Classic Bluetooth, not BLE - though BLE Audio in Bluetooth 5.2+ is changing this).
Typical Use Cases
Classic Bluetooth BR/EDR:
- Audio (headphones, speakers, car audio)
- File transfer (less common now with WiFi Direct)
- Serial port emulation (SPP - used in industrial/medical devices)
- Phone audio (HFP/HSP profiles for calls)
BLE:
- Fitness trackers, heart rate monitors, smartwatches (health data)
- Smart home sensors (temperature, humidity, presence)
- Location beacons (asset tracking, indoor positioning)
- Keyboards, mice (BLE HID)
- Smart locks, access control
- Medical devices (glucose monitors, blood pressure)
- Industrial sensors
The ESP32-C3 being BLE-only is appropriate for the BLEShark's use cases: BLE scanning, BLESpam, Bad-BT (HID keyboard), and the Shiver mesh. None of these require Classic Bluetooth's higher throughput. The BLE-only design reduces power consumption and chip complexity.
Security Protocol Differences
Classic Bluetooth and BLE have separate security systems, and the vulnerabilities in each are different.
sequenceDiagram
participant C as Central/Master
participant P as Peripheral/Slave
rect rgb(30, 30, 30)
Note over C,P: Classic Bluetooth Connection
C->>C: Inquiry scan (discover devices)
C->>P: Page (connection request)
P-->>C: Page response
C->>P: LMP link setup
Note over C,P: Authentication + encryption negotiation
C->>P: Service Discovery (SDP)
P-->>C: Available profiles (A2DP, HFP...)
C->>P: Profile-level connection
Note over C,P: Continuous connection maintained
end
rect rgb(30, 40, 30)
Note over C,P: BLE Connection
P->>P: Advertise on ch 37, 38, 39
C->>C: Scan advertisements
C->>P: Connection request (CONNECT_IND)
Note over C,P: Link layer connection established
C->>P: GATT service discovery
P-->>C: Services + characteristics
C->>P: Read/write/subscribe
Note over C,P: Connection intervals save power
end
Connection establishment - Classic BT uses inquiry/page while BLE uses advertising/scanning, with fundamentally different power profiles
Classic Bluetooth security has historically been problematic:
- BlueBorne (2017): A set of critical vulnerabilities in Bluetooth implementations affecting Android, iOS, Windows, and Linux - many involving Classic Bluetooth stacks. Some were exploitable without pairing.
- KNOB (Key Negotiation of Bluetooth, 2019): A downgrade attack allowing an attacker to force a Classic Bluetooth session to use a 1-byte entropy key, making brute force trivial. Affected many dual-mode devices.
- PIN-based legacy pairing: Classic Bluetooth 2.0 and earlier used PIN codes for pairing. An offline attacker who captures a pairing exchange can brute-force short PINs. Bluetooth 2.1 introduced SSP (Secure Simple Pairing) using ECDH, improving this significantly.
BLE security has its own issues (Just Works pairing MITM vulnerability, implementation bugs in LE Secure Connections, advertising data privacy issues) but the underlying cryptographic design of LE Secure Connections (BLE 4.2+) is generally considered sound.
Why Security Tools Focus on BLE
Classic Bluetooth's frequency hopping makes passive capture with a standard adapter difficult. Tracking a Classic Bluetooth connection requires either dedicated hardware (like Ubertooth One) that can follow the hopping sequence, or capturing the initial connection setup to derive the hopping pattern. This is achievable but requires more specialized hardware.
BLE's fixed advertising channels and predictable data channel hopping make it much more accessible for capture and analysis with standard hardware. The three advertising channels (37, 38, 39) are known and fixed - any BLE adapter can capture all advertising traffic by scanning these channels. Analysis tools like nRF Connect, GATTacker, and the BLEShark's own scanner work because BLE's architecture is designed for interoperability and discoverability.
The practical result: the BLE security research toolchain is much more accessible than Classic Bluetooth research. Most consumer IoT devices use BLE. Most BLE scanners and analyzers work with commodity hardware. Classic Bluetooth security research requires specialized hardware (Ubertooth) and is less accessible to the broader security community.
Why BLEShark Uses BLE
The BLEShark Nano's BLE focus reflects where the interesting security research and practical use cases are. Most smart home devices are BLE. Most fitness devices are BLE. The proximity marketing, location beacon, and HID-injection spaces are all BLE. BLE 5.0 on the ESP32-C3 gives the BLEShark access to all of these.
The trade-off: Classic Bluetooth audio devices (your headphones, your car's Bluetooth) are outside the BLEShark's scope. For Bluetooth audio research, the original ESP32 (dual-mode) or dedicated Classic Bluetooth tools are appropriate.
For the BLEShark's actual feature set - BLE scanning with OUI lookup, BLESpam, Bad-BT keyboard injection, the Shiver mesh, and BLE passive monitoring - BLE 5.0 is not a limitation, it's exactly what's needed.
graph TD
subgraph "Classic BT Security Vulnerabilities"
BT_SEC["Classic BT Security"]
BT_SEC --> BLUE["BlueBorne (2017)
RCE without pairing"]
BT_SEC --> KNOB["KNOB Attack (2019)
Key negotiation downgrade"]
BT_SEC --> BIAS["BIAS Attack (2020)
Authentication bypass"]
BT_SEC --> BLUF["BLUFFS (2023)
Session key derivation flaw"]
end
subgraph "BLE Security Vulnerabilities"
BLE_SEC["BLE Security"]
BLE_SEC --> JW["Just Works Pairing
No MITM protection"]
BLE_SEC --> TRACK["MAC Tracking
Static addresses leak identity"]
BLE_SEC --> EAVES["Eavesdropping
Unencrypted advertisements"]
BLE_SEC --> SPAM["BLE Spam
Fake advertisement flooding"]
end
subgraph "BLEShark Nano Testing"
BLESCAN2["BLE Scan
(enumerate devices)"]
BLESPAM["BLE Spam
(test notification
handling)"]
ASSESS["Security Assessment
(identify unencrypted
services)"]
end
BLE_SEC -.-> BLESCAN2
BLE_SEC -.-> BLESPAM
BLE_SEC -.-> ASSESS
Security vulnerability landscape - Classic BT has seen protocol-level attacks while BLE faces advertising and pairing weaknesses
BLE and Bluetooth security research should only be conducted on devices and in environments where you have explicit authorization. Interfering with, intercepting, or accessing Bluetooth communications without authorization may violate applicable laws.