Bonus

Both channel hopping and jamming are interesting because they blur the lines between layers. They involve the Link Layer (the brain) and the PHY Layer (the muscle) working together.

Here is the breakdown of where they happen and how they work.

1. Channel Hopping (Frequency Hopping)

Verdict: It is a Link Layer logic executed by the PHY Layer.

• The Brain (Link Layer): The Link Layer decides which channel to jump to next. It uses a mathematical formula (Channel Selection Algorithm #2) based on the Access Address and Hop Increment. It also maintains the "Channel Map" (a list of good vs. bad channels to avoid interference).

• The Muscle (PHY Layer): The PHY layer physically tunes the radio to the frequency requested by the Link Layer.

How it works (The Dance):

1. Connection Event 1: Link Layer tells PHY: "Tune to Channel 12." -> PHY transmits.

2. Wait: Link Layer calculates next hop.

3. Connection Event 2: Link Layer tells PHY: "Tune to Channel 23." -> PHY transmits.

Security Note: If you can figure out the Link Layer's formula (specifically the Hop Increment and Access Address from the unencrypted CONNECT_REQ), you can predict every future hop. This is how sniffers "follow" a connection.

---

2. Jamming

Verdict: It is physically a PHY Layer attack, but effective jamming requires Link Layer intelligence.

There are two main types of jamming, and they target different layers:

A. Reactive / Selective Jamming (The Sniper)

This is a Link Layer-aware attack.

• How it works: The attacker listens to the air. When it detects a specific packet preamble or Access Address (Link Layer info), it instantly blasts noise on that frequency.

• Why it's dangerous: It is stealthy. It doesn't jam the whole spectrum, just the specific packets of the victim. It targets the Link Layer State Machine, forcing the device to lose synchronization and drop the connection.

B. Continuous / Wideband Jamming (The Sledgehammer)

This is a pure PHY Layer attack.

• How it works: The attacker blasts noise across all advertising channels (37, 38, 39) or the entire 2.4GHz band.

• Why it's dangerous: It is a Denial of Service (DoS) that operates purely on physics. No protocol logic is involved; it simply raises the noise floor so high that the receiver cannot distinguish the signal from the noise.

---

3. The Relay Attack (The "Smart Lock Killer")

Layer: Physical / Application Context: This is the most famous attack against cars (PKI) and BLE Smart Locks. The Scenario: You have a "Proximity Unlock" feature. The door opens when the phone is within 1 meter. The Attack:

1. Thief A stands near the locked door with a "Relay Node."

2. Thief B stands near the victim (at a coffee shop 100m away) with another "Relay Node."

3. The nodes bridge the signal over Wi-Fi/LTE.

4. The Lock thinks the Phone is 1 meter away and unlocks.

Why we missed it: It is not a "protocol" vulnerability. The crypto is valid. The packets are valid. The distance is the lie. Defense: BLE encryption does not fix this. You need Distance Bounding (measuring round-trip time of flight) or user interaction (button press on phone).

🛡️ How to Test:

• Tool: Two laptops with standard BLE dongles + GATTacker (relay mode) or specialized hardware like Proxmark (for RFID) / Custom SDR setups.

• Test: Place the phone far away. Set up a relay. See if the device unlocks.

---

4. Bad Channel Map Attack (Connection Steering)

Layer: Link Layer Context: BLE hops across 37 channels to avoid interference. The "Channel Map" tells the device which channels to use. The Attack: An active attacker (MITM) sends a LL_CHANNEL_MAP_IND packet. They tell the device: "Channels 1 through 36 are 'bad'. Only use Channel 0." Result: Frequency hopping is effectively disabled. The connection stays on a single frequency (e.g., 2404 MHz). Impact: Sniffing becomes trivial. You don't need expensive hardware to follow the hop sequence; you just sit on one channel and capture 100% of the traffic.

🛡️ How to Test:

• Tool: Mirage (Python framework) or InternalBlue (Firmware modding).

• Test: Inject a malicious Channel Map Update. Monitor the spectrum. Does the transmission collapse to a single peak?

---

5. Fault Injection / Voltage Glitching

Layer: Hardware / SMP Context: This targets the microcontroller (MCU) silicon itself during the Pairing process. The Attack: During the SMP Phase 2 (Authentication), the code checks the signature:

C

if (check_signature(key) == VALID) {
    grant_access();
} else {
    disconnect();
}

The attacker creates a power spike (glitch) at the exact microsecond the CPU executes the if statement. The CPU misfires and skips the else branch, granting access even though the signature was invalid. Impact: Bypassing Secure Boot or Authentication on "unhackable" chips.

🛡️ How to Test:

• Tool: ChipWhisperer (Hardware tool).

• Test: Requires physical access to the PCB. Monitor the power lines and attempt to glitch the CPU during the pairing handshake.

---

6. GATT Caching Attacks (BLE 5.1+)

Layer: GATT / ATT Context: To save battery, BLE 5.1 devices "cache" the attribute table so they don't have to rediscover it every time. They use a "Database Hash" to check if things changed. The Attack:

1. Spoof: The attacker spoofs a legitimate server but sends a mismatched Database Hash.

2. Confusion: The client (phone) gets confused about the memory layout of the device.

3. Overwrite: The client might write data to the wrong handle (e.g., intending to write to "Light" but actually writing to "Firmware Control") because its map is outdated.

🛡️ How to Test:

• Tool: Custom scripts mimicking a peripheral.

• Test: Advertise a Service Changed Indication but provide an inconsistent Database Hash. Observe if the Client (Phone) writes to incorrect handles.

---

7. HCI Snooping (The "Inside Job")

Layer: OS / Link Layer Context: On Android/Linux, the "Host" (OS) talks to the "Controller" (Bluetooth Chip) via HCI (Host Controller Interface). The Attack: If you have ADB access (or a malicious app) on the Android phone, you don't need to sniff the radio. You can just read the HCI Snoop Log. This log contains everything: Unencrypted keys, raw data, and OOB data. Impact: Retrieving the LTK (Long Term Key) from the phone to decrypt past traffic.

🛡️ How to Test:

• Tool: Android Developer Options -> "Enable Bluetooth HCI Snoop Log".

• Test: Pair with a device. Pull the file (adb pull /sdcard/btsnoop_hci.log). Open in Wireshark.

• Goal: Can you see the "Link Key" or "LTK" in plain text in the log? (Yes, you usually can).

---

8. DoS: Connection Parameter Request Flood

Layer: Link Layer (Control Plane) Context: Once connected, a device can ask to change speed: "Can we talk faster?" (LL_CONNECTION_PARAM_REQ). The Attack: The attacker sends this request 100 times per second with slightly different values. Result: The Controller's CPU spends 100% of its time calculating radio timing for these requests and has no cycles left to run the actual application code (e.g., unlocking the door). The device becomes unresponsive (Bricked state until reboot).

🛡️ How to Test:

• Tool: L2cap_stress or Sweyntooth.

• Test: Spam the connection update request. Check if the device application loop freezes.