Non che io abbia mai sentito nominare. La comunicazione Bluetooth non è progettata come la comunicazione wifi. Quando rilasciamo i client tramite il metodo che comunichi della comunicazione avviene al 2.4Ghz (o più recentemente a 5Gz) tutte le comunicazioni vengono effettuate a quell'intervallo in base ai canali.
Il Bluetooth è un po 'diverso. documento di specifiche v4.0 qui:
Nel caso di router Internet sono sempre disponibili per parlare in base a BSSID ed ESSID e lo usiamo anche per determinare i client ad essi connessi con qualcosa come aerodump.
Nel caso di Bluetooth, tuttavia, se un dispositivo non è rilevabile avremmo bisogno di conoscere il bd_addr a 48 bit. in modalità inaffidabile il dispositivo non risponderà ai tentativi di scansione e non ci rivelerà questo. ma supponiamo che tu l'abbia in qualche modo catturato quando è stato individuabile.
Quando la comunicazione inizia, i messaggi vengono inviati in quelle che vengono chiamate pagine e qui è dove le cose si divertono. Tra le fasi richieste per la comunicazione vi sono quella di sincronizzazione dell'orologio e accordo di frequenza (tra cui un codice di accesso principale del canale) e la sequenza di salto del canale, questa è la principale differenza nella comunicazione dei dispositivi wlan.
Questo è il modo in cui si formano le piconet (la piccola rete in cui ogni dispositivo master e slave esiste), ciascuna con il proprio meccanismo di salto di frequenza e codice di accesso al canale. vedere la sezione 4.1.1 sulla topologia. Questo è quello che penso sia il problema principale con la creazione di un attacco simile qui. ma ci arriveremo tra un po '. solo sapere che stiamo parlando di 1600 luppolo al secondo. È importante notare anche che se un dispositivo Bluetooth è il padrone di una connessione, non può essere il padrone di un'altra connessione. Può tuttavia essere uno schiavo di più connessioni. Quindi un hub Bluetooth molto probabilmente effettuerà le connessioni come slave. Poiché anche il codice di accesso e la frequenza di sperimentazione sono definiti dal dispositivo master, ciò gioca un ruolo nel motivo per cui ritengo che non possa essere fatto. Vedi 3.1 per la sequenza di connessione completa.
Una volta terminata la connessione, un LMP_detach può essere inviato da un dispositivo all'altro ma non è richiesto, né è richiesta la risposta. Inoltre, non c'è alcuna garanzia che io possa vedere qui, che un dispositivo slave ignorerà qualsiasi comunicazione dopo aver ricevuto un LMP_detach o un soft reset. Penso che se è trascorso un tempo sufficiente per la desincronizzazione, la risincronizzazione sarebbe semplicemente necessaria.
Per riassumere tutto, al fine di emettere il LMP_detach avremmo:
- per ottenere il bd_addr del dispositivo che desideriamo spoofare
- ottenere il codice di accesso principale di quella comunicazione
- conosci la topologia del salto di frequenza
- avere un master clock completamente sincronizzato con il dispositivo (e quindi con lo slave)
- emettere il comando come master
- spero che smetta di rispondere
Oh e c'è anche la crittografia da qualche parte.
Come ho detto, non ho mai provato questo? ma penso che la sincronizzazione dell'orologio e il salto di frequenza sarebbero i maggiori ostacoli per ottenere qualcosa del genere. Non sono comunque in grado di dire ciò che è impossibile. E io non sono esperto in Bluetooth di gran lunga. Se è stato fatto, id ama vederlo! Ma questo è solo il mio 2c.
Non penso che possa essere fatto.