Is there currently a road map for adding injection/jamming for this hardware? about sniffle HOT 13 CLOSED

I do have initiator, master, advertiser, and slave modes implemented, along with support for sending/receiving arbitrary link layer data. This is currently on a private internal branch as part of a larger project of mine, but it should become public later this year.

from sniffle.

It's certainly possible with the hardware, and it's something I've contemplated implementing.

Jamming is quite straight-forward to implement, so I could add that in the near future. Jamming with a regular CC1352R/CC2652R would probably work, but jamming with a CC1352P/CC2652P might work better due to the power amplifier being able to better drown out the legitimate device.

Frame injection is more work, requires more precise timing, and would require more thought on transmissions conflicting/overlapping the real master/slave. Something along the lines of BTLEJack would be needed, and it would be best to collaborate with Damien on this front. It's also a matter of finding time, and a specific use case.

One other feature I've experimented with but not released is identifying access adresses of existing connections by syncing on the preamble (similar to Ubertooth and BTLEJack). I've had it sort-of working, but I need to fiddle with radio configuration more to improve performance/reliability, as it was far from where I wanted last time I played with it.

It's all a matter of finding time :)

from sniffle.

Well if you have a POC concept somewhat built out for jamming I would be more than happy to test it for you! Just got my CC2652R dev board today! I can try and collaborate with Damien to try and port his "Time-out" attack to this hardware.

To once again reference the KNOB attack. They claim that you can pull this attack off over the air, and decrypt BLE Secure Connection in real time! It might be worth putting some effort into that. If the KNOB attack is successfully I believe injecting/hijacking secure connections might be possible using the BTLEJack timeout attack with encryption layered on top.

from sniffle.

Regarding the KNOB attack - the attack is much less practical on Low Energy compared to Classic.

In Classic, the KNOB attack is in the negotiation of the connection encryption key K_c, so it’s done on every connection establishment. In LE, the attack is in the pairing phase (LTK generation), so you need to be present and jam/transmit while the victim devices are pairing to force the negotiation of a weak LTK.

Also, brute forcing a 56 bit key (7 byte), while possible with enough computational hardware, is still very slow and expensive even if you rent out a big chunk of AWS. LE requires a minimum key strength of 56 bits, while it’s classic that permits the 8 bit minimum.

from sniffle.

Hmmm. In the official video https://youtu.be/v9Xg9XcnNh0 the researchers show a table clamming that bluetooth versions 4.0 - 5.0 are all affected. Which from what I understand Classic is Bluetooth < 4.0.

Additionally, the researcher says that the vulnerability is in the "Entropy Negotiation" phase. He also states that this is done AFTER the devices have already negotiated a LTK and are using that to connect to one another.

I don't think he says the attack is in the negotiation of the key, its in the negotiation of the Entropy. Am I missing something?

from sniffle.

Bluetooth Classic includes 4.0-5.1. It’s still part of the current specification, just not having new features added. The attack you’re referring to is in connection key negotiation for BR/EDR aka. Bluetooth Classic.

from sniffle.

Yes indeed. My mistake. I re-read the researchers paper where it clearly states the differences you stated. Noice!

Well that sucks that KNOB is pretty much only viable for Bluetooth Classic. But don't a wide variety of devices use Bluetooth Classic like phones and computers?

Do you think the hijack attack presented by BLEJack is viable and portable for both BLE and Classic? From what I understand to hijack a device this would require the device does not use encryption?

from sniffle.

Attacks similar to what BTLEJack does should be possible with classic. At least later versions of Classic enforce encryption, so connection hijacking may be less useful there. A better approach may be to jam existing classic connections to force a reconnect, then conduct the KNOB attack over the air on reconnect.

There are fewer affordable low-level radio tools for classic due to the combination of lower interest, more frequent channel hopping (tighter timing), and many PHY modes with a limited number of low cost flexible radios that support them. The Ubertooth has some crude Classic BR support, and something similar should he possible to implement something similar here with the proprietary radio mode. For EDR, I’ll have to read the CC26x2 data sheet in more detail to see if it’s possible.

Most new IoT gadgets I see nowadays use LE, but Classic is still the norm for headphones and hands free calling from cars.

Classic and LE are practically two unrelated specifications that both happen to be branded as Bluetooth, have overlapping use cases. and both use the 2.4 GHz spectrum, but don’t have much in common beyond that.

from sniffle.

Yes I think having some support for Bluetooth Classic for this platform would make this the best platform available for sniffing. What about support for connecting to devices like BTLEJack? How difficult would this be to implement?

from sniffle.

I'm planning on implementing support for BLE scanner, initiator, master, and slave roles in the next few weeks as part of a bigger project I'm working on.

from sniffle.

That sounds amazing @sultanqasim, I'm really keen to see where this goes

from sniffle.

I've pushed a branch that includes basic link-layer functionality.

from sniffle.

Basic functionality released with version 1.3

from sniffle.