At least for listening, a $100 software defined radio would be able to sample the whole band in one go without needing to follow the frequency hops.

I don’t think the price point is quite that low yet, is it? I have a couple I bought for $250 that can do that, but I’m not aware of a readily available radio that can receive 80MHz+ at that price point. If you can point me to it, I’ll probably buy a couple immediately.

I own most of the commonly available SDRs, and I’m also not aware of any that can do that wide of a range at $100 price point. Like you, I’d be happy to be proven wrong (albeit my wallet won’t be).

79MHz, so you will need 4x $100 HackRF (price for bare board, no case/cabling). https://www.ebay.com/itm/HackRF-One-1MHz-to-6GHz-Software-De...

I have several HackRF boards. That’s not 80MHz for $100, that’s 20MHz for $100.

This is not a trivial attack. Within the short key negotiation phase, the attacker must simultaneously prevent the two devices from hearing each other, and be transmitting in their place at the exact frequency hop and interval.

"The attacking device would need to intercept, manipulate, and retransmit key length negotiation messages between the two devices while also blocking transmissions from both, all within a narrow time window. "

That quote is from the Bluetooth standardisation group’s response. They are clearly trying to downplay the seriousness with their choice of language here. “All within a narrow time window” is, generally speaking, something computers are capable of handling. I have no idea from that statement how easy/tricky this attack is. Also, is it really necessary to block transmissions, or can the attacker just “get lucky” and have his transmissions received first? (Honest question, I have no idea)

For BT, it's not a matter of transmitting first (for Wifi it would be), but rather transmitting in the exact time slot that the two devices are expecting each other to transmit. This is tightly timed in BT devices (tens of microseconds)--they are only listening on tiny intervals and only expected to transmit on tiny intervals. It would sound like periodic chirping if you were able to hear it with your ears.

Meanwhile, the two BT devices are going to be transmitting in their normal time slots, so you would need to prevent them from being heard by the peer-- otherwise, the combined transmission (of the attacker and original BT device) will look like noise to the receiver and the attack would fail.

The attack is certainly doable, but in a practical setting would be extremely difficult.

You are not thinking like an attacker.

The attacker has to hit the precisely correct time slot. However, there is no penalty for hitting the wrong time slots, so the easy solution is to just sync the timeslot boundaries by listening once and then retransmit on every timeslot.

The attacker has to somehow prevent the listener from hearing the original transmission. If the attacker retransmits at a similar power, as BT devices usually do, the combined transmission will look like noise. However, the attacker doesn't need to care about things like FCC rules or BT standards, and can simply transmit at a power few order of magnitudes greater, so that what the receiver hears is pretty much just the attacker.

There certainly is a penalty for missing time slots (especially if you're trying to overpower the other transmitter). There are two reasons for this: (1) the victim device will have hit the time slot and the pairing process will move into the next stage and (2) packet counters will prevent you from using the same packet in the wrong slot.

Trying to overpower the transmission of the BT peer is certainly the technique to take (although I was hoping not to broadcast that publicly in my original post). You will still have a tough time, however, because you're probably trying to overpower the transmission of two collocated devices (e.g. keyboard+computer) while you are 5-50feet away. In many cases you'll probably end up saturating the receiving antenna. It will be largely a trial-and-error technique, but it will work eventually.

> packet counters will prevent you from using the same packet in the wrong slot.

Source to back up that claim? I am not an expert, but have enough experience on the topic to feel justified in feeling that’s wrong.

The way you're describing this makes it sound like an extremely difficult process. In some ways, it is. However, every BT device that exists is currently capable of doing this frequency tracking and tight timing. It's merely a matter of starting to transmit slightly earlier and significantly louder than a normal BT transmit after sniffing the start of the connection.

This attack should be possible from any software-defined radio that's capable of sniffing on and forming BT connections.

Quoting my response to Tuna-Fish: "Trying to overpower the transmission of the BT peer is certainly the technique to take (although I was hoping not to broadcast that publicly in my original post). You will still have a tough time, however, because you're probably trying to overpower the transmission of two collocated devices (e.g. keyboard+computer) while you are 5-50feet away. In many cases you'll probably end up saturating the receiving antenna. It will be largely a trial-and-error technique, but it will work eventually."

And if you do manage, it's granting the ability to intercept/modify traffic, right?

If so, this won't lead to RCE on a host mobile unless other exploits are used. There's probably some interesting stuff that can be done against shitty IOT-type devices, but they should be assumed vulnerable anyway...

That's true for use cases like phones and headsets where the physical device can't reasonably be tampered with. But this sounds like something you could trivially squish on top of an unattended reader device a-la credit card skimmers.

Not sure I understand what you mean.

If one side of the communication is a fixed device subject to simple tampering (e.g. "put your phone here for access") then you can MitM the connection is much the same way as was done with ATM skimmers.

Or with a little more difficulty, you could pop open a bluetooth keyboard, put a shield over the antenna, and MitM what it says to its already-paired desktop to implement a keylogger.

These aren't remotely accessible vulnerabilities to internet hackers, but they're the kind of thing that has been done by amateurs in the past in other realms.

Agree that it would be significantly easier if you had physical access either of the devices. However, with physical access there are probably even easier attack vectors (e.g. in the case of a keyboard, why not just capture the key presses directly instead of trying to capture it as it's going over BT?).

Depending on the BT tech your hopping either 79 or 29 channels, not that many. Find the increment and hop timing and you can hop along with them.

>you can hop along with them

The hopping sequence is determined pesudorandomly (not sequentially) using the link key, so you can't exactly "hop along" once you find the right channel.

I thought the hopping sequence and clock was adopted from the master during the paging process, as the slave joins the network, before the link negotiation process even begins.

https://courses.cs.washington.edu/courses/cse474/18wi/pdfs/l...

There are Bluetooth sniffers available for low $ks that can listen on all channels simultaneously.

Assuming you mean “low thousands” by that, you can get them for under a third of that price easily.

Cheaper ones can track a single connection, but they can't listen to all channels simultaneously.

There are a handful of SDRs that can handle 80MHz for well under $1k.