Getting "Segmentation fault" while scanning device

[Patidar1307]

Hi Team,

I would like to check the BrakTooth vulnerability in my metering product before launching to market. I have followed the provided steps in Ubuntu 18.04 VM machine and ESP32 Wrover kit.

While scanning for devices using the following command, getting segmentation fault in ESP32 and also taking too much time to open port /dev/ttyUSB1:

$ sudo bin/bt_exploiter --scan

Output is attached here for reference.

I have tried multiple options like updated configs file (/bt_config.json ), erased ESP32 flash and programmed again, flashed using idf.py (default ESP32 flashing script), validated "Hello world" example code and much more.

Can you please share your inputs on priority to resolve this issue.

Please let me know if any further information is required Thanks and regards, Patidar

[Matheus-Garbelini]

Hi @Patidar1307 thanks for reaching out. Note that the PoC reports the following concerning result: Measuring UART Latency.... USB Latency:2348 us

• 1. The PoC unfurtunatelly does not tell you this, but your latency is extremely high. Usually a good value is in range 200us-400us maximum. Few things could be causing the issue. Check on your VM if USB is configured to USB 3.0 (latest version you can possibly select there). Also make sure to use VMWare instead of VirtualBox. We got some issues with USB latency when using VirtualBox, so we always recommend vmware player instead.
• 2. The taking too much time to respond can be solved by disabling "SerialAutoDiscovery":false in configs/bt_config.json and setting "SerialPort": "/dev/ttyUSB1". This will make PoC connect to /dev/ttyUSB1 right away.
• 3. As for the segmentation fault, the PoC has a useful feature that whenever it gets a segmentation fault, it saves a coredump file so we can analyse such error later. To help us you can run the following and submit the output stack trace: sudo gdb bin/bt_exploiter core. It should show us what line of the source code the segfault was triggered.

PS: Also, what esp32 board are you using? Is it the ESP-WROVER-KIT?

Anything else please let us know.

[Patidar1307]

Hi Matheus-Garbelini,

Please find the response for your suggested points: 1. USB latency:

• In the shared logs, latency seems 2348 us but I had also observed 125 us in multiple tries.
• I have enabled USB3.0 in the VM workstation.

2. The taking too much time to respond can be solved by disabling "SerialAutoDiscovery":false::

• Ok, I will check and share the observations

3. segmentation fault:

• I will check and share the results

Further information: 4. Platform:

• Yes, using ESP32 Wrover kit (https://www.amazon.in/Espressif-ESP-WROVER-KIT-VB-Wi-Fi-Development-Board/dp/B07SZH25H7)

5. Firmware Version:

• in your post, I have observed that ESP32 reports firmware version 1.4.0 whereas in my log I found 1.3.0.
• Please let me know if version difference can create an issue.

Thanks and regards, Patidar

[Matheus-Garbelini]

@Patidar1307 the firmware version should be ok. The difference in version is just some internal changes of baudrate between this repo and the sniffer repo.

[Patidar1307]

Hi Matheus-Garbelini,

An ESP32 is responding after disabling "SerialAutoDiscovery":false in configs/bt_config.json file. We can scan and target our device. Thank you for the inputs.

Further, we have validated our device but we have not observed any remarkable activity after targeting it using following command: sudo bin/bt_exploiter --host-port=/dev/ttyUSB1 --target=<target bdaddress> --exploit=<exploit name>

Attached herewith the test logs (from /braktooth/braktooth_esp32_bluetooth_classic_attacks/wdexploiter/logs/ directory) for the reference: Bluetooth.zip

Can you please do some favor and confirm our observation by reviewing attached logs? Thanks again for the continuous support.

Best regards, Patidar

[Matheus-Garbelini]

Hi @Patidar1307 by looking the logs, everything seems normal. Note that the logs folder only contain the last execution you've made. So I can only see the logs for au_rand_flooding.

[Patidar1307]

Hi Matheus-Garbelini,

Thank you for the quick response and log review. Yes, the attached log was for "au_rand_flooding" exploit only.

We have quick questions on your previous response: To verify the BrakTooth vulnerability, do we need to test all available exploits, or only "au_rand_flooding" exploit test is sufficient?

Thanks and regards, Patidar

[Matheus-Garbelini]

@Patidar1307 if you are testing Texas Instruments CC2564C, au_rand_flooding should be sufficient. But if it's not the exact chipset we have tested before, it is worth to test all the exploits.

[Patidar1307]

Hi Matheus-Garbelini,

Thank you for the quick response and log review. We have tested the device with all the exploits and the device is remain connected and responding to ping requests to another device.

It will be great if you quick look the following logs, and check if any discipline is available.

braktooth_test_logs.zip

Thanks again for the quick response and your time. We can close this topic after your comments on the attached log review.

best regards, Patidar Technologist

[Patidar1307]

Hi Matheus-Garbelini,

Have you got a chance to walk through the logs? Please quick look at the logs, and check if any discipline is available.

We can close this topic after your comments on the attached log review.

best regards, Patidar Technologist