Skip to main content
SearchLoginLogin or Signup

How Android Bluetooth Connections Can Determine if a Driver had Their Hands on the Wheel During an Accident

Published onNov 05, 2020
How Android Bluetooth Connections Can Determine if a Driver had Their Hands on the Wheel During an Accident


Forensic question: How can Android Bluetooth artifacts be used in distracted driving cases?

OS: Android versions 6-10 were used in this research.

Tools: Magnet Acquire

Public Roots for access

Cellebrite UFED

Cellebrite Physical Analyzer


DB Browser for SQLite

Here’s how to unlock critical evidence from Android devices using Bluetooth connections to vehicles.

By Heather Mahalik, Senior Director of Digital Intelligence

Author’s note: I’d like to extend my special thanks to Josh Hickman for allowing me to use his public images, for taking my calls to validate my sanity during my research, and for peer-reviewing this blog.

When it comes to scanning and tracking paired Bluetooth devices, Android devices are completely different from iOS phones. Historically, more files were accessible that tracked connectivity in older Android versions. We used to be able to track connectivity to Bluetooth, NFC, USB, and more within /data/ This file is no longer present on the Android devices we tested. In addition, connections to a car via Bluetooth exist all over the Android device. If you are trying to determine if a user was driving hands-free, you have your work cut out for you.

This blog will focus on determining if Bluetooth devices were paired to an Android device. We’ll then look at how to determine actual connection times. For the examples in this blog, I used Josh Hickman’s public Android image1 so that you can validate my findings. This research includes validation from Josh’s image and the Android images from myself and my colleagues.

Diving Into The Data

The easiest way to approach Bluetooth on Android is to start with what is parsed inside of your tool. Below we can see what Physical Analyzer detected for Bluetooth and Bluetooth devices.

Physical Analyzer Parsed Bluetooth

The Bluetooth listing under “Device Connectivity” shows paired devices. This device is the Bluetooth connection to Josh Hickman’s Nissan Rogue. (Note: it is stored as “rouge” in the config file and in Josh’s car. He confirmed that for me as the typo is strange). Notice the lack of a timestamp? We will circle back to that shortly.

Physical Analyzer Parsed Bluetooth - Paired

The next connection for Bluetooth is listed as “Devices > Bluetooth Devices.” This includes “detected” devices. For this test image, the Nissan Rogue (Rouge) was detected.

Physical Analyzer Parsed Bluetooth - Detected

Sadly, this is where the easy part ends. If you just needed to prove pairing, consider yourself lucky. But what if you needed timestamps for this pairing? What if you needed to whether the user was in a hands-free state when something occurred?

Anytime a connection is made on an Android device (USB, Bluetooth, etc.) there are traces left all over the device. To start, we can manually to examine the bt_config.conf file to determine “Paired” and “Detected” devices. The file system view of parsed Bluetooth data is shown below. You can easily get to the location by clicking on the “Source file” in Physical Analyzer.

Physical Analyzer File System View

Some may open the configuration file and start poking around. We now need to make sense of this data.

Physical Analyzer Hex View of bt_config.conf

Upon closer examination, you may notice the timestamp at the top of the bt_config.conf file. This is not when the Bluetooth connection was established, but when the device was first set up for use. Make sure your tool is not parsing this as a connection timestamp.

Below, we can see that Josh started using his device on January 29, 2020. Don’t believe me? Read his documentation file for this extraction. The Bluetooth wasn’t first connected until the next day. Stay tuned for details on how to piece that together.

Physical Analyzer Hex View of bt_config.conf

Depending on the Bluetooth device, you may retrieve timestamps. This was not the case when I was examining Josh’s device because his paired Bluetooth connection was with a vehicle. Android Auto is a beast of its own, and timestamps and correlations are everywhere. Josh and I both conducted research on Android Auto a few years ago and we both continue learning as we dig though this data.

For this blog, I am going to provide you with a glimpse into how to put a person in a car, connected to Android Auto, when an activity occurs. To do this, we need to examine many files to establish connection start times, run times, and end times. From here, you can then correlate (timeline) the activity of interest.

There are many ways to approach this. One could simply search for “Bluetooth” across the parsed data or you can dive right in like I did. I copied the Mac address of Josh’s car and did a Hex search in Physical Analyzer.

To properly conduct a Hex search across the entire device extraction, you must first go to the File Systems model and select the “FileDump” by double clicking.

Next, select the magnifying glass and type in your keyword of interest. (Refer to Hex Diving Blog for more details on this type of keyword search).

Physical Analyzer Hex Search

This search produced 106 results. I recommend sorting by “Source” and examining the files of interest.

Physical Analyzer Search Results

You can now double-click on the source and it will take you to that file in the “File System View.” Determining usage is the hard part, but we now have some files to lead us down that trail. Also note, I include all of these files for reference at the end of this blog.

Databases of interest can be examined using the SQLite Wizard inside PA where you can leverage the query builder to check columns of interest, decode timestamps, rename columns, and add it as a parser into Physical Analyzer.

SQLite Wizard in Physical Analyzer

Or, you can export the database out of Physical Analyzer and parse in your preferred tool. This query may help you determine relevance of this file to your investigation. The results will show that the “modllyear” is 18 MY, but his vehicle is actually a 2019. It appears that Nissan may associate all years to specific model parts (Nissa_Bosch_SUV). I am not a vehicle expert but wanted to mention it as the query provide this output.





datetime(connectiontime/1000,'unixepoch','localtime') AS "connection time",




when bluetoothConnectionAllowed = 1 then "Bluetooth Allowed"

else "Bluetooth Not Allowed"

end AS "Permissions"

from allowedcars

DB Browser for SQLite showing my query results

At this point, we see a connection time of February 2, 2020 at 14:09 (localtime). This is where having test data is extremely helpful and we discuss testing like this in our Cellebrite podcast “Carved From Unallocated”. Josh provides documentation with his public images so that you can validate the data! I looked at what my query provided and found that he last connected his Android device to his car on this exact date and time.

A snippet from Josh’s public documentation (Bluetooth Activity)

We are now getting somewhere. Now we know the last time Josh connected his Android device via Bluetooth to his car. Let’s keep digging! Another file that caught my eye was coffee_preferences.xml. This file helped determine when the device was first paired via Bluetooth using Android Auto. The decoded timestamp below (yes, there are others, but this is the one that matters) shows the timestamp of January 30, 2020 at 08:56 AM (localtime).

Physical Analyzer File Format Viewer and DCode for Validation

When we look at Josh’s testing documentation, we can see we have established our primary date of interest correctly!

A snippet from Josh’s public documentation (Bluetooth Activity)

What we have done so far is not an easy task, which is why I hope this blog helps you along your way. I am 100% positive that different devices will store the data in different files. However, you now have methods to guide you along the way.

Please refer to the presentation that Sarah Edwards and I provided at the DFIR Summit in 20192 as it provides a look at the Samsung side of Android Auto and Apple CarPlay as well. You will see that this research provided even more information than my presentation at the DFIR Summit showed as the device was made by a different manufacturer and the Android OS was older. This is the perfect example of why we all must continue researching, learning, and sharing our findings!

The following files were tested for Android Auto connections only (you may find more if you search like I did in this blog):



/data/data/ - tracks last runtime for Bluetooth

/data/data/ - tracks first run time and monitoring start time.

/data/data/ - Can be used to verify mac address for connected automobile.

/data/data/ - Can be used to verify mac address for connected automobile.

/data/user_de/0/ - contains paired mac address.

/data/user_de/0/ - contains paired mac address and can be associated to the peoplelog.db which updates contacts to the vehicle when the device is connected via Bluetooth or USB.

/data/data/ - Lists the allowed cars for the device.

/data/data/ - Associations Google account to the vehicle mac address

/data/user_de/0/ - The metadata table shows paired Bluetooth mac addresses.


[1] Josh Hickman’s public Android image:

[2] DFIR Summit Presentation:

DFIR Review

The paper/blog structure and its story telling method makes it easy to read and understand. This research could be very helpful to construct timeline analysis for Bluetooth connections made between devices and is a good addition to the digital forensic community. The images/figures, table, the list of the artifact paths on the device are presented clearly. Reviewers were able to verify the results using open source tools including HexEditor, SQLite DB Browser, Autopsy, and Notepad++.

We must consider the possibility that Bluetooth was turned off on the Android device. This means that a user could be in a vehicle, but there might not have been a connection. The table being looked at in SQLite Wizard was not indicated. One of the reviewers was able to identify the database as Pixel 3\data\data\\databases\carservicedata.db.

Future Work

A tool or plugin to extract these artifacts and construct the timeline analysis could be a big help. Future work could also include research on the additional timestamps available in coffee_preferences.xml as well as testing to see if multiple entries for different vehicles would exist in carservicedata.db. It would also be helpful to determine how long records last before they are overwritten by new records.


  • Addisu Afework Birhanu (Methodology Review, Verified Review using Author Provided Datasets)

  • Yohannes Yemane Brhan (Methodology Review, Verified Review using Author Provided Datasets)

  • Jessica Hyde (Methodology Review, Verified Review using Author Provided Datasets)

No comments here
Why not start the discussion?