mikeryan/crackle

Support BLUETOOTH_HCI_H4_WITH_PHDR

Closed this issue · 4 comments

LegNeato commented

Consider this a feature request to support BLUETOOTH_HCI_H4_WITH_PHDR.

Currently:

$crackle -i foo.pcap
PCAP contains [BLUETOOTH_HCI_H4_WITH_PHDR] frames
Frames inside PCAP file not supported ! dlt_name=BLUETOOTH_HCI_H4_WITH_PHDR
Frames format supported:
 [256] BLUETOOTH_LE_LL_WITH_PHDR
 [192] PPI
$

The value it is getting for cap_dlt is 201.

LegNeato commented

Also happy to take a swing at it if you can point me to some docs to get me started. Though my C is pretty rusty 😄

mikeryan commented

What tool generates this? If this is captured between the Bluetooth host (stack) and controller (USB/chip), then there is no encrypted data. You may capture the key exchange and be able to crack that, but the derived LTK should also be directly logged as part of the capture.

I guess what I'm getting at is: what's your use case for this capture format?

mikeryan commented

I'm going to close this one since my best guess is that you're using a tool like btmon, hcidump, or Android's HCI packet logging, all of which should include the unencrypted LTK directly in the output. If this is not the case, please reopen this issue.

Arinerron commented

@mikeryan I know this issue is a bit old, but given the LTK, shouldn't the tool be able to support decryption?

$ crackle -i ./output.pcap -o decrypted.pcap -v -l <LTK>                        
PCAP contains [BLUETOOTH_LINUX_MONITOR] frames
Frames inside PCAP file not supported ! dlt_name=BLUETOOTH_LINUX_MONITOR
Frames format supported:
 [256] BLUETOOTH_LE_LL_WITH_PHDR
 [192] PPI

I can open a new issue if you'd like.

  • 👍2