greatscottgadgets / ubertooth

Software, firmware, and hardware designs for Ubertooth
https://greatscottgadgets.com/ubertoothone/
GNU General Public License v2.0
1.92k stars 430 forks source link

Implementing CRC Check #328

Closed CarlyAmar closed 6 years ago

CarlyAmar commented 6 years ago

I'm working on a modification of the ubertooth-btle software for my application. One issue is that we are observing malformed packets, and would like a way to filter them out. CRC check does not happen on the board with the below parameters, and I was hoping to either find a way to either:

Either one of these implementations would work, however sending an ubertooth cmd to perform the check is obviously preferred.

For calculating CRC on host side, I am using the data field of usb_rx_packet and parsing it myself. All fields are being successfully parsed, but I seem to not be able to calculate the CRC correctly.

Steps to reproduce

  1. sudo ubertooth-btle -Uubertooth0 -v1 -f -q /tmp/ubertooth
  2. Open wireshark on the pipe
  3. Observe malformed packets.

Expected behaviour

Ability to filter out malformed packets.

Actual behaviour

Malformed packets are not able to be filtered out by providing the -v1 flag.

Version information

Operating system: Ubuntu 16.04 Ubertooth tools version (ubertooth-rx -V): libubertooth 1.0 (git-f8aa736*)

libbtbb version: libbtbb 1.0 (git-ee1bbd5)

Ubertooth firmware version (ubertooth-util -v): Firmware version: 2017-03-R2 (API:1.02)

If you are reporting a problem that involves third party software (Wireshark/Kismet/etc), please report the version here.

Output

Insert any commandline or build output here
mikeryan commented 6 years ago

This is a regression in the latest firmware release. I plan to reimplement support for firmware-side CRC checking.

If you want to implement it host-side, keep in mind that each connection will have a unique CRCInit. You will need to parse that out of the CONNECT_REQ packet and use it when performing CRC validation of packets from connections.

CarlyAmar commented 6 years ago

Thanks for the quick reply.

I forgot to mention that we are setting the target to 00:00:00:00:00:00 with -t in a separate command, so we are only looking at the advertising channel. Given that, there should be a constant CRC init of 0x555555 if I understand correctly.

Also, I am not running the latest firmware due to other issues. If the expected behavior is that no malformed packets should be observed with wireshark, then the regression must come from an earlier commit.

specifically should this command filter out malformed packets? cmd_set_crc_verify(ut->devh, 1);

mikeryan commented 6 years ago

Ah yes, the older firmware explicitly does not do CRC validation on advertising packets. If you comment out the following line, that should allow you to use the USB command for CRC validation:

https://github.com/greatscottgadgets/ubertooth/blob/2017-03-R2/firmware/bluetooth_rxtx/bluetooth_rxtx.c#L1969

And yes, you are correct about the fixed CRCInit.

FWIW the new firmware has a built-in feature to not follow connections and only dump advertising packets. Once the CRC validation is implemented in there, I definitely recommend upgrading.

CarlyAmar commented 6 years ago

Thanks for the help. That one line wasn't enough so I just added it to a bunch of places. Here is a patch for anyone else with this issue

ubertooth-firmware-crc.txt