btlejack does not respond to the commands after taking control of my device

[TanKil]

Hi,

After taking control of my lawnmower, btlejack does not respond to the commands (e.g. "discover"). Nothing really happens after that. Any ideas what it could be?

[virtualabs]

It could be caused by the provided channel map. If the channel map changes very often, hop interval and hop increment computations will succeed but may give incorrect results, leading to a desync. Basically, two scenarios render the hijacking almost impossible (with the actual version of btlejack):

• BTLE connection is actually encrypted: btlejack is not able to decrypt the packets used by the master to notify a new channel map and therefore is desynchronized, causing the firmware to believe the hijacking was successful as it won't catch any packet from the master device

• recovered BTLE connection parameters are wrong: btlejack catches a valid packet from time to time, but is completely desynchronized. This can be due to very frequent channel map updates sent by the master, especially during hop interval computation. I noticed this with some Samsung devices which BTLE chip tried to improved the connection and regularly updated the channel map.

The problem here is there is absolutely no way to determine if we successfully hijacked an existing connection except by looking for a lack of communication from the master. And this is exactly what you get with wrong parameters or if the connection is encrypted. Moreover, it takes some seconds to btlejack to detect that a connection is lost through a timeout but if it catches a valid packet in between, this timeout is reset and it may be stuck for a long time. In this case, the CLI won't tell you the connection is lost as it keeps getting packets from time to time. If this occurs after a "successful hijacking", then you would end up with this exact behavior.

My (2 cents) advice: try to sniff a regular connection with the same devices (option -c) and save the captured packets into a PCAP. Wait a few minutes before stopping btlejack. Analyze the captured packets with Wireshark, and if you see a lot of LL_CHANNEL_MAP_REQ packets that would mean your central device is updating the connection channel map quite often. Furthermore, you may want to sniff multiple connections this way and compare the CONNECT_REQ packets (which also contains the channel map used when initiating the connection) and see if this value changes from one connection to another.

Hope this helps. And yes, it took me ages to answer it, sorry about that.