Tools for reversing a bluetooth protocol?

[mikeselectricstuff]

I have a big Bluetti powerbank, which I want to set up for solar EV charging -  the idea is it continuously charges from whatever solar is available, and when the SoC exceeds a particular level, it  turns on its AC output to dump the battery into the car via a normal granny-charger, and turns off below a specified level ( it will probably do the latter by itself anyway).

There is an Android App that allows access to all the info I need - SoC readback and AC on/off control.

I know very little about Bluetooth - can anyone recommend  any nice man-in-the-middle type tools for reversing a Bluetooth connection like this ?

The Bluetti does Bluetooth via a small sub-board with an ESP32, so sniffing the serial link to this would probably be a good first step - I suppose it could even be that the ESP32 provides a transparent COM port link, which should make things pretty easy.

Phase 2 would be to make a simple widget, maybe ESP32 based, to talk to the Bluetti and do this switching as a standalone unit, possibly as a product, hence  wanting to do this without modifying the powerbank.

 

[coppice]

Is it using classic BT or BTLE? In either case a lot of simple applications, where they have tacked on BT, use a COM port over the BT channel, but how you sniff is different. If you already have access to a UART port I'd start there, and get a hang of the protocol. Then have a look at the BT side. For BTLE I can recommend the Nordic dongles and the software Nordic supply for them. I'm not sure what a good tools for classic BT is these days.

[ataradov]

I don't know if it will work in your case, but for a BLE sniffer I use this dongle from Nordic https://www.nordicsemi.com/Products/Development-hardware/nRF52840-Dongle

They have software that adapts it to Wireshark and it does all the decoding. It is cheap, works very well and easy to setup.

Also, ST has a generic Andorid app called ST BLE Toolbox. It just lets you connect to any BLE device and discover/read/write any characteristics. You may be able to figure it out just by using that app.

There is an app like this from all BLE IC vendors, but ST's is the best, at least from the ones I tried.

[zapta]

+1 for wireshark and the nordic dongle. You can capture the packets with decoding at various stack levels.

Try also the Nordic nRF connect app for phones. It allows you to see the structure of the BLE endpoints that the device provides.

[mikeselectricstuff]

I don't know if it will work in your case, but for a BLE sniffer I use this dongle from Nordic https://www.nordicsemi.com/Products/Development-hardware/nRF52840-Dongle

They have software that adapts it to Wireshark and it does all the decoding. It is cheap, works very well and easy to setup.

Also, ST has a generic Andorid app called ST BLE Toolbox. It just lets you connect to any BLE device and discover/read/write any characteristics. You may be able to figure it out just by using that app.

There is an app like this from all BLE IC vendors, but ST's is the best, at least from the ones I tried.

AFIAK this probably uses classic Bluetooth (based on there not being any need for it to be BLE) - is this dongle any use for that? - AIUI the BT over-the-air traffic is encrypted.

[RoGeorge]

Once I've tried to reverse engineer a BTLE bracelet.  Found this talk interesting, has both a video and a pdf with the slideshow used during the presentation:

Bluetooth: With Low Energy Comes Low Security
Authors: Mike Ryan, iSEC Partners
https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan

As for tools, "nRF Connect" apk for Android might tell a lot about the radio link and the data packets.  Also, Nordic Semiconductor have some app notes (or it was in the user guide? don't recal) about their nRF IDE/toolchain and how to use that to debug a radio link.

[coppice]

AFIAK this probably uses classic Bluetooth (based on there not being any need for it to be BLE) - is this dongle any use for that? - AIUI the BT over-the-air traffic is encrypted.

It really depends on the age of the design. There are so many cheap BTLE solutions now, which can't do classic BT, that everything recent is BTLE unless speed demands classic BT.

[mikeselectricstuff]

Actually you may be right here - the device does not appear in Android's list of BT devices - connection happens inside the app, so I'm guessing that would indicate BLE ?

[nali]

Just download nRF Connect and do a scan, it'll probably show up, and it'll show you what BLE services it's advertising.

[ataradov]

Actually you may be right here - the device does not appear in Android's list of BT devices - connection happens inside the app, so I'm guessing that would indicate BLE ?

I think both versions should appear in the list. But in Android there is a setting to hide device with no name in the advertisement. Sometimes IoT type devices use that to hide themselves from the list.

Download ST BLE Toolbox or nrF connect, they will show you all the information that is possible to get from the OS. I personally prefer the ST one, but ultimately they do the same thing.

[coppice]

Actually you may be right here - the device does not appear in Android's list of BT devices - connection happens inside the app, so I'm guessing that would indicate BLE ?

I think both versions should appear in the list. But in Android there is a setting to hide device with no name in the advertisement. Sometimes IoT type devices use that to hide themselves from the list.

I don't think they are trying to hide anything. A lot of devices have just taken a serial port on their device, and attached a generic BTLE module that will pass that serial data through. They have done the minimum beyond that. So, they end up with a BTLE end point that looks exactly like the end point in a hundred other products using the same module. They only expect the device to have to communicate with their own app on a phone or tablet. If it does that, they are are good to go.

[Jon_S]

There is an Android App that allows access to all the info I need - SoC readback and AC on/off control.

As another option, you could attack it via that Android App using a tool like JADX. I did this with a BLE device but I can't see any major difference if it happens to be Bluetooth Classic.

I reversed the .APK and documented how the comms parts of it worked. Next I made a simple app with just the comms part re-implemented and debugged that until it worked properly.

This was possibly quicker than attacking it via the air as there was some basic protection on some of the data (XOR), and that was trivial to understand in the reversed code.