Skip to content

Reconnaissance

Modules: 13 total (12 CLI-exposed, 1 internal)

All reconnaissance probes are non-intrusive and require no pairing.

Reconnaissance is the deep-dive phase that follows Discovery. Where discovery answers "what devices are nearby?", reconnaissance answers "what does this specific target expose?" Each probe reveals a different facet of the target's attack surface: which services it offers, which channels are open, what firmware it runs, and how its Bluetooth stack behaves.

Target is optional

All recon commands accept the target address as an optional argument. When omitted, Blue-Tap scans for nearby devices and presents an interactive picker.

The findings from reconnaissance directly inform which vulnerability checks and exploits apply. For example, if SDP reveals OBEX Object Push on RFCOMM channel 12, you know the target may be vulnerable to Bluesnarfing. If GATT enumeration shows writable characteristics without authentication, the target has a BLE posture weakness.

CLI-Exposed Probes

Command Module ID What It Collects Key Options
recon [TARGET] sdp reconnaissance.sdp SDP services, profiles, channels --retries
recon [TARGET] gatt reconnaissance.gatt BLE GATT services, characteristics ---
recon [TARGET] l2cap reconnaissance.l2cap_scan Open L2CAP PSMs --start-psm (1), --end-psm (4097), --timeout (1000ms)
recon [TARGET] rfcomm reconnaissance.rfcomm_scan Open RFCOMM channels --start-channel (1), --end-channel (30), --timeout (2000ms)
recon [TARGET] fingerprint reconnaissance.fingerprint Device identification ---
recon [TARGET] capture reconnaissance.hci_capture HCI packet capture -d duration, -o output
recon [TARGET] sniff reconnaissance.sniffer Passive BT sniffing -m mode, -d duration, -o output
recon [TARGET] auto reconnaissance.campaign Full recon campaign — all applicable probes ---
recon [TARGET] capabilities reconnaissance.capability_detector Supported profiles, transports, features ---
recon [TARGET] analyze reconnaissance.capture_analysis Pcap protocol breakdown, anomalies --pcap (file path)
recon [TARGET] correlate reconnaissance.correlation Cross-probe correlation, unified profile ---
recon [TARGET] interpret reconnaissance.spec_interpretation BT spec data — flags, versions, class codes ---

Probe Details

SDP

Queries the target's Service Discovery Protocol database. SDP is Bluetooth Classic's service registry --- every profile the device supports (A2DP, HFP, OBEX, HID, etc.) is advertised here along with the protocol stack needed to connect.

SDP results tell you exactly what the target does over Bluetooth: which profiles are active, which L2CAP PSMs or RFCOMM channels they use, and what protocol versions are supported. This is the single most informative recon probe for Classic targets.

blue-tap recon 4C:4F:EE:17:3A:89 sdp
blue-tap recon 4C:4F:EE:17:3A:89 sdp --retries 3

SDP probe output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 sdp
Session: blue-tap_20260416_144012

── SDP Services (4C:4F:EE:17:3A:89) ───────────────────────────────────────────

Service: Audio Source (A2DP)
  Profile:   Advanced Audio Distribution (0x110D) v1.3
  Protocol:  L2CAP > AVDTP
  PSM:       25
  Channel:   ---

Service: AV Remote Control Target
  Profile:   A/V Remote Control (0x110E) v1.6
  Protocol:  L2CAP > AVCTP
  PSM:       23
  Channel:   ---

Service: Handsfree Audio Gateway
  Profile:   Hands-Free (0x111E) v1.7
  Protocol:  L2CAP > RFCOMM
  Channel:   2

Service: OBEX Object Push
  Profile:   Object Push (0x1105) v1.2
  Protocol:  L2CAP > RFCOMM > OBEX
  Channel:   12

Service: Phonebook Access PSE
  Profile:   Phonebook Access (0x1130) v1.2
  Protocol:  L2CAP > RFCOMM > OBEX
  Channel:   15

Service: Message Access Server
  Profile:   Message Access (0x1132) v1.0
  Protocol:  L2CAP > RFCOMM > OBEX
  Channel:   16

Found 6 services on 4C:4F:EE:17:3A:89

What SDP Findings Mean

  • OBEX Object Push on an IVI means file transfer is available --- potential Bluesnarfing vector
  • Phonebook Access (PBAP) means the target syncs phonebooks --- if auth is weak, contacts can be extracted
  • Message Access (MAP) means SMS sync is available --- messages may be extractable
  • Hands-Free means audio channel access --- can be used for eavesdropping after exploitation
  • HID means the target accepts keyboard/mouse input --- relevant for CVE-2023-45866

GATT

Enumerates BLE GATT services and characteristics. Connects to the target, discovers all services, and reads characteristic properties (read/write/notify flags). GATT is the BLE equivalent of SDP --- it defines what data and operations the device exposes.

blue-tap recon DE:AD:BE:EF:CA:FE gatt

GATT enumeration output

$ sudo blue-tap recon DE:AD:BE:EF:CA:FE gatt
Session: blue-tap_20260416_144130

── GATT Services (DE:AD:BE:EF:CA:FE) ──────────────────────────────────────────

Service: Generic Access (0x1800)
  ├── Device Name (0x2A00)          [read]
  └── Appearance (0x2A01)           [read]

Service: Battery Service (0x180F)
  └── Battery Level (0x2A19)        [read, notify]

Service: Human Interface Device (0x1812)
  ├── Report (0x2A4D)               [read, write, notify]
  ├── Report Map (0x2A4B)           [read]
  └── HID Control Point (0x2A4C)    [write-no-response]

Service: Vendor Specific (0xFFF0)
  ├── Custom Char (0xFFF1)          [read, write]
  └── Custom Char (0xFFF2)          [read, notify]

Found 4 services, 9 characteristics
Writable without auth: 3 characteristics (flagged)

Writable Characteristics

Characteristics marked [write] or [write-no-response] that do not require authentication are a posture finding. The vulnscan writable_gatt check flags these automatically, but GATT recon shows you the full picture. Vendor-specific services (UUIDs starting with 0xFFF) often have custom writable characteristics that were not designed with security in mind.

L2CAP Scan

Probes L2CAP Protocol/Service Multiplexer (PSM) values to find open channels. L2CAP is the transport layer that most Bluetooth Classic protocols run on. Each service listens on a specific PSM.

This probe iterates through the PSM range and attempts a connection to each. Open PSMs indicate listening services --- some may not be advertised in SDP (intentionally hidden or undocumented). This is analogous to a TCP port scan in network security.

blue-tap recon 4C:4F:EE:17:3A:89 l2cap
blue-tap recon 4C:4F:EE:17:3A:89 l2cap --start-psm 1 --end-psm 4097 --timeout 500

L2CAP scan output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 l2cap --timeout 500
Session: blue-tap_20260416_144300

── L2CAP PSM Scan (4C:4F:EE:17:3A:89) ─────────────────────────────────────────

PSM 1    (SDP)          OPEN
PSM 3    (RFCOMM)       OPEN
PSM 15   (BNEP)         OPEN
PSM 17   (AVCTP)        OPEN
PSM 19   (AVDTP)        OPEN
PSM 23   (AVCTP Brws)   OPEN
PSM 25   (AVDTP)        OPEN
PSM 4113 (unknown)      OPEN    ← not in SDP

Scanned 2049 PSMs: 8 open, 2041 closed/rejected

Hidden Services

PSMs that are open but not advertised in SDP are worth investigating --- they may be debug interfaces, OTA update channels, or vendor-specific services that the manufacturer did not intend to expose. PSM 4113 in the example above would warrant further investigation.

RFCOMM Scan

Probes RFCOMM channel numbers to find open serial-port-style services. RFCOMM provides a serial port emulation layer over L2CAP. Many legacy Bluetooth services (AT commands, OBEX, SPP) use RFCOMM channels.

This probe is especially useful when SDP is restricted or incomplete --- some devices hide services from SDP but still accept connections on RFCOMM channels.

blue-tap recon 4C:4F:EE:17:3A:89 rfcomm
blue-tap recon 4C:4F:EE:17:3A:89 rfcomm --start-channel 1 --end-channel 30 --timeout 2000

RFCOMM scan output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 rfcomm
Session: blue-tap_20260416_144420

── RFCOMM Channel Scan (4C:4F:EE:17:3A:89) ────────────────────────────────────

Channel 1   SPP (Serial Port Profile)          OPEN
Channel 2   Hands-Free                         OPEN
Channel 12  OBEX Object Push                   OPEN
Channel 15  Phonebook Access                   OPEN
Channel 16  Message Access                     OPEN
Channel 22  (unknown)                          OPEN    ← not in SDP

Scanned 30 channels: 6 open, 24 closed

RFCOMM vs SDP

Compare RFCOMM scan results with SDP output. Channels that appear in RFCOMM but not in SDP may be undocumented services. Channel 22 in the example above --- not advertised in SDP --- could be a vendor debug console, diagnostic port, or firmware update interface.

Fingerprint

Identifies the target device by combining multiple signals: device name patterns, OUI lookup, SDP profiles, BLE advertisement data, and LMP feature pages. Produces a device identification report with manufacturer, model, and firmware version when available.

Fingerprinting helps you determine exactly what you are testing. An IVI head unit running Android Auto has a different Bluetooth stack (and different vulnerabilities) than one running QNX or Linux.

blue-tap recon 4C:4F:EE:17:3A:89 fingerprint

Fingerprint output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 fingerprint
Session: blue-tap_20260416_144530

── Device Fingerprint (4C:4F:EE:17:3A:89) ─────────────────────────────────────

Manufacturer:    Harman International
Model:           Harman Kardon IVI (MY-CAR-AUDIO)
Device Type:     In-Vehicle Infotainment (IVI)
OS Inference:    Linux-based (BlueZ stack)
BT Version:      5.0 (from LMP features)
LMP Subversion:  0x220e
HCI Revision:    0x000b

LMP Features:
  ├── Secure Simple Pairing:     Supported
  ├── LE Supported (Controller): Supported
  ├── Extended Inquiry Response:  Supported
  ├── Encryption Pause/Resume:   Not Supported
  └── Secure Connections:        Not Supported ← weak

Assessment Notes:
  [!] BT 5.0 without Secure Connections --- vulnerable to KNOB, BIAS
  [!] No encryption pause/resume --- may accept enc downgrade
  [i] Linux/BlueZ stack --- check CVE-2017-0785, CVE-2022-42896

Why Fingerprinting Matters

The fingerprint output directly informs your vulnerability assessment strategy. In the example above, the target lacks Secure Connections support, which means KNOB (CVE-2019-9506) and BIAS (CVE-2020-10135) are likely viable. The "Linux/BlueZ stack" inference tells you to prioritize BlueZ-specific CVEs. Without fingerprinting, you would run all 25 CVE checks blindly; with it, you can focus on the most likely hits.

HCI Capture

Captures raw HCI packets to/from the target for offline analysis. Output is in btsnoop format, which can be opened in Wireshark.

HCI capture is useful for understanding the protocol exchange in detail --- troubleshooting failed probes, analyzing authentication handshakes, or building evidence for a report.

blue-tap recon 4C:4F:EE:17:3A:89 capture -d 30 -o capture.btsnoop
Example output 
$ sudo blue-tap recon 4C:4F:EE:17:3A:89 capture -d 30 -o capture.btsnoop

15:10:00  ●  Running: HCI Capture
15:10:00  ●  Starting reconnaissance.hci_capture
15:10:00  ●  btmon capture started -> capture.btsnoop (btsnoop/pcap)
15:10:30  ✔  btmon capture stopped
15:10:30  ✔  Completed reconnaissance.hci_capture
15:10:30  ●  Result: capture.btsnoop (14.2 KB, 30s, 247 frames)

When to Capture

Run a capture during other operations to record the full protocol exchange. For example, capture during vulnscan to have packet-level evidence of vulnerability detection, or during exploit to document the attack for your report.

Sniffer

Passive Bluetooth sniffing. Captures over-the-air Bluetooth traffic without establishing a connection. Requires compatible hardware for some modes (particularly LMP sniffing).

blue-tap recon 4C:4F:EE:17:3A:89 sniff -m ble -d 60 -o sniff.pcap
Example output 
$ sudo blue-tap recon 4C:4F:EE:17:3A:89 sniff -m ble -d 60 -o sniff.pcap

15:15:00  ●  Running: Bluetooth Sniffer
15:15:00  ●  Starting reconnaissance.sniffer
15:15:00  ●  Mode: ble | Duration: 60s | Output: sniff.pcap
15:15:00  ●  nRF Sniffer started on /dev/ttyACM0
15:15:00  ●  Scanning for BLE advertisements...
15:15:08  ●  Captured 34 advertisement frames (12 unique devices)
15:15:22  ●  Target 4C:4F:EE:17:3A:89 detected — following connection events
15:15:60  ✔  Completed reconnaissance.sniffer
15:15:60  ●  Result: sniff.pcap (87.4 KB, 60s, 1,842 packets)

nRF Sniffer Required

BLE connection sniffing requires an nRF52840 dongle with the nrf_sniffer_ble extcap plugin for Wireshark/tshark. Without it, the sniffer falls back to advertisement-only capture using the standard adapter. LMP sniffing requires DarkFirmware on the RTL8761B.

Sniff modes:

Mode Description Hardware
ble (default) BLE advertisement sniffing Any BLE adapter
ble_advertise Alias for ble Any BLE adapter
ble_connection Targeted BLE connection capture (requires RHOST) nRF52840 sniffer
ble_pairing BLE pairing exchange capture nRF52840 sniffer
lmp LMP (Link Manager Protocol) sniffing DarkFirmware RTL8761B
combined BLE + LMP simultaneously, correlated nRF52840 + DarkFirmware

Outcome taxonomy

The sniffer maps results to the recon outcomes:

  • observed --- packets counted (scapy enumerated the pcap successfully)
  • artifact_collected --- pcap has bytes on disk but Blue-Tap could not count frames (scapy missing). The file is still usable in Wireshark.
  • not_applicable --- capture produced nothing.

If you are seeing artifact_collected consistently, pip install scapy inside the Blue-Tap virtualenv to unlock frame counts.

Prerequisites

blue-tap run reconnaissance.prerequisites CAPABILITY=dual_mode

The prerequisites module reports available / applicable / reason for each recon collector. A collector that is not applicable to the current target capability (e.g. LMP sniffing on a BLE-only target) is reported as applicable=false and is not counted as "missing" in the summary. Earlier versions flagged inapplicable checks as missing, which misled operators into installing LMP tooling they did not need.

LMP Sniffing

The lmp and combined modes require a DarkFirmware-patched RTL8761B dongle. Standard HCI adapters cannot capture LMP frames because they are handled below the HCI layer by the controller firmware. See the DarkFirmware documentation for setup instructions.

Auto Campaign

Orchestrates a full reconnaissance campaign across all applicable probes for the target. The campaign module determines which probes to run based on the target type (Classic, BLE, or dual-mode) and skips probes that do not apply. This is the fastest way to get comprehensive recon without specifying individual probes.

blue-tap recon 4C:4F:EE:17:3A:89 auto

Auto campaign output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 auto
Session: blue-tap_20260416_145000

── Recon Campaign (4C:4F:EE:17:3A:89) ─────────────────────────────────────────

[1/7] SDP enumeration...              6 services found
[2/7] L2CAP PSM scan...              8 PSMs open
[3/7] RFCOMM channel scan...         6 channels open
[4/7] Device fingerprint...          Harman IVI (BT 5.0, BlueZ)
[5/7] Capability detection...        14 profiles, dual-mode
[6/7] Finding correlation...         3 hidden services identified
[7/7] Spec interpretation...         2 security concerns flagged

Campaign complete: 7/7 probes executed

Capability Detection

Detects the target's full capability set by combining information from SDP, GATT, LMP feature pages, and advertisement data. Produces a unified profile of supported Bluetooth profiles, transports, and security features.

blue-tap recon 4C:4F:EE:17:3A:89 capabilities

Capability detection output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 capabilities
Session: blue-tap_20260416_145200

── Capabilities (4C:4F:EE:17:3A:89) ────────────────────────────────────────────

Transport:       Dual-mode (Classic + BLE)
Profiles:        A2DP, AVRCP, HFP, PBAP, MAP, OPP, PAN, SPP
Security:        SSP supported, Secure Connections NOT supported
Encryption:      E0 (legacy), AES-CCM not available
BLE Features:    GATT, GAP, Device Information
LMP Version:     5.0

Security Assessment:
  [!] No Secure Connections — KNOB, BIAS viable
  [!] Legacy encryption only — downgrade attacks possible
  [i] 8 profiles exposed — large attack surface

Capture Analysis

Analyzes a previously captured pcap/btsnoop file for protocol breakdown, anomalies, and key events. Useful for post-hoc analysis of HCI captures taken during other operations.

blue-tap recon 4C:4F:EE:17:3A:89 analyze --pcap capture.btsnoop

Capture analysis output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 analyze --pcap capture.btsnoop
Session: blue-tap_20260416_145400

── Capture Analysis (capture.btsnoop) ──────────────────────────────────────────

Duration:        00:02:34
Packets:         1,847
Protocols:       HCI (1847), L2CAP (1203), SDP (89), RFCOMM (412)

Key Events:
  00:00:02  Connection established (handle 0x0040)
  00:00:03  Authentication started (SSP)
  00:00:04  Encryption enabled (E0, key_size=16)
  00:01:12  PBAP session opened (RFCOMM ch 15)
  00:02:30  Disconnection (reason: 0x13)

Anomalies:
  [!] Encryption key size negotiation: target accepted key_size=7
  [i] 3 retransmissions on L2CAP channel 0x0040

Finding Correlation

Correlates findings from multiple reconnaissance probes into a unified target profile. Cross-references SDP services with L2CAP PSMs and RFCOMM channels to identify hidden services, inconsistencies, and additional attack surface not visible from any single probe.

blue-tap recon 4C:4F:EE:17:3A:89 correlate

Correlation output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 correlate
Session: blue-tap_20260416_145600

── Finding Correlation (4C:4F:EE:17:3A:89) ─────────────────────────────────────

Cross-Reference Results:
  RFCOMM ch 22 — open but NOT in SDP (hidden service)
  L2CAP PSM 4113 — open but NOT in SDP (vendor-specific)
  SDP advertises HFP on ch 2 — confirmed open via RFCOMM scan

Unified Attack Surface:
  Known services:     6 (SDP-advertised, channel-confirmed)
  Hidden services:    2 (channel open, no SDP record)
  BLE services:       4 (GATT-enumerated)
  Total endpoints:   12

Spec Interpretation

Interprets raw Bluetooth specification data — LMP feature flags, version strings, Class of Device codes, and capability bits — into human-readable security assessments. Translates protocol-level observations into actionable findings.

blue-tap recon 4C:4F:EE:17:3A:89 interpret

Spec interpretation output

$ sudo blue-tap recon 4C:4F:EE:17:3A:89 interpret
Session: blue-tap_20260416_145800

── Spec Interpretation (4C:4F:EE:17:3A:89) ─────────────────────────────────────

LMP Features Page 0:
  Bit 0x01 (3-slot packets):         Supported
  Bit 0x08 (Encryption):             Supported
  Bit 0x40 (SSP Controller):         Supported
  Bit 0x100 (LE Supported):          Supported
  Bit 0x200 (Secure Connections):    NOT Supported ← security gap

Version Interpretation:
  LMP 5.0 → Bluetooth 5.0 (2016 spec)
  Missing: Secure Connections Host Support (added in BT 4.1)

Class of Device (0x200424):
  Major: Audio/Video (0x04)
  Minor: Car Audio (0x08)
  Services: Audio (bit 21)
  Assessment: IVI system — high-value target

Internal Modules

These modules are not directly exposed via CLI commands but are used by automated workflows.

Module ID Purpose
reconnaissance.prerequisites Checks whether recon prerequisites are met for a target

Outcomes

All reconnaissance modules use the same outcome taxonomy:

Outcome Meaning
observed Data was successfully collected
merged Results merged from multiple sources
correlated Cross-probe correlation produced enriched findings
partial Some data collected, but the probe was incomplete (e.g., target went out of range, timeout on some channels)
not_applicable Probe does not apply to this target type (e.g., GATT against a Classic-only device)

Partial Results

A partial outcome does not mean the data is useless. If an L2CAP scan times out after scanning 1000 of 2049 PSMs, you still have results for the first 1000. The outcome tells you the scan was incomplete so you can re-run with a longer timeout or narrower range if needed.

For a thorough assessment of a Classic target:

# 1. Service enumeration --- most informative, always run first
sudo blue-tap recon 4C:4F:EE:17:3A:89 sdp

# 2. Channel scans --- find hidden services not in SDP
sudo blue-tap recon 4C:4F:EE:17:3A:89 l2cap
sudo blue-tap recon 4C:4F:EE:17:3A:89 rfcomm

# 3. Device identification --- determine stack, version, capabilities
sudo blue-tap recon 4C:4F:EE:17:3A:89 fingerprint
sudo blue-tap recon 4C:4F:EE:17:3A:89 capabilities

# 4. Correlate all findings into unified profile
sudo blue-tap recon 4C:4F:EE:17:3A:89 correlate

# Or run everything at once:
sudo blue-tap recon 4C:4F:EE:17:3A:89 auto

For a BLE target:

# 1. GATT enumeration --- the BLE equivalent of SDP
sudo blue-tap recon DE:AD:BE:EF:CA:FE gatt

# 2. Fingerprint --- determine device type and capabilities
sudo blue-tap recon DE:AD:BE:EF:CA:FE fingerprint

What's Next?

With recon data collected, you have a clear picture of the target's attack surface. The next step is vulnerability assessment: