Whats the reason for a "Hijacking failed"?

virtualabs / btlejack

Bluetooth Low Energy Swiss-army knife

MIT License

1.9k stars 196 forks source link

Whats the reason for a "Hijacking failed"? #56

Closed whoot closed 1 year ago

whoot commented 4 years ago

Hey, I´m having an issue where btlejack cant hijack an bluetooth LE connection:

btlejack -f 0xaf9a9cde -t -m 0x1bff001fff -p 39

BtleJack version 2.0

[i] Detected sniffers:
 > Sniffer #0: fw version 3.14
 > Sniffer #1: fw version 3.14
 > Sniffer #2: fw version 3.14

[i] Synchronizing with connection 0xaf9a9cde ...
✓ CRCInit = 0x48ef4a
✓ Channel map is provided: 0x1bff001fff
✓ Hop interval = 39
✓ Hop increment = 8
[i] Synchronized, hijacking in progress ...
[!] Hijack failed.

And im not sure if the issue is myself or the connection or btlejack. Can you explain why Hijacking does not work or what the issue could be?

EDIT: capturing the traffic works as expected with the same CRCInit, Channel Map, Hop interval and Hop increment values.

virtualabs commented 4 years ago

Well, I'm currently thinking about two possible reasons:

the channel map may have changed: channel map updates are not supported (yet) while jamming a connection
low supervision timeout: detecting a successfully jammed connection takes some time as btlejack waits for no packets sent by the master device, but if latency is low then this master device may consider the connection lost before btlejack does the same and start sending packets to keep the connection alive.

whoot commented 4 years ago

Well, I'm currently thinking about two possible reasons:
* the channel map may have changed: channel map updates are not supported (yet) while jamming a connection
I can rule that out, because sniffing the traffic after failing to hijack the session still works with the same parameters.
* low supervision timeout: detecting a successfully jammed connection takes some time as btlejack waits for no packets sent by the master device, but if latency is low then this master device may consider the connection lost before btlejack does the same and start sending packets to keep the connection alive.

Ok so basically the master needs to stop sending packages to the slave to make this attack work?

virtualabs commented 4 years ago

I can rule that out, because sniffing the traffic after failing to hijack the session still works with the same parameters.

Allright, that means btlejack did not managed to jam this connection. A few ideas to improve the attack:

Place your Micro:Bit close to your master device (e.g. your smartphone) as it has more chance to jam your slave packets
Obviously, keep your slave device away but still in range

Ok so basically the master needs to stop sending packages to the slave to make this attack work?

This attack is based on jamming: btlejack jams every packet sent by the slave to the master (once it is synchronized), detects when the master considers the connection lost (no more packets from the master) and spoofs the master.

whoot commented 4 years ago

Placing the Mirco:Bit closer to the master device worked! However, I cant get any results:

btlejack -f 0x17242e08 -t -m 1fffffffff --hop-interval 40
BtleJack version 2.0

[i] Using cached parameters (created on 2019-10-28 12:43:04)
[i] Detected sniffers:
 > Sniffer #0: fw version 2.0
 > Sniffer #1: fw version 2.0
 > Sniffer #2: fw version 2.0

[i] Synchronizing with connection 0x17242e08 ...
✓ CRCInit: 0xd2545f
✓ Channel map is provided: 0x1fffffffff
✓ Hop interval = 40
✓ Hop increment = 8
[i] Synchronized, hijacking in progress ...
[i] Connection successfully hijacked, it is all yours \o/
btlejack> discover
btlejack>

virtualabs commented 4 years ago

See #64, I've just answered this question in details.