HFP (Hands-Free Profile - Bluetooth)

Bluetooth audio accessories have become ubiquitous in modern life - from hands-free car kits and wireless earbuds to smartwatches and infotainment systems. At the heart of hands-free calling capabilities is the Bluetooth Hands-Free Profile (HFP), a protocol suite that bridges the gap between mobile devices and external audio hardware.

For developers, engineers, and security researchers, understanding HFP at both the protocol and implementation level is essential - not just for enabling features but also for securing devices against real-world threats and failures. This guide synthesizes best practices from Bluetooth SIG specifications, in-depth technical notes like Silicon Labs' AN992, and leading-edge fuzzing methodologies with Penzzer, providing an end-to-end playbook for anyone working with Bluetooth HFP.

‍

Overview of Bluetooth Hands-Free Profile (HFP)

What is HFP?

The Hands-Free Profile (HFP) is a Bluetooth protocol designed to facilitate voice communication between a mobile phone (or any Audio Gateway) and an external hands-free device, such as a car kit or a wireless headset. Its key purpose is to enable users to initiate, receive, and manage phone calls without physically handling the phone, promoting convenience and safety - especially while driving.

"Hands-Free Profile describes how an audio gateway device can be used to place and receive calls for a hand-free device."
- AN992, Silicon Labs

‍

Typical Use Cases

• Car Kits: Route call audio through a vehicle’s speakers and use built-in microphones.
• Wireless Headsets: Allow users to make and receive calls while on the move.
• Wearables and IoT Devices: Smartwatches or infotainment systems that need voice call capability.

Both the phone and the accessory must implement the HFP to ensure compatibility.

‍

Bluetooth HFP in Depth

HFP Device Roles: Audio Gateway (AG) and Hands-Free Unit (HF)

HFP splits device roles into:

• Audio Gateway (AG):
  • Typically a mobile phone or computer.
  • Provides access to the phone network and manages call logic.
  • Controls audio input/output routing to/from the network.
• Hands-Free Unit (HF):
  • Headsets, car kits, wearables, or other accessories.
  • Acts as a remote microphone and speaker for the AG.
  • Sends control signals (answer, hang up, volume) and receives status notifications.

‍

Hands-free control is implemented using AT commands over an RFCOMM serial port emulation. Audio is transmitted over SCO/eSCO (for voice quality and bandwidth).

"Hands-Free control is the entity responsible for Hands-Free unit specific control signalling; this signalling is AT command based. Control channel works on top of RFCOMM connection and the audio channel on top of SCO or eSCO channel."
- AN992, Section 1.1

‍

Protocol Stack and Channel Architecture

• Control Channel:
  • Implemented over RFCOMM.
  • Exchanged AT commands control call state, device features, and status reporting.
• Audio Channel:
  • Implemented over SCO (Synchronous Connection-Oriented) or eSCO.
  • Carries PCM audio data between AG and HF.
• Service Discovery:
  • SDP (Service Discovery Protocol) used to discover services and supported features (UUID 111F for AG, 111E for HF).

‍

HFP Versions and Audio Quality

• HFP v1.5 and older: 8kHz, 8-bit audio (classic voice).
• HFP v1.6: Supports 16kHz, 8-bit "Wideband Speech" (HD Voice), enabling higher call quality.

‍

HFP Implementation: Protocol Mechanics

Connection Setup

Hands-Free Unit (HF) Configuration

To enable HFP as HF on an embedded device or Bluetooth module:

SET PROFILE HFP ON
SET BT CLASS 200404
RESET

• SET PROFILE HFP ON: Enables HFP mode.
• SET BT CLASS 200404: Sets the Class-of-Device (CoD) for discoverability.
• RESET: Applies changes.

‍

Audio Gateway (HFP-AG) Configuration

SET PROFILE HFP-AG ON
SET BT CLASS 400204
RESET

‍SET PROFILE HFP-AG ON: Enables Audio Gateway mode.

• SET BT CLASS 400204: Correct CoD for AG.

‍

Security Configuration

• Secure Simple Pairing (SSP):
  • Mandatory for Bluetooth 2.1+EDR and newer.
  • PIN code pairing supported for legacy compatibility.
  • Example:

SET BT SSP 3 0        # Enables "just works" SSP
SET BT AUTH * 0000    # Enables PIN code pairing with code '0000'
RESET

‍

Service Discovery

• Discovering HFP-AG:

SDP 00:07:80:93:0c:aa 111F

‍

• Discovering HF:

SDP 00:07:80:81:66:6f 111E

• Returned SDP record will list the RFCOMM channel and supported features.

‍

Audio and Control Channel Establishment

Control Channel

• Open from HF to AG:

CALL {bd_addr} 111F HFP

‍

• Open from AG to HF:

CALL {bd_addr} 111E HFP-AG

• After connection, various status indicators are sent to synchronize state.

‍

Audio Channel

• Incoming Call Scenario:
  • AG receives a call → notifies HF via status messages.
  • HF answers with ANSWER command; audio channel (SCO) established.
• Outgoing Call:
  • HF initiates call with ATD<number>; or AT+BLDN (last dialed).
  • Status indicators (callsetup, call, etc.) and audio connection negotiated.

‍

Connection Termination

• End Call:
  • HANGUP command from either device.
• Close SCO connection:
  • CLOSE {sco_link_id} command.
• Close control channel:
  • CLOSE {link_id} command.

‍

HFP AT Command Set and Field Values

HFP is fundamentally driven by AT commands and their respective field values. Understanding and correctly handling these is essential for both interoperability and security.

‍

Indicator Fields and Events

After establishing the control channel, the AG sends status reports:

These are reported as HFP {link_id} STATUS "{indicator}" {value}.

‍

Audio Management and Codec Negotiation

• Volume Control:
  • AT+VGS (speaker) and AT+VGM (microphone), range 0-15.
• Codec Selection:
  • HFP 1.6 allows for CVSD (8kHz) and mSBC (16kHz).
  • Codec is indicated via events: HFP {link_id} CODEC {codec}.

‍

Three-Way Calling and Multiparty

• AT+CHLD parameters for call management:
  • 0: Release all held calls
  • 1: Release all active calls
  • 2: Place active calls on hold
  • 3: Add held call to conversation (conference)

‍

Advanced: Phonebook and SMS Access

Some implementations expose AT commands for phonebook and SMS access:

• AT+CPBS/AT+CPBR: Phonebook select and read.
• AT+CMGF, AT+CMGL: SMS format and listing.

‍

Real-World HFP Security and Robustness Challenges

Despite its simplicity, HFP can be a source of security and stability issues, especially as the complexity of implementations increases. Real-world bugs have included:

• Buffer overflows: Poor parsing of long or malformed AT commands.
• Unexpected state transitions: Handling call setup and multiparty sequences out-of-order.
• Denial-of-Service: Devices locking up or crashing due to protocol fuzzing or malformed commands.
• Unauthorized access: If security configuration is lax or AT command access is overexposed.

Vulnerabilities may be triggered by:

• Rapidly changing state (incoming/outgoing call flapping)
• Sending invalid or unknown AT commands
• Exploiting edge cases in phonebook or SMS command parsing

‍

Fuzzing and Testing Bluetooth HFP Devices with Penzzer

Why Fuzz HFP?

The HFP protocol surface, especially its AT command set and stateful operation, makes it an attractive target for fuzzing—not just to find implementation flaws, but to proactively secure devices against malicious actors or malformed device behavior.

Key Reasons:

• Complex State Machine: Multiple possible transitions between call, held, and setup states.
• Extensive AT Command Set: Many commands with variable fields and allowed values.
• Widespread Deployment: Vulnerabilities in HFP affect millions of headsets, car kits, and smartphones.

‍

Protocol-Aware and Stateful Fuzzing Strategies

What Does Protocol-Aware Fuzzing Mean?

• Awareness of Legal/Illegal Commands: Penzzer understands the HFP AT command set and can generate both valid and intentionally malformed commands.
• State Tracking: Ensures only contextually appropriate commands are sent (e.g., only sending ANSWER if a call is incoming).
• Bitmask and Range Testing: Systematically exercises all indicator values, volume levels, codec options, and phonebook/SMS entry lengths.

‍

Example Fuzzing Campaigns with Penzzer

1. AT Command Fuzzing:

• Randomize, extend, and mutate all fields in the AT command set.
• Test edge cases for number lengths, unsupported commands, and buffer limits.

‍

2. Call State Manipulation:

• Rapidly alternate between call, held, and multiparty states using combinations of AT+CHLD, ANSWER, and HANGUP.
• Explore what happens when calls are put on hold and resumed in quick succession.

‍

3. Indicator and Event Stress:

• Force all status indicators (service, call, callsetup, etc.) through their min/max and undefined values.
• Observe for crashes, assertion failures, or incorrect state transitions.

‍

4. Audio Channel Abuse:

• Attempt to force SCO/eSCO connection/disconnection repeatedly.
• Test resilience to unsupported codec negotiation and repeated volume changes.

‍

5. Phonebook/SMS Attack Surface:

• Use long names, special characters, and edge values in phonebook AT commands.
• Simulate SMS floods or malformed SMS retrieval requests.

‍

Automating Regression and Security Testing

• Regression Testing:
  • Penzzer can be set up to continuously run a comprehensive suite of fuzzing tests to ensure no new vulnerabilities or instabilities are introduced during firmware or stack updates.
• Security Testing:
  • Simulates both expected and malicious device behavior, giving manufacturers actionable insights into their device’s real-world resilience.