virtualabs / btlejack

Bluetooth Low Energy Swiss-army knife
MIT License
1.88k stars 195 forks source link

Hijack seems to be not working #17

Closed ghost closed 6 years ago

ghost commented 6 years ago

Hi

I have setup three microbit devices to sniff connections for pentesting our BLE-application. I am able to find the connection and to sniff packets (though the first packet output takes a real long time > 10 minutes). But when I try to hijack the connection it seems like nothing happens after starting the hijacking:

BtleJack version 1.1

[i] Using cached parameters (created on 2018-08-23 08:52:21) [i] Detected sniffers:

Sniffer #0: fw version 1.1 Sniffer #1: fw version 1.1 Sniffer #2: fw version 1.1

[i] Synchronizing with connection 0xb3460c11 ... ✓ CRCInit: 0xf044f7 ✓ Channel map is provided: 0x1fffffffff ✓ Hop interval = 12 ✓ Hop increment = 12 [i] Synchronized, hijacking in progress ...

I have waited for more than half an hour but nothing happens from here. Is there any possibility to have a more verbose output?

Regards Frank

virtualabs commented 6 years ago

Hi,

I have setup three microbit devices to sniff connections for pentesting our BLE-application. I am able to find the connection and to sniff packets (though the first packet output takes a real long time > 10 minutes).

It looks like your sniffer is not synchronized with the target connection. I see that you specified the channel map (0x1fffffffff) and that the sniffer managed to recover a valid hop interval and increment, but I'm suspecting this channel map to be different than 0x1fffffffff and therefore to give wrong results (bad hop interval and increment values).

Since this channel map is invalid, it is very likely the sniffer does not manage to synchronize with your target connection and therefore cause you a lot of trouble. The packets you captured during sniffing are purely due to collisions, the sniffer sitting on a channel used by the connection at this precise moment. And of course, you cannot jam this connection without being completely synchronized: btlejack will send jamming packets on the "colliding" channels, and will not jam the connection during enough time for this attack to work.

ghost commented 6 years ago

Hi

thanks for the quick reply. This might be the reason, but why is "Synchronized" written in the output when the synchronize failed? How can I force the synchronization?

Regards, Frank

virtualabs commented 6 years ago

This might be the reason, but why is "Synchronized" written in the output when the synchronize failed? The message displayed by Btlejack is a bit ambiguous here. This "synchronization" is in fact the moment where the sniffer is waiting on a specific channel for a packet sent by the master device (e.g. your phone). Once this packet received, the sniffer then hops from one channel to another based on the parameters it has previously recovered. It does not mean the sniffing is successful, and yes this is a problem.

I should add a mechanism to determine if a connection is lost, in order to tell the user if an error occured. I added this to my todo list.

How can I force the synchronization?

In your case, the best way is to let Btlejack discover the channel map (you are using 3 sniffers, this will speed up the process) and it will synchronize itself with your target connection, unless the channel map changed during the recovery. If the channel map changes while you are trying to recover it, btlejack will not be able to recover the hop interval.

virtualabs commented 6 years ago

Version 1.2.0 released, including a fix for this issue (automatic connection loss detection).