mikeryan/crackle

Decrypt LE Secure Connection with known LTK does not work

jkrauss1987 opened this issue · 2 comments

jkrauss1987 commented

Hi, I have a pcap file from sniffing an LE Secure owner pairing. I have got the correct LTK on another way.
The output of the tool reports a successful decription and a new output.pcap file is generated. But when i load it into Wireshark the payload of the decypted packets is much less than in the original files messages and Wireshark says "bad MIC" just like in the original file.

Original File:
image

Decrypted File:
image

So my question is: Is the "decrypt with LTK" part of crackle able to decript LE Secure Connection when the LTK is known?

Many Thanks!

jkrauss1987 commented

I just saw that the decryption seems to work well but the problem is rather that the BT LE Link Layer and the BTL2CAP Layer are not recognized/parsed by Wireshark. I think that might be because the BTLE.CRC value is not recalculated but instead set to 0x 00 00 00. Is there a way to say Wireshark to ignore that?

In addition i saw that crackle does not change the Length Field of the payload (nordic_ble.plen). I am using a nordic nRF BLE Sniffer. The second and third byte of the frame is for the payload length. Could this be implemented?

image

Regards

trentp-igor commented

Decrypting LE Secure Connection with LTK doesn't seem to work at all for me.

Without supplying LTK, it fails as expected:

 Analyzing connection 0:
  44:01:bb:a0:d6:17 (public) -> 48:27:e2:2d:9a:66 (public)
  Found 23 encrypted packets
  Unable to crack due to the following error:
    LE Secure Connections

With LTK it just doesn't decrypt the packets for some reason:

[crackle]$ ./crackle -i ../pairing.pcapng -l AD1FE6CCEE0E20E701108DE0141BE9ED -o test.pcap
…
Analyzing connection 0:
  44:01:bb:a0:d6:17 (public) -> 48:27:e2:2d:9a:66 (public)
  Found 23 encrypted packets
  Decrypted 0 packets