Here’s how to lawfully access critical evidence from Apple devices using Bluetooth connection data.

Bluetooth connections are often a factor in many investigations and can cover a wide range of case types from accident investigations to cases involving proximity to locations. Proving whether a driver was distracted before a fatal accident occurred is a common request.

Were they really connected to Bluetooth? How can you be sure? What about a “seen” Bluetooth device? Can you leverage that to put a suspect in an approximate location at a point in time? Yes, you can. But only if you really understand the data.

This blog is going to cover Bluetooth for iOS devices. This research does not include “spoofing” Bluetooth and involves real or detected Bluetooth devices that could have been paired to your smartphone.

For Android devices, read our blog, “How Android Bluetooth Connections Determine If The Hands of a Driver Are On The Wheel During An Accidents“. 

Matt and I have spent a good amount of time independently researching Bluetooth connectivity on iOS devices over the last few years. Oddly enough, our research stemmed from a question asked by an IACIS colleague of ours. (We did not work for Cellebrite at this time and didn’t even know one another, yet we each helped.)

This is another reason why sharing your research is important! Matt and I could have worked on this together in 2018, but we weren’t aware we were both researching the same thing, which is a common theme in DFIR.

In this scenario, the detective needed to know how to determine the correct time from an iOS plist. The timestamp was key to his investigation. Sounds simple, right? Not quite.

We assumed the timestamp would be in UTC – most database and plist timestamps are. That was not the case for this file, however. More details on this will be provided later in the blog. For now, let’s see where most Bluetooth investigations begin. For these examples, we used Josh Hickman’s checkm8 extraction1.

Files of interest (from the test device)

DarArchive/root/private/var/containers/Shared/SystemGroup/<GUID>/Library/Database/com.apple.MobileBluetooth.ledevices.other.db

DarArchive/root/private/var/containers/Shared/SystemGroup/<GUID>/Library/Database/com.apple.MobileBluetooth.ledevices.paired.db

DarArchive/root/private/var/containers/Shared/SystemGroup/<GUID>/Library/Preferences/com.apple.MobileBluetooth.devices.plist

Note: WAL files should also be parsed by your forensic tool.

What is stored in each file

com.apple.MobileBluetooth.ledevices.other.db: This database logs low energy devices the iOS device detected or came into range with. Low energy includes devices that stay in a “sleep mode” and wake up when connected. They operate on a different band from normal Bluetooth. These often include exercise devices (Fitbits, etc.), headphones, and more.

com.apple.MobileBluetooth.ledevices.paired.db: This database logs low energy devices the iOS device paired with.

com.apple.MobileBluetooth.devices.plist: This plist logs paired devices and last-detected times. This is one of the most important files that require attention for paring!

Diving into the data

Let’s look at the file system of the iOS device and the files of interest for Bluetooth artifacts. 

Physical Analyzer File System View from Josh’s iPhone

You will notice tools parse Bluetooth data from iOS devices and show connected devices. Make sure you do not confuse “detected” with “connected” as these are two vastly different things.

In Cellebrite Physical Analyzer, we put Bluetooth in one location and declare the connection type under the column labeled “Connectivity nature.” The Bluetooth results are in the Analyzed Data model under Devices & Networks > Device Connectivity > Bluetooth. Detected devices can be used for proximity to Bluetooth locations (think about investigations involving a suspect being at a specific location).

Physical Analyzer Parsed Bluetooth from Josh’s iPhone

Keep in mind that a device can be detected and then later paired to your iOS device. Above, you can see that Josh’s AirPods were “Paired” (Line 9) and the last time they were “Detected” was on 3/30/2020 (Line 8).

This is useful to the investigator because it indicates the disconnect time for the device (when pairing stopped). In short, Physical Analyzer will show two entries for a paired Bluetooth device—one that shows it was paired, and another that indicates the last time the paired device was detected.

Cellebrite Physical Analyzer Detected Bluetooth from Josh’s iPhone

Let’s take a closer look at the plist that logs paired devices. The com.apple.MobileBluetooth.devices.plist logs all Bluetooth device pairing – not just low energy devices. This is where vehicles come into play.

If you needed to prove a person was driving hands-free when a call or text was sent, this file would be a great place to start. However, the timestamp is tricky. Apple is notorious for storing timestamps in UTC, so why would this be any different, right? Well, it is different. An example from Josh Hickman’s iOS device is shown below (this way you can validate what we are showing you).

Cellebrite Physical Analyzer Hex View of com.apple.MobileBluetooth.devices.plist from Josh’s iPhone

Notice the date/timestamp? This timestamp for when connectivity started is stored in UTC with an adjustment to the user’s “base” time zone. This may not make sense when looking at Josh’s iOS data because he connected in his “base” time zone. This is the key thing that helped that detective we previously mentioned.

To further explain this, Heather tested some Bluetooth connections while in Paris in March of 2018 (her initial research). Even though her AirPods (Hank’s AirPods) were detected and paired in Paris, they did not reflect in the Europe/Paris time zone (UTC +1).

Below we can see the data parsed in Physical Analyzer, which is using UTC+0 as the time setting. The date displays March 16, 2018, at 06:22 UTC.

Cellebrite Physical Analyzer Bluetooth Parsing of Heather’s Test iPhone

The “LastSeenTime” value is stored in UTC but with the time zone adjusted for America/New York – Heather’s base time zone (UTC-4:00). If you weren’t aware of this specific way Apple is storing this data, your entire investigation could be thrown off!

Cellebrite Physical Analyzer File Format Viewer of com.apple.MobileBluetooth.devices.plist from Heather’s Test iPhone

DCode being used for validation from Heather’s Test iPhone

To further validate this, Matt did some testing on his phone as well. The results are confirmed – com.apple.MobileBluetooth.devices.plist stores the timestamp according to the phone’s own local time.

Cellebrite Physical Analyzer File Format Viewer of com.apple.MobileBluetooth.devices.plist from Matt’s iPhone

In the image above, you can see Matt’s Subaru Bluetooth connection. The LastSeenTime stored here translates to 2/20/2020 at 6:46 PM. Matt was at the car dealership on the evening of February 20th trading in his Subaru for a Jeep. The 6:46 PM timestamp is accurate for the last time (locally) Matt disconnected from the Subaru.

To reiterate: This value is stored according to local time, not UTC, and the value LastSeenTime will reflect the time of disconnection from the Bluetooth device.

Timestamp decoded using Sanderson’s Date Decoder v1.2.1

Matt also tested this with his laptop – where he could actively notate the connect and disconnect times. In a rare display of vulnerability, I (Matt) am sharing a snippet of my handwritten notes relating to this specific test. As you can see below, the times I recorded in my testing match the times stored in the plist.

Matt’s handwritten notes displaying the computer disconnect time of 10:28 AM on 3/24 match the time stored in the plist…

…The screenshot from the same plist highlighting the computer connection time…

…And that same time decoded via Sanderson’s Tool.

Can you imagine the confusion this was causing? Why does this file rely upon your “base” or home time zone even if you connect in another part of the world? We do not have an answer to this question, but it’s pretty cool when you uncover artifacts like this and share them with the community.

In summary, we know that it’s not always easy to put the pieces together during investigations. That is why it’s important to share the research you have completed. During our Podcast “Carved From Unallocated,” we discuss why test data is important.

Josh Hickman provided test data and documentation to support it. Download his images and use them to validate your tools. If you’re brave enough, proceed with data collection on your own iPhone and explore these files – they are available in a normal extraction (you don’t need a full-file system). At Cellebrite, our goal is to make your life easier and educate you along the way.

References:

[1] Josh’s checkm8 extraction:

https://drive.google.com/file/d/1GQP_y1340LHcq8eiDOYKAma62Q8GEyN5/view?usp=sharing

[2] Josh’s checkra1n extraction: https://thebinaryhick.blog/2020/04/16/ios-13-images-images-now-available/

Share this post