Not that i have ever heard of. Bluetooth communication is not designed like wifi communication. When we drop clients via the method you speak of the communication happens at the 2.4Ghz (or more recently at 5Gz) all communication is done at that range give or take depending on the channels.
Bluetooth is a little different. v4.0 specification document here:
In the case of internet routers are always available to talk to based on the BSSID and ESSID and we also use this to determine the clients connected to them with something like aerodump.
In the case of Bluetooth however, if a device is not discoverable we would need to know the 48 bit bd_addr. in undiscoverable mode the device wont respond to scanning attempts and will not reveal this to us. but we'll assume you have it somehow, captured it when it was discoverable.
When communication starts the messages are sent in what are called pages and this is where things get fun. Amongst the steps required for communication are that of clock synchronization and frequency agreement (among which a channel master access code) and channel hopping sequence, this is the main difference in the communication of wlan devices.
This is how piconets (the little network each master and slave device exist in) are formed, each with its own frequency hopping mechanism and channel pass code. see section 4.1.1 on the topology. This is what i think is the main problem with creating a similar attack here. but well get to that in a bit. just know we're talking about 1600 hops per second. Its important to also note that if a Bluetooth device is the master of a connection, it cannot be the master of any other connection. It can however be a slave of multiple connections. So a Bluetooth hub will most likely make connections as a slave. Since the access code and frequency hoping are also defined by the master device this also plays a role in why i think it cant be done. See 3.1 for full connection sequence.
Once the connection is finished an LMP_detach can be sent from one device to the other but it is not required, nor is the response required. There is also no guarantee that i can see here, that a slave device will ignore any communications after receiving an LMP_detach or soft reset. I think that if sufficient time for desynchronization to occur has passed, resynchronization would simply be necessary.
To sum it all up, in order to issue the LMP_detach we would have:
- to get the bd_addr of the device we wish to spoof
- obtain the master access code of that communication
- know the frequency hop topology
- have a master clock completely synchronized with the device (and therefore the slave)
- issue the command as the master
- hope it stops responding
Oh and there is encryption somewhere in there too.
Like i said, I've never tried this? but i think that the clock synchronization and frequency hopping would be the biggest hurdles to achieving something like this. I'm not one to say anythings impossible though. And I'm no expert in Bluetooth by far. If it has been done, id love to see it! But this is just my 2c.
I don't think it can be done.
