Turbo Speed: Parsing Device Health Services from Google
·
Synopsis
Forensics Question: What sort of information can be parsed from the turbo.db database?
How does Device Health Services track application usage?
How does Device Health Services track battery levels and usage of Bluetooth devices?
OS Version: Android v9-11
Tools: DB Browser for SQLite v3.12.2
ALEAPP v1.9.7
Notepad++ v8.1.2
Introduction
Device Health Services is an application from Google that can monitor how heavy your phone is using the battery. From the description on the Google Play Store it “predicts how long your phone’s battery will last based on your usage”:
While I don’t always find the application to be fully accurate in terms of battery usage left, especially after your battery has degraded over time, it does give us some great artifacts from a forensics perspective.
Application Usage
Inside the shared preferences folder for the “Turbo” application we get an XML file for application usage. The file can be found at the following path:
Opening the file, we can see some application names listed alongside a bunch of Unix Epoch timestamps.
Figure 1: Sampling of data in the "app_usage_stats.xml"
Since the sample data is pulled directly from Josh Hickman's Android 11 image, we can check to see what events occurred with each application at those specific times. Doing a quick conversion in CyberChef, it shows the following:
1601765910317 > 10/3/2020 22:58:30.317 UTC
1601765939116 > 10/3/2020 22:58:59.116 UTC
These line up pretty much exactly to what Josh documented for when he used the Telegram application on the same day (minus 4 hours for local timezone offset):
Figure 2: Telegram app usage from Josh Hickman's image creation
Let's look at another application to see what we can correlate. Here is what Google Maps shows in the "app_usage_stats.xml" file
1601764099335 > 10/3/2020 22:28:19.335 UTC
1601768689375 > 10/3/2020 23:44:49.375 UTC
1601768794738 > 10/3/2020 23:46:34.738 UTC
And here are the matching actions taken from Josh's documentation:
Figure 3: Google Maps app usage from Josh Hickman's image creation
They are basically an exact match, give or take a few seconds difference. It would appear that Device Health Services is tracking all application usage for a certain period of time. Knowing a little more about the application, it gives estimates on how long your phone battery will last while it's being used, so it makes sense why application usage plays a big part.
Figure 4: Sample image of Device Health Services Battery usage
At the bottom of the XML file we also get start and end times in Unix Epoch signifying that we are only getting application usage for a certain period of time.
Figure 5: XML start and end times
Converting these are as follows:
Start Time: 9/25/2020 19:41:54.750 UTC
End Time: 10/5/2020 19:42:10.301 UTC
These dates align with the first and last application dates parsed from the XML file as well. You can parse these application usage names and timestamps using the latest build of ALEAPP.
Figure 6: ALEAPP output of Device Health Services application usage
Of note, I have seen this application usage populated mostly on Google Pixel phones, and some newer Samsung phones. My assumption is that more Android phone makers may start to include this in their iterations.
Phone Battery Levels
The main database for Device Health Services lives at the following path:
It's a simple SQLite database which makes parsing fairly easy using DB Browser to start. Opening the database there was only one table of interest:
battery_event
The database table is simple for the most part. It has 6 columns, 5 of which have useful information.
Figure 7: battery_event table fields in turbo.db
The timestamp is in Unix Epoch millisecond format. Battery level tracks what percentage the battery of the phone was currently at during that time period. From sample data that I had, the Charge Type was four different options:
0 = not charging
1 = charging rapidly
2 = charging slowly
3 = charging wirelessly
Battery saver was a switch that showed whether the battery saver option was turned on or off:
1 = turned ON
2 = turned OFF
Timezone is the offset of where the phone was set to at that current date/time of the battery event.
Figure 8: Sample data in the battery_event table
Timezone could be useful in correlating with other artifacts on the phone to determine a user's location during a certain time period. These phone battery events are now parsed in ALEAPP.
Figure 9: ALEAPP output of Device Health Services phone battery usage
I have only seen the turbo.db database file populated on Google Pixel devices, but was found across Android versions 9-11 so far.
Bluetooth Devices & Battery Levels
We will be taking a look at some Bluetooth items found in the file at the following path:
Similar to the turbo.db, we don't have too many tables to sift through for evidence but some useful stuff nonetheless can be parsed from the "battery_event" and "device_address" tables.
Figure 10: bluetooth.db table structure in DB Browser for SQLite
Breaking down the "battery_event" table we get the following fields:
timestamp_millis
timestamp in milliseconds since Unix Epoch
device_idx
device index number, more on this later
battery_id
TBD, was empty for all my test evidence
battery_level
battery level percentage of the connected Bluetooth device at that specific time
time_zone
the timezone of the phone when the event occurred
volume_level
volume level percentage of the Bluetooth device at that specific time
Now onto "device_address" table:
device_idx
device index number, each unique Bluetooth device gets one, incrementally from what I can tell, ties back to the field of the same name from the "battery_event" table
bd_addr
the MAC address of the connected bluetooth device
untethered_device -
TBD, my assumption is 0 is no and 1 is yes, but haven't gotten any devices to be listed as untethered
device_identifier
universally unique device ID, 32 hex characters in length
Combining both tables we can get a better picture of when a Bluetooth device was connected to the phone and some level of usage with the battery status of the Bluetooth device and volume levels. Be aware that not all Bluetooth devices allow for tracking battery level. From my testing it seems to have been implemented in devices that support BT v4.2 and above.
Figure 11: ALEAPP output for Device Health Services bluetooth history
We can see from the sample ALEAPP report I created, we see some battery levels of -1. I'm still looking into this but my thought is it may be related to a disconnection event. Another thing I had noticed is event entries are only created when the Bluetooth device battery level changes (in increments of 10 at that).
As with the turbo.db database from the section above, I have only been able to test finding this Bluetooth history on Google Pixel devices.
Future Work (written by the author)
As I could only test on Google Pixel phones and one Samsung image I want to expand this to other manufacturers if I can get test images or devices. I also want to test more Bluetooth connections to see if different types of devices change the results, such as connecting to another phone vs. headphones vs. a car navigation system.
If you have any questions I can be reached via twitter @KevinPagano3 or emailed at stark4n6[at]gmail[dot]com.
DFIR Review
Device Health Services provides the forensic community with an additional artifact for tracking application usage, battery usage, and Bluetooth usage. One of the reviewers suggested putting a reference on the information for the charging types could help the readers explore more. They also indicated that they had trouble identifying which dataset was analyzed for some results in mitigation; they suggested finding a way to differentiate the source datasets throughout the article. This could be accomplished by using figure numbers for all associated screenshots and referring to the associated figure number throughout the text.
Future Work (provided by DFIR Review)
Reviewers are interested in knowing how to determine which device the Bluetooth Device ID/MAC Address is associated with, why it is important to know which apps use the most battery life, and why it is important to parse through the battery levels.
Future work on this topic could also include additional information on the make, model, and OS versions as well as analyzing different phone models manufactured by different vendors.
Reviewers
Addisu Afework Birhanu (Methodology Review, Verified Review Using Author Provided Data Sets)
Alexander Brunner (Methodology Review, Verified Review Using Author Provided Data Sets)
Rishi Krishnan (Methodology Review, Validated Review Using Reviewer Generated Datasets, Verified Review Using Author Provided Data Sets)
Selena Ley (Methodology Review, Validated Review using Reviewer Generated Datasets)
Creative Commons Attribution 4.0 International License (CC-BY 4.0)
