Open sultanqasim opened 4 years ago
Postponing to version 1.4, since I've already implemented a bunch of improvements I could tag as 1.3.
Hello, Thank you for this great solution. I was using the prebuilt firmware binary from release v1.4 and notice that the capture stops after LL_START_ENC_REQ. I assume this is due to decryption issue and understand that this is still work in progress. May I know your plan on adding this support? From the comment, it seems like it is added in release 1.4, not sure if i am missing something. looking forward to see your comments on this. Thanks.
The reason capture usually stops soon after an LL_START_ENC_REQ is that connection parameters are often changed after a connection is set up (usually for power saving or latency reduction reasons), and Sniffle cannot decipher encrypted connection parameter changes. My plan is to implement decryption in the firmware (where you supply the LTK), though I don't really have a schedule for when things will be implemented, it's just a matter of when I have the time and the mood to do it. Another thing I plan to implement is automated cracking of legacy pairing using just works or 6 digit PIN (ie. what crackle does) so that you don't need to use crackle separately, and don't miss the first encrypted connection.
Thank you for the response.
Still haven't implemented decryption within the firmware, but I did recently implement features to improve sniffing of encrypted connections with an unknown key.
While it’s possible to decrypt after capture with crackle, this has limitations. Connection parameter changes occurring over an encrypted link can’t be handled by the firmware since they’re also encrypted. This can be solved by implementing decryption within the firmware (when LTK is known). The firmware should also report back a flag with every packet indicating whether or not it was decrypted before being sent to the host, and the host can note this in the PCAP (the format supports this).
Planned for version 1.3