Introduction
In the final phase of this project, we have achieved a mostly functional Bluetooth tracking ecosystem. Our team worked through a lot of issues during testing in the past month. We dealt with inconsistencies that hindered data collection. We also had issues with implementing the elasticsearch python library. We’ve spent time troubleshooting these problems, and think we’ve reached the best conclusion. There are still certain constraints inherent in the system. However, our current framework fits the original objectives of the project.
Local Testing Setup
In order to test our tracking nodes on real devices moving past them, we needed a way to remotely observe each node. This would allow us to check the status of the node if we had concern in the collection process. We also needed to solve the issue of how to remotely connect to nodes we didn’t already know the IP address of.
We ended up connecting the Raspberry Pis to the LCDI wireless network using dedicated USB adapters. The adapters proved easier to configure than the built-in wireless cards on the Pis. We decided the best solution to the connection issue was to install the free command-line teamviewer client. This would allow us to access the nodes no matter what network they were on. As long as they had external internet, we’d be able to manage them remotely from the teamviewer web client. We could use this connection to remote in to the nose and kick off the scanning script. We had a deployment procedure. First, connect the Pi to a power source in the desired location. Next, wait for the Pi to come live on the Teamviewer web console. Finally, use the console to log in to the Pi and execute the script.
Bluetooth Testing Challenges
After running the scripts on each node and monitoring the data sent to our server, we got mixed results. We used a Moto G phone for testing. Our nodes could not detect the device, even when it was placed in discoverable mode. On the other hand, other student devices that were present around the lab were detected easily. This was a disappointing result. It is more at the fault of the Ubertooth and Blue Hydra programs themselves. They couldn’t see certain devices. We hope that with upgrades to the Blue Hydra and Ubertooth, the technology will cover more devices. Until then, it is almost certain that some devices are slipping through the net. It also presents an issue when examining data. We can’t be sure a device seen by one node but missing on another was actually ever there.
We also faced an issue with the original implementation of the elasticsearch python library for shipping log results from the nodes to the central server. This was solved with a series of tweaks to the script that are reflected in the final report.
Conclusion
This project was able to produce a complete ecosystem for collecting and viewing Bluetooth devices. Keep an eye out for our final report for a more in depth breakdown of our process and tutorials on how to build your own.
Post any feedback, questions, or general comments in the comment section below! Interested in our research? Follow the Leahy Center for Digital Investigation (LCDI) on Twitter @ChampForensics, Instagram @ChampForensics and Facebook @ChamplainLCDI.