Computing Hop Increment - TIME SENSITIVE

[oncegrey]

Hi all! I am a cybersecurity student using btlejack for some investigations

I am trying to perform all attacks but am having issues with computing hop increment, I read through some questions that were similar and have followed advice. I am using 3 v1.5 microbits to try process this but it still seems to be taking a long time.

Any advice?

btlejack -f 0x50657d59 -j 
BtleJack version 2.0

[i] Using cached parameters (created on 2022-10-05 15:23:22)
[i] Detected sniffers:
 > Sniffer #0: fw version 2.0
 > Sniffer #1: fw version 2.0
 > Sniffer #2: fw version 2.0

[oncegrey]

@virtualabs Sorry to bother you, but I'd love a hand on this. I'm actually writing a paper on your software for my university and would really love some help on this if you can.

[virtualabs]

Hop increment recovery can be impacted by regular channel map updates, and this is more and more common on recent BLE chips. Your device may also use BLE version 5 with its new channel selection algorithm (CSA #2) which does not use the legacy hopping mechanism and thereforce btlejack cannot guess the key parameters to synchronize with the existing connection.

[oncegrey]

Hop increment recovery can be impacted by regular channel map updates, and this is more and more common on recent BLE chips. Your device may also use BLE version 5 with its new channel selection algorithm (CSA #2) which does not use the legacy hopping mechanism and thereforce btlejack cannot guess the key parameters to synchronize with the existing connection.

Hi! So the device is BLE 4.0 and I managed to get it to work using -m 0x1fffffff which seemed to fix the issue and jam the connection and then it died due to jamming which is what I expected to see. I'm hoping if it computes here then hijacking will also work. I am wondering though the best way to record this evidence. I tried using the built-in packet capture but the output pcap seems to be blank.