Encrypted packets found but not decrypted

Question

Encrypted packets found but not decrypted

Closed this issue 4 years ago · 11 comments

It is not showing any errors but not decrypting the connections as well. What's wrong ?

crackle -i captured.pcapng -o decrypted-dlt_PPI_without-LTK.pcap
Found 1 connection

Analyzing connection 0:
  52:59:91:36:91:31 (random) -> f0:c7:7f:fc:da:8e (public)
  Found 12 encrypted packets
  Unable to crack due to the following error:
    Missing both Mrand and Srand

Did not decrypt any packets, not writing a new PCAP
Done, processed 0 total packets, decrypted 0

Then tried with LTK

rajib@rajib-lab-desk:~/bluetooth$ crackle -i captured.pcapng -o decrypted-dlt_PPI-LTK.pcap -l e77655c8523f02fc93c05e2fa279f1b8
Found 1 connection

Analyzing connection 0:
  52:59:91:36:91:31 (random) -> f0:c7:7f:fc:da:8e (public)
  Found 12 encrypted packets
  Decrypted 0 packets

Did not decrypt any packets, not writing a new PCAP
Done, processed 0 total packets, decrypted 0

Answer 1 · 2018-01-12T17:43:50.000Z

For the first case, you're missing the required packets to crack the encryption key: https://github.com/mikeryan/crackle/blob/master/FAQ.md#crackle-is-complaining-about-missing-packets-why-cant-i-crack In the second case, it appears that the LTK is not correct. Where did you get that LTK?

Answer 2 · 2018-01-12T18:05:06.000Z

I got the LTK from the android sniffer file. This LTK is for the same connection, do not think the LTK is wrong. In fact it has not even changed for a specific device even after unpair-repair. What should I do ?

Answer 3 · 2018-01-12T18:30:34.000Z

Can you share a screenshot of the log file that shows it?

Answer 4 · 2018-01-12T19:52:10.000Z

rajibeee commented 7 years ago

Answer 5 · 2018-01-12T20:27:19.000Z

Thanks, one last thing: can you also share the .pcap file that you're using with crackle?

Answer 6 · 2018-01-12T20:51:26.000Z

remove the .zip at the end of the file name

captured-using-c-Multiple-LL_ENC_REQ.pcap.zip
captured-using-r.pcapng.zip

"captured using" is used in the name to identify which ubertooth command I used to capture.
I used this command when using -c
ubertooth-btle -f -tF0:C7:7F:FC:DA:8E -c captured-using-c.pcap

with the captured-using-c file I am getting the following error

crackle -i captured-using-c.pcap -l e77655c8523f02fc93c05e2fa279f1b8 -o decrypted-from-c.pcap
Warning: found multiple LL_ENC_REQ, only using latest one
Found 1 connection

Analyzing connection 0:
  54:0f:3b:31:0d:28 (random) -> 47:e8:cd:9b:bd:d8 (random)
  Found 0 encrypted packets
  Decrypted 0 packets

Did not decrypt any packets, not writing a new PCAP
Done, processed 0 total packets, decrypted 0

Answer 7 · 2020-03-13T12:25:12.000Z

Hi @rajibeee, I know it's been a while but I think I've solved your issue, the LTK you provide is in the incorrect byte order for Crackle. Crackle takes it in Big-Endian, whist some sniffers will output the LTK in Little-Endian.

See my successful run with your input file:

And the output file (just remove the .zip from the end):
decrypted-from-c.pcap.zip

Answer 8 · 2021-11-04T17:09:14.000Z

@rajibeee can you told me the way which you got the LTK key number with cause I have the same problem

Answer 9 · 2021-11-05T02:55:05.000Z

@rajibeee can you told me the way which you got the LTK key number with cause I have the same problem

Used wireshark.

You have to use the LTK in the opposite order that you get from Wireshark to properly decrypt it.

Answer 10 · 2021-11-07T11:29:02.000Z

@rajibeee
but how with Wireshark the LTK is not shared on the air to get it from Wireshark.

Answer 11 · 2021-11-08T07:29:38.000Z

@rajibeee but how with Wireshark the LTK is not shared on the air to get it from Wireshark.

I do not know about the latest BLE version. As far as I remember I got this on 4.1 or 4.2. It was almost 4 years ago.