Cybersecurity blog header

Unlocking hidden Bluetooth capabilities at ScapyCon

- Antonio Vázquez Blanco
Antón Vázquez, at one point during the talk on Scapy

Discover hidden Bluetooth capabilities with Scapy using vendor-specific HCI commands and new tools for Bluetooth security research

Bluetooth security research still lacks an equivalent to the monitor mode that Wi-Fi researchers take for granted. Beyond the standardized interface that every Bluetooth controller exposes, there is a layer of vendor-specific functionality where powerful features exist but remain inaccessible through conventional tooling.

This article documents how direct controller interaction over USB, the discovery of vendor-specific HCI commands and a sustained upstreaming effort in Scapy can be combined to unlock capabilities that are normally hidden from the operating system and from standard Bluetooth stacks, such as Bluetooth MAC address spoofing and low-level protocol access.

This research is part of our Bluetooth security research line and expands on the notes and findings shared in the ScapyCon 2026 talk Unlocking Hidden Bluetooth Capabilities with Scapy.

Table of Contents

Where this research comes from

Tarlogic’s Bluetooth research line started with vulnerability discovery. BlueTrust, published in 2022, described a procedure to clone Bluetooth identities and to identify trust relationships between devices even when both devices were not simultaneously present.

That period made one thing very clear: there was no unified place for Bluetooth security documentation. Resources existed, but they were scattered. That was the reason to create and publish BSAM, a complete, public and Creative Commons licensed Bluetooth security assessment methodology.

The research continued with BlueSpy and WallOfShame, proofs of concept that allowed us to listen to and inject audio in wireless headphones. Beyond validating BSAM against real devices, this phase exposed a second structural problem: Bluetooth tooling was missing.

From there the effort moved towards building the missing pieces. UsbBluetooth and the reverse engineering of the ESP32 hidden HCI vendor commands were published as libraries and documentation to facilitate tool development, and earlier in 2026 we released BSAM Checker, a free tool that assists and partially automates Bluetooth security assessments following the methodology.

This research is part of our Bluetooth security research line and expands on the notes and findings shared in the ScapyCon

Figure 1. Timeline of the Bluetooth research line.

Despite having started down the tooling path, the work is far from done. This article focuses on how Scapy can help you develop your own tools and proofs of concept for Bluetooth.

Bluetooth architecture: what the abstraction hides

Bluetooth physical architecture is split into two main components:

  • The Host: general purpose hardware, such as your computer, which runs a large amount of Bluetooth-related software but has no special hardware requirements.
  • The Controller: specific hardware with RF capabilities that takes on the lower layer requirements needed to actually put information on the air.

The two components interact using a protocol called HCI (Host Controller Interface). HCI is part of the specification and defines both how the components are connected and the protocol used to exchange data.

Bluetooth, however, is not about two local chips talking to each other. It is about wireless communication between two separate devices, and that happens over the RF layer. Curiously enough, the relevant user interaction is host to host, and in that sense the controllers carry the heavy weight of RF communications precisely because of those special hardware requirements.

In this process the host loses the ability to see the real RF traffic, which is hidden away behind an abstraction layer called ACL that travels over HCI.

Figure 2. Bluetooth physical architecture. The relevant interaction is host to host over HCI/ACL, while the real RF exchange stays inside the controllers.

Figure 2. Bluetooth physical architecture. The relevant interaction is host to host over HCI/ACL, while the real RF exchange stays inside the controllers.

Applications do not usually care about the lower layers, and this model conveniently simplifies away complexity for the average user. For security researchers, though, those lower layers are a hidden attack surface that we should not forget.

The goal of this research is therefore to gain capabilities on devices that allow us to see or modify at least part of that hidden behaviour, enabling testing that was not previously possible.

Scapy and Bluetooth

Before v2.6.0, Scapy already had reasonable Bluetooth support. During the 2.6 and 2.7 release cycles we sent around 30 pull requests to improve it.

The resulting coverage is a modest but practical map of the vanilla HCI and ACL protocols: enough to talk to the local controller chip and also to interact with remote hosts. Some packet definitions are still missing, but essentially everything is in place.

That still leaves two hard limits in the way of reaching the lower layers: the existing sockets and the controller.

Socket limitations

The first obstacle is how the host gets access to the controller in the first place:

  • Scapy Bluetooth sockets are OS dependent – Linux only, no Windows support.
  • Each operating system initializes Bluetooth controllers differently.
  • Different firmware revisions come with different quirk handling, and the OS may flash or upgrade controllers before you ever get to them.
  • Operating systems sometimes sanitize the traffic going to or coming from controllers, which is exactly the traffic a researcher wants to send.

To work around this, we created UsbBluetooth, an OS-independent driver for Bluetooth devices built on LibUSB. It provides a direct HCI connection to the controller with no sanitization whatsoever.

Upstreaming this into Scapy did not make much sense: it introduces an external dependency on libusb and it requires testing against real hardware.

Instead, we published a bridge package, scapy-usbbluetooth. It is deliberately simple to use: you list your devices, open a socket on one of them, and that socket is a Scapy SuperSocket that lets you send and receive with all of Scapy’s packet parsing magic.

With this, we move from the vanilla OS HCI socket to an enhanced HCI socket that works on any operating system without the limitations described above.

Controller limitations

The second obstacle is the controller itself. The base Bluetooth Core controller specification does not provide RF access.

Communication with the controller is strictly defined: you can send a finite set of commands that perform a finite set of actions, and that is it. One could argue that part of the security of the protocol relies on this premise.

Curiously, the specification also contains a section where vendors are allowed to implement their own «vendor-specific commands» (VSCs).

What ends up living there, in practice, is:

  • Debugging features that are often forgotten and left intact in production devices.
  • Update and upgrade mechanisms.
  • Configuration commands.

Do not expect any of it to be documented.

What we went looking for

The reverse engineering effort focused on vendor commands related to four capabilities, chosen as stepping stones towards a single final goal changing the MAC address of a controller:

  • Device information and identification: a tool must be able to detect which hardware it is talking to before it can use any advanced capability.
  • Memory read primitives: to dump internal state information and to reverse engineer Bluetooth firmwares.
  • Memory write primitives: if read primitives were not available, write primitives could provide them through RCE, and possibly modify the address modification directly.
  • MAC address changing: and if a direct command existed, to document it.

Vendor by vendor

Realtek

Credit here goes to Xeno Kovah and his Hardwear.io 2025 talk, which described how to obtain read and write capabilities on Realtek controllers from the firmware files shipped in the linux-firmware repository and from an RF testing utility for these chips.
We took that work and upstreamed the read and write memory commands to Scapy.

The BD_ADDR changing is possible on these parts, but it has to go through a vendor configuration command with enough complexity that it was not implemented yet. It looks achievable in the near future.

Barrot

Our colleague Isaac Lleida has been researching Barrot chips, publishing his work at barrot-tools. He found a bootloader exposed on a UART interface of a physical device and abused it to dump the Wi-Fi/Bluetooth firmware.

Reverse engineering that firmware produced a good quality list of commands, and the read, write, info and BD_ADDR commands were upstreamed to Scapy. For Barrot, upstream Scapy now has every capability we were looking for.

There are still commands pending upstreaming.

CSR

For Cambridge Silicon Radio devices, the goal was reached simply by reading BlueZ source code. The csr.c parser does not fully document the protocol details, but it is a very good base to start from.

The info and BD_ADDR commands were upstreamed.

Many more commands remain to be reversed and upstreamed.

Intel

Intel is a particular case. As an Intel Bluetooth user, the EULA “forbids” reverse engineering their firmwares.

Fortunately, the Linux driver partially documents some commands, including how to identify controllers.

The info command was upstreamed based on this information.

Nordic and Zephyr

Nordic devices run a fork of the Zephyr RTOS, and Zephyr partially documents its vendor commands in hci_vs.h.

From there we obtained an informational command and a BD_ADDR changing command, both were upstreamed.

There are many more available for future work.

Espressif

Espressif is the vendor we had already invested the most effort in, with the reverse engineering published in ESP32 hidden HCI vendor commands and the broader stack documentation in Liberating Bluetooth on the ESP32.

The read, write and BD_ADDR commands are currently being upstreamed in one pull request pending approval.

One caveat worth stating: since the publication of that research, Espressif has treated some of the vendor command discoveries as security issues (see CVE-2025-27840), and the read and write commands have been accordingly disabled or removed from newer SDK versions.

Current Scapy support

Figure 4. Summary of vendor-specific command support currently available in Scapy.

Figure 4. Summary of vendor-specific command support currently available in Scapy.

Four out of six vendors fully supported is not a bad ratio and it should grow.

Why this matters: attack ideas

The security relevance of BD_ADDR control follows directly from how Bluetooth identity works:

  • Bluetooth device identity is summarized to the BD_ADDR.
  • That identity (BD_ADDR) is authenticated using a pairing key.
  • A pairing key is a shared secret valid for a single pair of BD_ADDRs.

The security model therefore assumes that a device cannot change its own BD_ADDR. Once that assumption breaks, several things become possible:

  • If we obtain a Bluetooth pairing key, we can fully impersonate a device by changing our BD_ADDR, becoming indistinguishable from the legitimate one.
  • Even without a key, impersonating a BD_ADDR lets us reach the authentication step and receive incoming connections aimed at the impersonated device. That, in turn, provides a way to discover devices in non-advertising mode. Overall, a meaningfully increased attack surface to test.

Tools and demos

Theory and ideas are all well and good, but what are all these VSCs actually useful for?

A set of practical examples has been published at TarlogicSecurity/BluetoothExamplesAndDemos.

Controller Info

Advanced Bluetooth controller information, combining standard and vendor HCI commands. It is meant as a base for tools that need to recognize controllers and use whatever advanced capabilities they may offer, and as a way to explore advanced controller features.

Figure 6. Controller Info identifying a RivieraWaves controller.

Figure 6. Controller Info identifying a RivieraWaves controller.

Vendor Command Enumerator

A tool to brute-force vendor commands out of your controller, enumerating and researching what advanced features it may be hiding. It was written mainly to research the same devices we now support, but it is directly useful for testing your own hardware.

Figure 7. Vendor Command Enumerator sweeping opcodes and dissecting the responses with Scapy.

Figure 7. Vendor Command Enumerator sweeping opcodes and dissecting the responses with Scapy.

Firmware Dumper

For devices with read memory commands, this script locates the controller and dumps its firmware to a file. It is especially interesting for comparing firmware versions across devices and for studying and reverse engineering controller capabilities.

Figure 8. Firmware Dumper collecting a Realtek firmware image for later analysis.

Figure 8. Firmware Dumper collecting a Realtek firmware image for later analysis.

BD Addr Changer

The tool we were originally after. It lists your controllers and changes the public address on the supported ones.

Figure 9. BD_ADDR Changer showing which controllers expose a usable vendor address-change command.

Figure 9. BD_ADDR Changer showing which controllers expose a usable vendor address-change command.

Future work

For the future, we would like to find controllers from more vendors to test. We already hold information on five additional manufacturers’ VSCs that could not be validated for lack of hardware. Once tested, more commands can be upstreamed.

Another task is to integrate some of this into BlueZ, starting with the bdaddr tool to make this features available in Linux at a system level.

A definitive point would be to feed this knowledge back into BSAM Checker to improve methodology coverage and automate more controls.

Conclusions

The base structure for adding Bluetooth vendor-specific commands to Scapy is now in place.

Security-relevant commands have been upstreamed for several manufacturers, and if you are willing to research and test, the published tooling works across all six vendors covered here.

Beyond VSCs, a significant amount of standard HCI support and bug fixing has been upstreamed as well, and further Bluetooth improvements should land in Scapy v2.8.0.

Finally, a genuine thank you to the Scapy maintainers. A lot of people owe them thanks, and their patience is never paid enough.

References