As you probably know we perform research on a regular base at ERNW.
We – Olga and Rafael – started with a research project about Bluetooth. Our first goal was to gain some knowledge about the tools used by most Linux systems to communicate with Bluetooth hardware, such as BlueZ. A good help for that was the amazing Bluetooth hacking workshop we had before (check the link in our blog!)
To get a better understanding of the tools you need some Bluetooth hardware to interact with.
The hardware we used for our research so far are the very cool TexasInstruments SimpleLinkâ„¢ Bluetooth low energy/Multi-standard SensorTag (CC2650STK) and a Fitness Wristband found at home.
Both devices are using Bluetooth (or, in our case Bluetooth Low Energy) for communication. The SensorTag sends its sensors’ information to a client and the wristband synchronizes its data via Bluetooth LE.
After some playing around with the devices we decided to take a look at the apps both devices use to get information. And what helped us a lot with this, is a very handy feature of the Android system. Since Android 4.4, it is possible to capture all Bluetooth HCI packets and save them to a logfile. This logfile can be copied to your laptop (we used adb for that purpose) and opened in Wireshark for further analysis.
This feature can be enabled in your Android device by going to Settings-> Developer Options (which will only show up if your device is in developer mode). Then search for “Bluetooth HCI Snoop Log” and enable it. Now the device will start to dump all Bluetooth communications to a file usually called “btsnoop_hci.log”. Normally this can be found in “/sdcard/btsnoop_hci.log”. In our case we found it in “/sdcard/Android/data/btsnoop_hci.log”
Once copied from the Android device the file can be opened with Wireshark.
Then you can filter for the Bluetooth address of the device to see the correct conversation. This can be achieved with the following fitler “bluetooth.addr == 11:22:33:44:55:66”.
Now we know how some of the packets look like. We started to identify which purpose the different packet have and if we can see what is changing over time or after certain circumstances. The final goal is to rebuild a packet or even better a packet chain for a specific purpose and sending it as a replay to the device or the App.
This is where we stop for the moment and we will continue on that next time 😉
Cheers,
Rafael & Olga
Hi, this is really good, interesting stuff that’s clearly written. This would be good for showing to teens on what’s in the air around them. Would you consider working with us to use this for a Hacker Highschool lesson? http://www.hackerhighschool.org – we are making a wireless lesson where this kind of research would be great to show and the step-by-step is something they can do in the classroom too.
Sincerely,
-pete.
Hi Pete, we are discussing this internally and we’ll get back to you soon.