Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decryption Support #7

Open
sultanqasim opened this issue Feb 18, 2020 · 5 comments
Open

Decryption Support #7

sultanqasim opened this issue Feb 18, 2020 · 5 comments
Assignees
Labels
enhancement New feature or request

Comments

@sultanqasim
Copy link
Collaborator

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

@sultanqasim sultanqasim added the enhancement New feature or request label Feb 18, 2020
@sultanqasim sultanqasim self-assigned this Feb 18, 2020
@sultanqasim
Copy link
Collaborator Author

Postponing to version 1.4, since I've already implemented a bunch of improvements I could tag as 1.3.

@avinashnp81
Copy link

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.

@sultanqasim
Copy link
Collaborator Author

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.

@avinashnp81
Copy link

Thank you for the response.

@sultanqasim
Copy link
Collaborator Author

sultanqasim commented Apr 12, 2021

Still haven't implemented decryption within the firmware, but I did recently implement features to improve sniffing of encrypted connections with an unknown key.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants