SANS Institute turbo speed parsing device health services from google PDF

Preview

Summary

this is a paper whichh will help tudents...

Description

Turbo Speed: Parsing Device Health Services from Google By Kevin Pagano

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”: https://play.google.com/store/apps/details?id=com.google.android.apps.turbo 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. For this research I used a combination of my own personal phone, a Pixel 4A, as well as the test images provided by Josh Hickman found here.

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: data/data/com.google.android.apps.turbo/shared_prefs/app_usage_stats.xml 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: data\data\com.google.android.apps.turbo\databases\turbo.db 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: data\data\com.google.android.apps.turbo\databases\bluetooth.db 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 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 syste m. If you have any questions I can be reached via twitter @KevinPagano3 or emailed at stark4n6[at]gmail[dot]com....