Desbloqueando capacidades Bluetooth ocultas en ScapyCon
Descubre cómo Tarlogic desbloquea capacidades Bluetooth ocultas en Scapy mediante comandos HCI específicos del fabricante y nuevas herramientas de seguridad
La investigación de seguridad en Bluetooth todavía carece de un equivalente al modo monitor para los investigadores de Wi-Fi. Más allá de la interfaz estandarizada que expone cada controlador Bluetooth, existe una capa de funcionalidades específicas del fabricante en la que hay capacidades muy potentes que permanecen inaccesibles para las herramientas convencionales.
Este artículo documenta cómo la interacción directa con el controlador a través de USB, el descubrimiento de comandos HCI específicos del fabricante y un esfuerzo continuado de integración (upstreaming) en Scapy pueden combinarse para desbloquear capacidades que normalmente permanecen ocultas para el sistema operativo y para las implementaciones Bluetooth estándar, como la suplantación de direcciones MAC y el acceso a protocolos de bajo nivel.
Esto forma parte de nuestra línea de investigación en seguridad Bluetooth y amplía las notas y hallazgos compartidos en la charla de ScapyCon 2026 Unlocking Hidden Bluetooth Capabilities with Scapy.
Table of Contents
De dónde surge esta investigación
La línea de investigación de Tarlogic sobre Bluetooth comenzó con el descubrimiento de vulnerabilidades. BlueTrust, publicado en 2022, donde se describía un procedimiento para clonar identidades Bluetooth e identificar relaciones de confianza entre dispositivos incluso cuando ambos dispositivos no estaban presentes simultáneamente.
Aquello dejó algo muy claro: no existía un lugar unificado para la documentación sobre seguridad Bluetooth. Había recursos, pero estaban dispersos. Esa fue la razón para crear y publicar BSAM, una metodología completa y pública de evaluación de seguridad Bluetooth, publicada bajo una licencia Creative Commons.
La investigación continuó con BlueSpy y WallOfShame, pruebas de concepto que permitían escuchar e inyectar audio en auriculares inalámbricos. Más allá de validar BSAM frente a dispositivos reales, esta fase puso de manifiesto un segundo problema estructural: faltaban herramientas para Bluetooth.
A partir de ahí, el esfuerzo se orientó a desarrollar las piezas que faltaban. UsbBluetooth y la ingeniería inversa de los comandos HCI ocultos específicos del fabricante del ESP32 se publicaron como librerías y documentación para facilitar el desarrollo de herramientas. A principios de 2026 también lanzamos BSAM Checker, una herramienta gratuita que ayuda y automatiza parcialmente las evaluaciones de seguridad Bluetooth siguiendo la metodología.
Figura 1. Cronología de la línea de investigación sobre Bluetooth.
A pesar de haber iniciado el camino hacia el desarrollo de herramientas, el trabajo está lejos de haber terminado. Este artículo se centra en cómo Scapy puede ayudarte a desarrollar tus propias herramientas y pruebas de concepto para Bluetooth.
Arquitectura Bluetooth: qué oculta la abstracción
La arquitectura física de Bluetooth se divide en dos componentes principales:
- El Host: hardware de propósito general, como un ordenador, que ejecuta una gran cantidad de software relacionado con Bluetooth, pero que no requiere hardware especializado.
- El Controller: hardware específico con capacidades de RF que se encarga de los requisitos de las capas inferiores necesarios para transmitir información por el aire.
Ambos componentes interactúan mediante un protocolo denominado HCI (Host Controller Interface). HCI forma parte de la especificación y define tanto la forma en la que están conectados los componentes como el protocolo utilizado para intercambiar datos.
Sin embargo, Bluetooth no consiste en que dos chips locales se comuniquen entre sí. Se trata de comunicación inalámbrica entre dos dispositivos independientes, y esta comunicación tiene lugar a través de la capa RF. Curiosamente, la interacción relevante para el usuario se produce entre hosts y, en ese sentido, los controladores soportan el peso de las comunicaciones RF precisamente debido a esos requisitos especiales de hardware.
Debido a esta arquitectura, el host pierde la capacidad de ver el tráfico RF real, que queda oculto detrás de una capa de abstracción denominada ACL, que viaja sobre HCI.
Figura 2. Arquitectura física de Bluetooth. La interacción relevante es de host a host mediante HCI/ACL, mientras que el intercambio RF real permanece dentro de los controladores.
Las aplicaciones normalmente no necesitan preocuparse por las capas inferiores, y este modelo simplifica convenientemente la complejidad para el usuario medio. Para los investigadores de seguridad, sin embargo, esas capas inferiores constituyen una superficie de ataque oculta que no debemos olvidar.
Por tanto, el objetivo de esta investigación es obtener capacidades en dispositivos que nos permitan ver o modificar al menos una parte de ese comportamiento oculto, posibilitando pruebas que anteriormente no eran posibles.
Scapy y Bluetooth
Antes de la versión 2.6.0, Scapy ya contaba con un soporte razonable para Bluetooth. Durante los ciclos de lanzamiento de las versiones 2.6 y 2.7 enviamos alrededor de 30 pull requests para mejorarlo.
El resultado es una cobertura modesta pero práctica de los protocolos HCI y ACL estándar: suficiente para comunicarnos con el chip controlador local y también para interactuar con hosts remotos. Todavía faltan algunas definiciones de paquetes, pero, en esencia, todo está preparado.
Sin embargo, todavía existen dos grandes limitaciones para llegar a las capas inferiores: los sockets existentes y el controlador.
Limitaciones de los sockets
El primer obstáculo consiste en cómo obtiene acceso el host al controlador:
- Los sockets Bluetooth de Scapy dependen del sistema operativo: solo Linux, sin soporte para Windows.
- Cada sistema operativo inicializa los controladores Bluetooth de forma diferente.
- Las distintas versiones del firmware incorporan diferentes mecanismos para gestionar particularidades (quirks), y el sistema operativo puede actualizar o reemplazar el firmware de los controladores antes de que podamos acceder a ellos.
- En ocasiones, los sistemas operativos validan el tráfico que entra o sale de los controladores
Para solucionar este problema, creamos UsbBluetooth, un controlador independiente del sistema operativo para dispositivos Bluetooth basado en LibUSB. Proporciona una conexión HCI directa con el controlador, sin ningún tipo de filtrado.
Integrarlo directamente en Scapy no tenía demasiado sentido: introduce una dependencia externa de libusb y requiere realizar pruebas con hardware real.
En su lugar, publicamos un paquete puente, scapy-usbbluetooth. Está diseñado para ser sencillo de utilizar: se enumeran los dispositivos, se abre un socket en uno de ellos y ese socket se convierte en un Scapy SuperSocket que permite enviar y recibir datos utilizando toda la capacidad de análisis de paquetes de Scapy.
De esta forma, pasamos del socket HCI estándar del sistema operativo a un socket HCI mejorado que funciona en cualquier sistema operativo sin las limitaciones descritas anteriormente.
Limitaciones del controlador
El segundo obstáculo es el propio controlador. La especificación base del controlador Bluetooth Core no proporciona acceso RF.
La comunicación con el controlador está estrictamente definida: se puede enviar un conjunto limitado de comandos que realizan un conjunto limitado de acciones, y eso es todo. Se podría argumentar que parte de la seguridad del protocolo depende precisamente de esta premisa.
Curiosamente, la especificación también contiene una sección que permite a los fabricantes implementar sus propios comandos específicos del fabricante (vendor-specific commands, VSC).
En la práctica, ahí es donde suelen encontrarse:
- Funciones de depuración que a menudo se olvidan y permanecen intactas en dispositivos de producción.
- Mecanismos de actualización y modificación de firmware.
- Comandos de configuración.
No esperes que ninguno de ellos esté documentado.
Qué buscamos
El esfuerzo de ingeniería inversa se centró en comandos del fabricante relacionados con cuatro capacidades, elegidas como pasos intermedios hacia un único objetivo final: cambiar la dirección MAC de un controlador.
- Información e identificación del dispositivo: una herramienta debe ser capaz de detectar con qué hardware está comunicándose antes de poder utilizar cualquier capacidad avanzada.
- Primitivas de lectura de memoria: para extraer información sobre el estado interno y realizar ingeniería inversa de los firmwares Bluetooth.
- Primitivas de escritura de memoria: si las primitivas de lectura no estaban disponibles, las de escritura podrían permitir obtenerlas mediante RCE y, posiblemente, modificar directamente la dirección.
- Cambio de dirección MAC: y, si existía un comando directo, documentarlo.
Fabricante por fabricante
Realtek
El mérito en este caso corresponde a Xeno Kovah y su charla de Hardwear.io 2025, en la que describió cómo obtener capacidades de lectura y escritura en controladores Realtek a partir de los archivos de firmware incluidos en el repositorio linux-firmware y de una utilidad de pruebas RF para estos chips.
Tomamos ese trabajo e integramos en Scapy los comandos de lectura y escritura de memoria.
El cambio de la BD_ADDR es posible en estos componentes, pero debe realizarse mediante un comando de configuración específico del fabricante con una complejidad suficiente como para que todavía no se haya implementado. Parece alcanzable en un futuro próximo.
Barrot
Nuestro compañero Isaac Lleida ha estado investigando los chips Barrot y ha publicado su trabajo en barrot-tools. Encontró un bootloader expuesto a través de una interfaz UART de un dispositivo físico y lo utilizó para extraer el firmware Wi-Fi/Bluetooth.
La ingeniería inversa de ese firmware produjo una lista de comandos de buena calidad, y los comandos de lectura, escritura, información y BD_ADDR se integraron en Scapy. En el caso de Barrot, Scapy ya dispone de todas las capacidades que estábamos buscando.
Todavía quedan comandos pendientes de integración.
CSR
En el caso de los dispositivos Cambridge Silicon Radio, el objetivo se alcanzó simplemente leyendo el código fuente de BlueZ. El parser csr.c no documenta completamente los detalles del protocolo, pero constituye una base muy buena para comenzar.
Los comandos de información y BD_ADDR se integraron en Scapy.
Todavía quedan muchos comandos por analizar, mediante ingeniería inversa, e integrar.
Intel
Intel constituye un caso particular. Como usuario de Bluetooth de Intel, el EULA «prohíbe» realizar ingeniería inversa de sus firmwares.
Por suerte, el driver de Linux documenta parcialmente algunos comandos, incluido el procedimiento para identificar los controladores.
El comando de información se integró en Scapy basándose en esta información.
Nordic y Zephyr
Los dispositivos Nordic utilizan una versión modificada del RTOS Zephyr, y Zephyr documenta parcialmente sus comandos específicos del fabricante en hci_vs.h.
A partir de ahí obtuvimos un comando de información y un comando para cambiar la BD_ADDR, y ambos se integraron en Scapy.
Hay muchos más disponibles para trabajos futuros.
Espressif
Espressif es el fabricante en el que ya habíamos invertido más esfuerzo, con la ingeniería inversa publicada en ESP32 hidden HCI vendor commands y la documentación más amplia del stack en Liberating Bluetooth on the ESP32.
Los comandos de lectura, escritura y BD_ADDR se están integrando actualmente mediante una pull request pendiente de aprobación.
Hay una salvedad importante: desde la publicación de aquella investigación, Espressif ha tratado algunos de los comandos específicos del fabricante descubiertos como problemas de seguridad (véase CVE-2025-27840), y los comandos de lectura y escritura han sido deshabilitados o eliminados en las versiones más recientes del SDK.
Soporte actual de Scapy
Figura 4. Resumen del soporte actual de comandos específicos del fabricante disponible en Scapy.
Cuatro de los seis fabricantes cuentan con soporte completo, lo cual no es una mala proporción y debería seguir creciendo.
Por qué es importante: ideas de ataque
La relevancia para la seguridad del control de la BD_ADDR se deriva directamente de cómo funciona la identidad Bluetooth:
- La identidad de un dispositivo Bluetooth se resume en la BD_ADDR.
- Esa identidad (BD_ADDR) se autentica mediante una clave de emparejamiento (pairing key).
- Una clave de emparejamiento es un secreto compartido válido para un único par de BD_ADDR.
Por tanto, el modelo de seguridad parte de la premisa de que un dispositivo no puede cambiar su propia BD_ADDR. Cuando esa premisa deja de cumplirse, se abren varias posibilidades:
- Si obtenemos una clave de emparejamiento Bluetooth, podemos suplantar completamente un dispositivo cambiando nuestra BD_ADDR y haciéndonos indistinguibles del dispositivo legítimo.
- Incluso sin disponer de la clave, suplantar una BD_ADDR nos permite alcanzar la fase de autenticación y recibir conexiones entrantes dirigidas al dispositivo suplantado. Esto, a su vez, proporciona una forma de descubrir dispositivos que no están anunciándose. En conjunto, supone una superficie de ataque considerablemente mayor que merece ser evaluada.
Herramientas y demostraciones
La teoría y las ideas están muy bien, pero ¿para qué sirven realmente todos estos VSC?
Se ha publicado un conjunto de ejemplos prácticos en TarlogicSecurity/BluetoothExamplesAndDemos.
Controller Info
Información avanzada sobre el controlador Bluetooth, combinando comandos HCI estándar y específicos del fabricante.
Está pensada como base para herramientas que necesiten reconocer controladores y utilizar las capacidades avanzadas que puedan ofrecer, así como para explorar las funcionalidades avanzadas del controlador.
Figura 6. Controller Info identificando un controlador RivieraWaves.
Vendor Command Enumerator
Una herramienta para fuerza bruta de comandos específicos del fabricante del controlador, enumerando e investigando qué funcionalidades avanzadas puede estar ocultando.
Se desarrolló principalmente para investigar los mismos dispositivos que ahora soportamos, pero también resulta directamente útil para probar tu propio hardware.
Figura 7. Vendor Command Enumerator recorriendo opcodes y analizando las respuestas con Scapy.
Firmware Dumper
Para dispositivos que disponen de comandos de lectura de memoria, este script localiza el controlador y extrae su firmware a un archivo.
Resulta especialmente interesante para comparar diferentes versiones de firmware entre dispositivos y estudiar mediante ingeniería inversa las capacidades de los controladores.
Figura 8. Firmware Dumper recopilando una imagen de firmware Realtek para su posterior análisis.
BD Addr Changer
La herramienta que buscábamos originalmente. Enumera los controladores disponibles y cambia la dirección pública en aquellos compatibles.
Figura 9. BD_ADDR Changer mostrando qué controladores exponen un comando de cambio de dirección utilizable.
Trabajo futuro
De cara al futuro, nos gustaría encontrar controladores de más fabricantes para poder probarlos.
Ya disponemos de información sobre los VSC de otros cinco fabricantes que no pudieron validarse por falta de hardware. Una vez probados, se podrán integrar más comandos.
Otra tarea consiste en integrar parte de este trabajo en BlueZ, comenzando por la herramienta bdaddr, para hacer que estas funcionalidades estén disponibles en Linux a nivel de sistema.
Un objetivo definitivo sería trasladar estos conocimientos de vuelta a BSAM Checker para mejorar la cobertura de la metodología y automatizar más controles.
Conclusiones
La estructura básica necesaria para añadir comandos Bluetooth específicos de fabricantes a Scapy ya está disponible.
Se han integrado comandos relevantes para la seguridad de varios fabricantes y, si estás dispuesto a investigar y realizar pruebas, las herramientas publicadas funcionan con los seis fabricantes cubiertos en este artículo.
Más allá de los VSC, también se ha integrado una cantidad significativa de soporte HCI estándar y correcciones de errores, y está previsto que lleguen nuevas mejoras de Bluetooth en Scapy v2.8.0.
Por último, un agradecimiento sincero a todos aquellos que mantienen Scapy. Mucha gente les debe un agradecimiento, y su paciencia nunca recibe suficiente reconocimiento.
Referencias
- UsbBluetooth: https://usbbluetooth.github.io/
- scapy-usbbluetooth: https://github.com/usbbluetooth/scapy-usbbluetooth
- Bluetooth examples and demos: https://github.com/TarlogicSecurity/BluetoothExamplesAndDemos
- Metodología BSAM: https://www.tarlogic.com/bsam/
- BSAM Checker: https://www.tarlogic.com/cybersecurity-products/bsam-checker/
- Barrot tools: https://github.com/tryger/barrot-tools/
- Investigación previa sobre Realtek: https://darkmentor.com/publication/2025-11-hardweario/
- Slides: https://github.com/TarlogicSecurity/talks