Computing Hop Increment - TIME SENSITIVE
oncegrey opened this issue · comments
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
@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.
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.
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.