How to Use iOS Bluetooth Connections to Solve Crimes Faster
·
Synopsis
Forensics Question: We aim to educate those working iOS investigations on the primary files that are used to track Bluetooth connectivity and to provide a deeper understanding of the timestamp formats.
OS Version: iOS 11-13 were used for the testing and validation in this blog
Here’s how to unlock 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. Part II will cover Bluetooth for Android devices. This research does not include “spoofing” Bluetooth and involves real or detected Bluetooth devices that could have been paired to your smartphone.
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.
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 tracks 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 tracks low energy devices the iOS device paired with.
com.apple.MobileBluetooth.devices.plist: This plist tracks paired devices and last-detected times. This is one of the most important files that requires attention for pairing!
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 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.
Physical Analyzer Detected Bluetooth from Josh’s iPhone
Let’s take a closer look at the plist that tracks paired devices. The com.apple.MobileBluetooth.devices.plist tracks 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).
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, it 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 shows March 16, 2018 at 06:22 UTC.
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 tricky way Apple is storing this data, your entire investigation could be thrown off!
Physical Analyzer File Format Viewer of com.apple.MobileBluetooth.devices.plist from Heather’s Test iPhone
DCode being used for valication 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.
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 matches 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 it back to 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 it to validate your tools. If you’re brave enough, extract 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.
The purpose of the research was clear and the paper was easily readable. The authors utilized the Hickman datasets, which is helpful because the reference material is available to everyone. The documentation of the files of interest from the test device along with the description of what is stored in each file was helpful. One of the reviewers indicated that there is additional commentary which is not necessary.
Future Work
It could be helpful to track all known Bluetooth artifacts (e.g. KnowledgeC and other system traces) from the start to the finish of a connection so investigators know where else to look if one particular data source isn't consistent with expectations.
It is not immediately clear why certain paired devices (e.g. AirPods) only appear in other.db while others (e.g. Apple Watch) are listed in paired.db. One possible hypothesis is that if the device pairing is recorded in the com.apple.MobileBluetooth.devices.plist file, it will not be recorded in the paired.db file. Additional research on these files would be valuable.
It would be useful to understand how the files are affected if the user chooses to forget the Bluetooth device. Research into the values in the LastSeenTime and LastConnectedTime fields would also be valuable.
Additional research surrounding the time zone might also prove to be useful. For example, with the AirPods connecting in Paris, did the device automatically change to the time zone that it was in or did it remain in its "base" time zone? If the device automatically corrected to the Europe/Paris time zone (UTC +1:00) and it still recorded the time stamp as America/New York (UTC -4:00), was the behavior documented more than once?
Reviewers
Eric Eppley (Methodology Review)
Nickolas Ligman (Methodology Review)
Doug Metz (Methodology Review)
Linda Shou (Methodology Review and Verified Review using Author Provided Datasets)
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
