search

virtualabs / btlejack

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

computing CRCInit value #30

Closed Wini3114 closed 4 years ago

Wini3114 commented 5 years ago

When I try to follow a connection, after executed -s command, it always stops at computing CRC init value and computes without an ending, but doesn't find anything. Is there any trick or suggestion on what to do? And what exactly is the CRCInit value? Thanks in advance!

thisguy23 commented 5 years ago

same here. 3333

virtualabs commented 5 years ago

Allright, this one puzzled me a bit but I think I know what is happening.

When Btlejack sniffs for available access addresses, it relies on the nRF51822 sniffing mode which is basically a hack (this chip has no "official" sniffing capability). That said, the sniffed access addresses are prone to errors and some bits of the actual access address may have been sniffed wrong, leading to an inexisting access address value.

If you try to follow the connection corresponding to this access address, you will fail as it does not correspond to any existing connection and therefore Btlejack won't be able to capture packets and recover this connection's CRC initial value (CRCInit). If you want more information about this value, you might consider reading the Bluetooth 4.2 core specifications or even watch my talk at DEF CON or Mike Ryan's talk at WOOT13 (the man who started it all :p).

Anyway, when using Btlejack -s option, please consider a valid access address when more than 5 packets has been caught. Try again with that in mind, and come back here if it still does not work.

thisguy23 commented 5 years ago

I have found that forcing more packets will allow it to complete, but then it will stall again on "computing hop increments" Thanks for all your efforts, and assistance.

virtualabs commented 5 years ago

Again, you may have hit another known issue: Btlejack's channel map scanning default timeout. To explain it shortly, Btlejack determines a connection actual channel map by listening for packets on each channel. If no packet has been received during a specific amount of time, then it times out and continue with another channel, assuming the previous channel is not used.

The problem is the following: if a BLE connection uses a high value of hop interval, Btlejack will timeout BEFORE a legitimate packet is sent on the channel under test, and therefore consider this channel as unused while it is actually used by this connection. This is why I've added the -n option, that lets you decide what this timeout should be.

So, you should first try to capture a connection request to get an idea of what the hop interval value is (be careful, it is sometimes updated after the connection request) and then determine if you need a higher timeout value. Or you may want to try with a timeout of maybe 10 seconds per channel:

$ btlejack -f <access address> -n 10000

And see if it solves your issue.