Denial of Service

Module: exploitation.dos --- 30 checks across 4 categories

Outcomes: success, unresponsive, recovered, not_applicable, aborted

All DoS checks are intrusive. Each check sends crafted packets designed to crash, hang, or degrade the target device, then monitors recovery. The combination of attack and recovery monitoring is what makes this module useful for security assessments: it doesn't just test whether a device can be crashed, but how it behaves after a crash --- whether it recovers gracefully, requires a manual reboot, or enters a degraded state.

Intrusive

Every check in this module is intrusive by design. The target device may become unresponsive, crash, or require a manual reboot. Always use --yes to confirm or run interactively.

---

Ethical Considerations

Denial-of-service testing against Bluetooth devices raises specific ethical concerns that differ from web or network DoS testing.

Physical safety implications. A Bluetooth device that crashes in a vehicle context is not just an IT inconvenience. If an IVI system crashes while providing navigation, or if a hands-free system drops during an emergency call, the consequences are physical. Never run DoS checks against devices that are actively being used in safety-critical contexts (moving vehicles, medical devices, industrial control systems).

Recovery monitoring is the point. The goal of DoS testing in a security assessment is not to prove that you can crash a device --- that's usually straightforward. The goal is to characterize the failure mode: Does the device recover automatically? How long does recovery take? Does it come back in a degraded state? Is a manual reboot required? These answers determine the real-world severity of the vulnerability.

Scope and authorization. DoS testing should be explicitly authorized in the engagement scope. Document every check that was run, its outcome, and the target's recovery behavior. The session report captures all of this automatically.

---

Categories

Classic (10 checks)

Classic Bluetooth DoS checks target the BR/EDR protocol stack --- the traditional Bluetooth connection used by phones, cars, and headsets. These checks exploit vulnerabilities in L2CAP, BNEP, AVDTP, AVRCP, SDP, and HFP implementations.

Check ID	CVE	Description
cve_2017_0781_bnep_heap	CVE-2017-0781	BNEP heap overflow via oversized control message
cve_2017_0782_bnep_underflow	CVE-2017-0782	BNEP integer underflow in extension headers
cve_2022_39177_avdtp_setconf	CVE-2022-39177	AVDTP SETCONF heap overflow (malformed codec capabilities)
cve_2023_27349_avrcp_event	CVE-2023-27349	AVRCP event registration out-of-bounds read
cve_2025_0084_sdp_race	CVE-2025-0084	SDP service search race condition
cve_2025_48593_hfp_reconnect	CVE-2025-48593	HFP reconnect-during-teardown crash
l2ping_flood	---	L2CAP echo request flood
pair_flood	---	Rapid pairing request flood
name_flood	---	Remote name request flood
rate_test	---	Connection rate stress test

What these target at the protocol level:

• BNEP (CVE-2017-0781, CVE-2017-0782): BNEP sits on top of L2CAP and provides Ethernet-over-Bluetooth for tethering and PAN. The heap overflow sends a BNEP control message with a length field that exceeds the allocated buffer. The integer underflow crafts extension headers whose size calculation wraps around, causing the parser to read/write beyond buffer boundaries.
• AVDTP (CVE-2022-39177): AVDTP negotiates audio streaming parameters for A2DP. The SETCONF command includes codec capability descriptors. A malformed descriptor with an oversized capability payload overflows the heap buffer allocated for parsing.
• AVRCP (CVE-2023-27349): AVRCP handles media remote control. The event registration handler has an out-of-bounds read when processing a crafted RegisterNotification command with an invalid event ID, leading to a crash.
• SDP (CVE-2025-0084): SDP handles service discovery. The race condition occurs when concurrent ServiceSearch and ServiceAttribute requests manipulate shared state without proper locking, causing a use-after-free.
• HFP (CVE-2025-48593): HFP manages hands-free calling. The crash occurs when a reconnection attempt arrives while the previous connection's teardown callback is still executing, accessing freed memory.
• Flood checks (l2ping, pair, name, rate): These don't exploit specific vulnerabilities. They stress-test the target's ability to handle high-frequency legitimate requests. Many Bluetooth stacks have no rate limiting, and a flood of valid requests can exhaust connection slots, memory, or processing capacity.

BLE (2 checks)

BLE (Bluetooth Low Energy) DoS checks target the GATT/ATT and SMP layers used by fitness trackers, smartwatches, IoT sensors, and BLE-capable IVI systems.

Check ID	CVE	Description
cve_2019_19192_att_deadlock	CVE-2019-19192	ATT deadlock via malformed indication
cve_2019_19196_key_size	CVE-2019-19196	SMP key size overflow

• ATT deadlock (CVE-2019-19192): Part of the SweynTooth family. Sends a malformed ATT Handle Value Indication that triggers a deadlock in the target's ATT state machine. The target stops processing all BLE traffic until rebooted.
• SMP key size overflow (CVE-2019-19196): Also SweynTooth. Sends an SMP Pairing Request with a key size field that exceeds the valid range (>16 bytes), causing a buffer overflow in the key generation routine.

Raw ACL (1 check)

Check ID	CVE	Description
cve_2020_0022_bluefrag	CVE-2020-0022	BlueFrag --- ACL fragment reassembly crash

BlueFrag is one of the most impactful Bluetooth vulnerabilities discovered. It exploits the ACL fragment reassembly logic in Android's Bluetooth stack. By sending carefully crafted ACL fragments whose sizes cause an integer overflow in the reassembly buffer calculation, the attacker triggers either a crash (DoS) or, on Android 8.0--9.0, remote code execution.

DarkFirmware Required

CVE-2020-0022 (BlueFrag) requires a DarkFirmware-patched adapter to inject crafted ACL fragments below the HCI boundary. Standard Bluetooth adapters cannot generate the malformed ACL fragments needed for this check. See Hardware Setup for details.

Protocol (17 checks)

Protocol-level DoS checks stress-test specific protocol behaviors without targeting known CVEs. These checks are useful for finding new vulnerabilities in Bluetooth implementations.

Check ID	Description
hfp_at_flood	AT command flood over HFP
hfp_slc_confuse	Service Level Connection renegotiation loop
l2cap_cid_exhaust	Exhaust available L2CAP channel IDs
l2cap_data_flood	L2CAP data frame flood
l2cap_storm	Combined L2CAP signaling + data flood
lmp_detach_flood	LMP detach request flood
lmp_encryption_toggle	LMP encryption setup/teardown toggle
lmp_features_flood	LMP features request flood
lmp_invalid_opcode	Invalid LMP opcode injection
lmp_switch_storm	LMP role switch request storm
lmp_timing_flood	LMP timing accuracy request flood
obex_connect_flood	OBEX connect request flood
rfcomm_mux_flood	RFCOMM multiplexer command flood
rfcomm_sabm_flood	RFCOMM SABM (connection) frame flood
sdp_continuation	SDP continuation state exhaustion
sdp_des_bomb	Deeply nested SDP Data Element Sequence

What these target:

• Resource exhaustion (CID exhaust, continuation state): These checks open channels or initiate protocol transactions without completing them, consuming limited resources on the target. l2cap_cid_exhaust opens L2CAP channels until the target runs out of channel IDs. sdp_continuation starts SDP queries that require continuation responses, consuming server-side state.
• Flood attacks (l2ping, data, storm, AT, SABM, MUX, OBEX): High-frequency valid requests that overwhelm the target's processing capacity. The l2cap_storm combines signaling and data floods for maximum pressure.
• State confusion (SLC confuse, encryption toggle, role switch): These exploit the target's protocol state machine by rapidly changing state. hfp_slc_confuse renegotiates the SLC repeatedly. lmp_encryption_toggle rapidly enables and disables encryption. lmp_switch_storm floods role switch requests. These can trigger race conditions and state corruption.
• Parser stress (DES bomb, invalid opcode): The sdp_des_bomb sends deeply nested Data Element Sequences (DES within DES within DES), testing for stack overflow in recursive parsers. lmp_invalid_opcode sends LMP packets with reserved/undefined opcodes to test error handling.

LMP Checks

The 6 LMP checks (lmp_*) require DarkFirmware-patched firmware. LMP operates below the HCI boundary and cannot be accessed through standard Bluetooth APIs.

---

Execution Model

The dos_runner orchestrates each check:

1. Validate --- confirms the check is applicable to the target (transport type, DarkFirmware requirement)
2. Execute --- runs the check with the configured parameters
3. Probe recovery --- monitors whether the target recovers after the attack

---

Recovery Monitoring

After each check completes, the runner probes the target to determine its state. Recovery monitoring is the most important part of DoS testing --- it tells you the real-world impact.

Probe types:

Probe	Method	Applicable To
classic_l2ping	L2CAP echo request	Classic devices
classic_name	Remote name request	Classic devices
ble_advertising	BLE scan for advertisements	BLE devices
ble_att	BLE ATT connection attempt	BLE devices
ble_att_request	BLE ATT read request	BLE devices

Recovery status:

Status	Meaning	Real-World Implication
SUCCESS	Check executed, target remained responsive	Target is resilient to this attack
UNRESPONSIVE	Target did not recover within timeout	Requires manual reboot; serious DoS vulnerability
RECOVERED	Target was unresponsive but came back within timeout	Self-healing; temporary disruption only
NOT_APPLICABLE	Check not applicable to this target type	Skipped (e.g., BLE check against Classic-only device)

---

CLI Usage

Target is optional

The target address can be omitted. When no target is provided, Blue-Tap scans for nearby devices and presents an interactive picker.

Run all applicable DoS checks

blue-tap dos [TARGET]

Example output

$ sudo blue-tap dos 4C:4F:EE:17:3A:89 --yes

15:50:00  ●  Running: DoS Check Runner
15:50:00  ●  Starting exploitation.dos_runner
15:50:00  ●  Running 30 DoS checks against 4C:4F:EE:17:3A:89

────────── DoS Check 1/30: l2ping_flood ──────────
  15:50:01  ●  Sending 500 L2CAP echo requests (1000-byte payload)...
  15:50:06  ✔  Target responsive after flood (latency +8ms)
  15:50:06  ✔  Result: recovered

────────── DoS Check 4/30: cve_2017_0781_bnep_heap ──────────
  15:50:15  ●  Sending oversized BNEP SETUP_CONNECTION_REQ...
  15:50:18  ⚠  Target unresponsive after 3 packets
  15:50:28  ●  Waiting for recovery (10s)...
  15:50:38  ✔  Target recovered after 20s
  15:50:38  ✔  Result: recovered (20s downtime)

────────── DoS Check 12/30: sdp_des_bomb ──────────
  15:51:02  ●  Flooding SDP ServiceSearchReq (1000 requests)...
  15:51:08  ✔  Target responsive (latency +45ms, degraded)
  15:51:08  ✔  Result: degraded

────────── DoS Check 22/30: pair_flood ──────────
  15:51:45  ●  Sending rapid pairing requests (100 attempts)...
  15:51:52  ⚠  Target stopped responding at attempt 67
  15:52:02  ⚠  Target did not recover within 30s timeout
  15:52:02  ✖  Result: unresponsive (permanent DoS — power cycle required)

╭─ DoS Check Results ──────────────────────────────────────────────────────╮
│ Status          Check                                Count              │
│ ✔ recovered     L2CAP ping flood, BNEP heap, ...     24                 │
│ ⚠ degraded      SDP flood, RFCOMM flood              3                  │
│ ✖ unresponsive  Pair flood, ACL fragment flood        2                  │
│ ○ skipped       (requires BLE)                        1                  │
╰──────────────────────────────────────────────────────────────────────────╯
DoS Summary
──────────────────────────────────────────────────
  Target              4C:4F:EE:17:3A:89
  Checks run          29/30
  Recovered           24
  Degraded            3
  Unresponsive        2  (permanent DoS)
  Skipped             1

Run specific checks

blue-tap dos [TARGET] --checks l2ping_flood,pair_flood

Custom recovery timeout

blue-tap dos [TARGET] --recovery-timeout 30

Non-interactive (skip confirmation)

blue-tap dos [TARGET] --yes

Example output

$ blue-tap dos AA:BB:CC:DD:EE:FF --checks l2ping_flood,sdp_des_bomb,cve_2022_39177_avdtp_setconf --recovery-timeout 20

[16:00:01] DoS module starting
[16:00:01] Target: AA:BB:CC:DD:EE:FF
[16:00:01] Checks: 3 selected (2 Classic, 1 Protocol)
[16:00:01] Recovery timeout: 20s

⚠  These checks are INTRUSIVE. The target may crash or become
   unresponsive. Proceed? [y/N] y

─── Check 1/3: l2ping_flood ──────────────────────────
[16:00:05] Sending L2CAP echo requests (1000 packets, 600B each)...
[16:00:12] Flood complete. 1000 packets sent in 7.1s (140 pkt/s)
[16:00:12] Probing recovery...
[16:00:13] L2CAP echo: response in 8ms
[16:00:13] Remote name: "MyCarAudio" in 45ms
[16:00:13] Result: SUCCESS (target remained responsive)

─── Check 2/3: sdp_des_bomb ──────────────────────────
[16:00:15] Sending nested DES payload (depth: 256, 2048 bytes)...
[16:00:15] Response: timeout after 10s
[16:00:15] Probing recovery...
[16:00:16] L2CAP echo: no response
[16:00:20] L2CAP echo: no response
[16:00:25] L2CAP echo: response in 12ms
[16:00:25] Result: RECOVERED (unresponsive for 10.2s, then recovered)

─── Check 3/3: cve_2022_39177_avdtp_setconf ─────────
[16:00:27] Sending malformed AVDTP SETCONF (oversized codec caps)...
[16:00:27] Connection dropped.
[16:00:27] Probing recovery...
[16:00:32] L2CAP echo: no response
[16:00:37] L2CAP echo: no response
[16:00:42] L2CAP echo: no response
[16:00:47] L2CAP echo: no response (timeout reached)
[16:00:47] Result: UNRESPONSIVE (target did not recover within 20s)

═══════════════════════════════════════════════════════════
  DoS Summary
═══════════════════════════════════════════════════════════
  Target:        AA:BB:CC:DD:EE:FF
  Checks run:    3
  SUCCESS:       1 (l2ping_flood)
  RECOVERED:     1 (sdp_des_bomb --- 10.2s recovery)
  UNRESPONSIVE:  1 (cve_2022_39177_avdtp_setconf)
  NOT_APPLICABLE: 0
═══════════════════════════════════════════════════════════

Interpreting Results

• SUCCESS means the target handled the attack without disruption. This is the desired outcome from the target manufacturer's perspective. It does not mean the attack was ineffective --- it means the target is resilient.
• RECOVERED indicates a temporary denial of service. Note the recovery time. A 2-second recovery is a minor issue; a 30-second recovery during a phone call is a significant vulnerability.
• UNRESPONSIVE is the most severe outcome. The target requires manual intervention (usually a power cycle) to resume operation. This is a high-severity finding in any security assessment.

Recovery Timeout

The default recovery timeout is 15 seconds. Increase --recovery-timeout for targets that are slow to reboot (e.g., IVI systems with long boot sequences). A typical IVI may take 30--60 seconds to fully restart, so --recovery-timeout 60 prevents false UNRESPONSIVE results.

---

Next Steps

• Correlate with fuzzing: Crashes found by the fuzzer can be replayed through the DoS module to confirm denial-of-service impact.
• Check known CVEs: Run vulnerability assessment first to identify which CVE-based DoS checks are relevant to the target.
• Full assessment: Use auto mode to run DoS checks as part of a complete assessment pipeline.
• Report findings: DoS results including recovery status are automatically included in session reports.