No es de lo que he oído hablar. La comunicación Bluetooth no está diseñada como la comunicación wifi. Cuando dejamos a los clientes a través del método del que habla, la comunicación ocurre a 2.4GHz (o más recientemente a 5Gz), toda la comunicación se realiza en ese rango de dar o recibir, dependiendo de los canales.
Bluetooth es un poco diferente. Documento de especificación v4.0 aquí:
En el caso de los enrutadores de Internet, siempre están disponibles para hablar según BSSID y ESSID, y también lo usamos para determinar los clientes conectados a ellos con algo como aerodump.
Sin embargo, en el caso de Bluetooth, si no se puede detectar un dispositivo, deberíamos conocer el bd_addr de 48 bits. en modo no visible, el dispositivo no responde a los intentos de escaneo y no nos lo revelará. pero asumiremos que lo tiene de alguna manera, lo capturó cuando fue detectable.
Cuando comienza la comunicación, los mensajes se envían en lo que se llama páginas y aquí es donde las cosas se ponen divertidas. Entre los pasos necesarios para la comunicación se encuentran la sincronización del reloj y el acuerdo de frecuencia (entre los que se incluye un código de acceso maestro del canal) y la secuencia de salto de canal, esta es la principal diferencia en la comunicación de los dispositivos wlan.
Así es como se forman las piconets (la pequeña red en la que existen los dispositivos maestro y esclavo), cada una con su propio mecanismo de salto de frecuencia y código de paso de canal. Ver la sección 4.1.1 sobre la topología. Esto es lo que creo que es el principal problema con la creación de un ataque similar aquí. Pero bueno lleguemos a eso en un momento. Sólo sé que estamos hablando de 1600 saltos por segundo. También es importante tener en cuenta que si un dispositivo Bluetooth es el maestro de una conexión, no puede ser el maestro de ninguna otra conexión. Sin embargo, puede ser un esclavo de múltiples conexiones. Por lo tanto, un concentrador Bluetooth probablemente hará conexiones como esclavo. Dado que el dispositivo maestro también define el código de acceso y la esperanza de frecuencia, esto también desempeña un papel en la razón por la que creo que no se puede hacer. Ver 3.1 para la secuencia de conexión completa.
Una vez finalizada la conexión, se puede enviar un LMP_detach de un dispositivo a otro, pero no es obligatorio, ni se requiere la respuesta. Tampoco hay garantía de que pueda ver aquí, que un dispositivo esclavo ignorará cualquier comunicación después de recibir un LMP_detach o un reinicio por software. Creo que si ha pasado el tiempo suficiente para que ocurra la desincronización, la resincronización simplemente sería necesaria.
Para resumir todo, para emitir el LMP_detach tendríamos:
- para obtener el bd_addr del dispositivo que deseamos falsificar
- obtenga el código de acceso maestro de esa comunicación
- conocer la topología del salto de frecuencia
- tener un reloj maestro completamente sincronizado con el dispositivo (y, por lo tanto, con el esclavo)
- emita el comando como maestro
- espero que deje de responder
Ah, y también hay encriptación en algún lugar allí.
Como dije, nunca he probado esto? pero creo que la sincronización del reloj y el salto de frecuencia serían los mayores obstáculos para lograr algo como esto. Aunque no soy alguien que diga nada imposible. Y no soy un experto en Bluetooth por mucho. Si se ha hecho, me encantaría verlo! Pero esto es solo mi 2c.
No creo que se pueda hacer.