search

Matheus-Garbelini / sweyntooth_bluetooth_low_energy_attacks

Proof of Concept of Sweyntooth Bluetooth Low Energy (BLE) vulnerabilities.
267 stars 69 forks source link

nRF52840 dongle is not detecting cubiTag to execute public key crash #6

Closed Priyasachi closed 4 years ago

Priyasachi commented 4 years ago

I have created necessary environment on windows 10 to crash the cubiTag device by using the nRF52840 dongle, unfortunately i always received the following output.

Screenshot (9)

can you please suggest something by looking out the screenshot.

Matheus-Garbelini commented 4 years ago

Hi @Priyasachi, did you flash the nRF52840 driver firmware before executing the exploit script? By looking the image, it doesn't seem the nRF52840 is running the driver firmware. The command to install the firmware on the dongle is the following:

python -m pip install nrfutil pyserial pycryptodome
nrfutil dfu usb-serial -p COM4 -pkg nRF52_driver_firmware.zip
Priyasachi commented 4 years ago

Hi, Yes i did flash the nRF52840 driver firmware before executing the exploit script and both run successfully. (My serial port changed) 

              python -m pip install nrfutil pyserial pycryptodome
              nrfutil dfu usb-serial -p COM7 -pkg nRF52_driver_firmware.zip

Screenshot (45)

Matheus-Garbelini commented 4 years ago

@Priyasachi does this happen only with the public key script, or if you run the other scripts it can find CubiTag? Also make sure the CubiTag is disconnected from any smartphone/app. SweynTooth scripts can't find CubiTag if a connection has already been established between it and any other device. For example, if you can locate CubiTag address on the nRF connect app, without clicking on the connect button, the public key script should also be able to find it.

I'll try to replicate this problem here, but let me know if you have verified the CubiTag address is correct and that you are not connected to it while executing the script.

Regards

Priyasachi commented 4 years ago

Thank you very much for your comments.

  1. Yes for other scripts also similar output was observed.
  2. After firmware is flashed the red light stop blinking (does it mean dongle is no more in DFU mode?) and we are again pressing reset button to make it on DFU mode.
  3. Also CubiTag address is correct and it was not connected to any other device and then we are executing script.

Screenshot (48)

Matheus-Garbelini commented 4 years ago

Hi @Priyasachi after flashing the red led stops working, but a green led starts blinking. By looking at your output, the firmware was flashed, but the COM port may have changed after the nRF switched from DFU mode to normal operation (COM7 windows error).

Please, check if the script works by using the COM port under normal operation of the nRF52 dongle and let me know.

Priyasachi commented 4 years ago

Yes, We already checked that cubiTag can be connected to nRF52840 dongle. We would be wondering if you can give us the hints on final step of crashing cubiTag

Screenshot (57)

Priyasachi commented 4 years ago

We are getting the expected output. Thank you.

Matheus-Garbelini commented 4 years ago

Hi @Priyasachi I noticed you were not getting a yellow message showing that a malformed packet was sent on the terminal. Could you share what you did to get the expected output so we can try to improve the scripts?

Thanks.

Priyasachi commented 4 years ago

Hi @Matheus-Garbelini after reconnecting nRF52840 dongle we are not running the script to flash the firmware again that might be the reason for not getting the yellow message (malfunction packet was sent on the terminal). also we believe that the environment (many active Bluetooth/WiFi) also affects the final output. Thank you Screenshot (44)

Matheus-Garbelini commented 4 years ago

@Priyasachi thanks a lot, I'll investigate what you reported about the environment. Regards.