Clockin’ In with Google’s Wear OS

Smart watches & fitness trackers. They are everywhere. Personally, I know more people that wear them than do not. While there is some consistency across most smart watches and fitness trackers, each one has their own particular features and nuances which can attract buyers and drive up prices. The wearables industry is worth a lot of money…roughly 20 billion USD in 2019…and it does not show signs of slowing down any time soon. Many people are interested in the health data collection capabilities of these devices which is helping to drive the adoption.

There are several players in the smart watch market: Apple, Fitbit, Samsung, and Garmin are the more notable companies in this space. Each of these companies manufacture their own hardware with each running a proprietary operating system. There may be changes on the horizon for Fitbit, though, as it was recently acquired by Google, and, while it is finally getting into the smart watch hardware market, Google has been in the smart watch operating system market for almost seven years, though you would be forgiven for not knowing it.

Wear OS is not exactly burning up the market share these days, but, as previously mentioned, that may be changing with Google’s acquisition of Fitbit. With that in mind, I thought I would take a look at Wear OS to see what, if anything, is present that may be of investigative value.  When conducting background on this subject much of what I found was older, and nothing mentioned a notorious security feature that causes a big headache.

Rewinding the Clock

Wear OS started out as Android Wear, and was introduced at Google I/O 2014. When announced, several OEMs were presented as partners, including Samsung, Asus, LG, HTC and Motorola. Throughout the remainder of the year, LG (G Watch), Sony (SmartWatch), Asus (ZenWatch), Motorola (Moto360), and Samsung (Gear Live) all shipped Android Wear watches. Huawei jumped into the fray in the first half of 2015 with the Huawei Watch.

Interestingly enough, of those manufacturers, only Motorola still uses the (descendant) operating system.

In 2018 Android Wear was rebranded to Wear OS, and, along with the new name, a reset in the version numbering. While Motorola is the lone remaining original OEM, some new players have entered: Fossil, Mobvoi, Oppo, Skagen, and Suunto. Who knows, Fitbit may be running Wear OS in the future.

Google took (and takes) a very Android-like approach with Wear OS. Wear OS is a baseline operating system, and smart watch OEMs are permitted to add layers on top of it in the way of apps, features, and watch faces. Some of the features (e.g. 24-7 heart rate monitoring, sleep monitoring) are dependent on a watch’s hardware (hardware is an entirely different article) and OEM software implementation, so some features appear some watches but may be absent on others. The experience across OEMs is different. Basically, the fragmentation that plagues Android also plagues Wear OS.

The Details

For this research I used my Pixel 3 running Android 11 on latest patch level as of November 2020, and the phone was rooted. Additionally, the following information on the Wear OS app and the watch itself is as follows:

Wear OS (phone app):
Version: 2.39.0.325424183.gms

Watch Info:
Make: Mobvoi
Model: TicWatch E2 (WG120026)
Build No: PWDR.190618.001.B6
Wear OS Version: 2.16 (H)
Patch Level: May 2020
Chipset:  Qualcomm Snapdragon Wear 2100

In order to access the watch, ADB is required. Just like an Android phone, turning on ADB required enabling Developer Options, which you can do by going to Settings > System > About and tapping on the Build Number seven times. The developer options on Wear OS are very similar to those of Android. Once ADB is enabled, an examiner can interact with the watch, but, just like modern Android phones, the ability to get to where the user data resides is restricted without root-level permissions, which requires unlocking the bootloader.  And, just like modern Android phones, unlocking the bootloader will wipe all user data from the watch, so proceed caution. I am not aware of any tool(s) that can currently bypass a locked bootloader on Wear OS watches, but I am optimistic since the U.S. versions of Mobvoi watches (and many other Wear OS watches) carry a Qualcomm chip.  For reference, the E2 uses the lowest-tier Qualcom Snapdragon Wear chip, the 2100, but there is also the 3100 and the recently released 4100.

Fortunately, there was a TWRP version for the TicWatch E2, which made things a bit easier. Flashing it to the watch was also the same. I won’t cover how to flash TWRP, but if you would like to know how please look here. Rebooting the watch into TWRP allowed me to send over Magisk and Magisk Manager and install those as well. Again, if I will not cover that process, but you can learn about that process here. I rebooted back into the OS, finished Magisk setup, and obtained root access.

A quick note. While this process worked with the TicWatch E2, it did not work on the Fossil Gen 5 watch I had. The connection I made to the TicWatch was over the wire; the watch has four contact points on the back of it (red arrow on left in Figure 1), at least one of which is presumably for data transfer. The Fossil watch only had two contact points, which are white rings around the heart rate sensor (blue arrow on right in Figure 1). I was able to establish an ADB connection with the Fossil, but the connection was wireless (I used Bluetooth and WiFi); however, once I booted into the bootloader, I was unable to re-establish a connection with it. I believe the two contact points on the back of the Fossil watch are for power only. To see the differences between the two sets of contact points see Figure 1.

For the remainder of this article, I will refer to the watch face as the home screen. It will make understanding swipe directions a bit easier. Also, the term “Wear OS app” refers to the app on the paired phone.

Looking Through the Crystal

Unlike Android on the phone, swiping up on the home screen displays notifications. Notifications are not grouped together by app, so they can get out of control quickly if a user lets them. Notification settings, such as which apps can send notifications and when notifications are silenced, are set within the Wear OS app on the paired phone. See Figure 3.

Figure 4 shows notification settings in the Wear OS app on the paired phone which dictates how notifications appear on the watch.

Figure 5 is the Notification screen from the watch.

Swiping left to right exposes the Google Assistant screen. The screen can be generally broken up into three sections: the Assistant microphone and weather conditions (Figure 6), Assistant quick actions (Figure 7), and inspirational quotes (Figure 8). Below the quote is button for access to the Assistant Settings menu.

Swiping right to left will reveal Tiles. Tiles are ways for an app to display quick bits of information without actually having to go into the app itself. For example, my tiles were (left to right) Google Fit, Weather, News Feed, and Timer. News Feed isn’t in the app drawer (more on that in a moment), but it is able to display information in Tiles. Tiles occupy the whole watch face. Figure 9 shows my tiles.

Tiles can be set, rearranged, and deleted on the watch, and in the Wear OS app on the phone. Figure 10 shows the Tiles menu in the phone app.

The side button, or the crown, takes a user to the app drawer. There are three sections of the app drawer. From top to bottom: recently used, pinned (or favorites), and the rest of the apps (listed in alphabetical order). Apps can be pinned by long pressing on the app, which will place a star over the app icon. They can be unpinned by long pressing the app again. Figure 11 shows the app drawer.

That is it from a UI perspective. There are other, more mundane, things such as settings, which will not be covered in this article.

Cracking Open the (Digital) Case

User interaction isn’t the only similarity between Wear OS and Android on a phone. A lot of the forensic artifacts are similar, too. The overall file system structure is the same. Figure 12 shows the root level of the file system, Figure 12-A shows the parition layout, and Figure 12-B shows the /data directory.

Since this is a blog article and not a book, I will highlight a few system artifacts that may be of interest. Because watch OEMs can add their own apps/features, things will be different between watch models, so I will try to stick with the more generic artifacts.

The first is Bluetooth. Bluetooth artifacts can be found in /data/misc/bluedroid/, just like a phone. The file of interest is bt_config.conf, also like the phone. Figure 13 shows the contents.

The area in the red box contains the Bluetooth MAC address of the watch and the Bluetooth name, and the area in the blue box shows the paired phone (Pixel 3) and the phone’s Bluetooth MAC address.

Note the TimeCreated timestamp at the top of the file is NOT the time the phone and watch were paired.

The next artifact is WiFi. Again, this is the same as an Android phone. The file WifiConfigStore.xml can be found in /data/misc/wifi. The blue box in Figure 14 shows the SSID of the stored WiFi connection, and the solid red box is the location of the WiFi password.

WiFi connections are transferred to the watch via the Wear OS app during initial setup; however settings can be adjusted on the watch, too, to include changing networks, adding new ones, and deleting saved ones. I did not try adding a network as the keyboard is absurdly small, and there would be no way I could type in a password without getting frustrated. 🙂

Up next is packages.list, which can be found in /data/system/. See Figure 15.

This file provides a list of packages (apps) that are currently installed on the watch, along with some metadata about them. Again, this is an artifact that is also present in Android phones.

Usage Stats! Yes, Usage Stats are present in Android Wear. If you are not familiar with Usage Stats, Jessica Hyde, Alexis Brignoni, and Yogesh Khatri have all put out some great work on the subject so I suggest looking at the research to understand the full benefits of this artifact.

Usage Stats are found in the same place as on an Android phone: /data/system/usagestats/. The version of Wear OS I examined is based on Android 9, so the Usage Stats were in XML. I suspect that the following version of Wear OS (released in December) would be based on Android 10, which would shift Usage Stats to a protobuf format, but that is speculation on my part. Figure 16 shows some sample output. Figure 16 shows a file from the weekly usage stats directory.

Along with Usage Stats, Battery Stats are also present. The file BatterystatsDumpsysTask.gz is present in the /data/data/com.google.android.gms/files directory. See Figure 17.

If you have not watched it already, I suggest watching Jessica Hyde’s 2018 SANS DFIR Summit presentation on how BatterystatsDumpsysTask can be used to determine application usage on an Android (and now Wear OS) device.

Information about sync’d accounts is also present on the watch, and, just like everything else thus far, can be found in the same locations as on an Android phone. I will mention three here:

/data/system_de/%PROFILENUMBER%/accounts_de.db

/data/system/sync/accounts.xml

/data/data/com.android.providers.contacts/databases/profile.db

Wear OS allows for multiple user accounts just like Android, so be aware that more than one account may be present on a watch. Also, accounts from other apps may be present on the watch.  The date/time accounts were added to the watch can be determined by examining the accounts_de.db database. If you want to get a listing of when each account was added, a simple SQL query will work:

SELECT accounts._id, accounts.name, debug_table.action_type, debug_table.time
FROM accounts
INNER JOIN debug_table on accounts._id=debug_table._id
ORDER by time

Look for the value of action_account_add in the column action_type.

I could continue with more artifacts, but, as I said, I would end up writing a book. The takeaway here is that many of the artifacts found on an Android phone can be found in Wear OS. Again, this is not surprising since Wear OS is basically Android-lite. The SANS 585 poster is a good resource to work from if you find yourself working on a Wear OS watch.

The good news is that because these (and probably many more) artifacts both reside in the same locations and have the same names as what is found on an Android phone, forensic tools can parse the artifacts I describe above. For example, I ran Alexis Brignoni et al.’s ALEAPP across a Wear OS image and it parsed the artifacts it knew about with no problem!

Watch Specific Data

There are a few things that are of interest that are watch-specific. The first deals with the watch face, and, there are two different places you can find information on the current watch face (there may be more, but these were the two I found). The first is home_preferences.xml, which is found in /data/data/com.google.andrdoid.wearable/shared_prefs. See Figure 18.

The tag last_watch_face (red box) contains the name of the last watch face used. Here, it is “Colorful”, which can be seen on the watch (Figure 19) and in the Wear OS app (Figure 20 – blue box).

The second location where the name of the current watch face can be found is wallpaper_info.xml and it can be found in /data/system/users/%USERNUMBER%/. Since there was only one user account on the watch, the path was /data/system/users/0/. The current watch face can be seen in the red box in Figure 21.

Note that watch faces can be set from either the watch or the paired phone.

Watch faces in Wear OS can have complications just like Apple’s watchOS. Complications are tracked in the database complications.db which can be found in /data/data/com.google.andrdoid.wearable.app/databases. See Figure 22.

This database is simple. The table of interest here is complications, and specifically, the column provider (red box). The naming scheme of the complications are fairly straight forward, but a quick Google search can always help if needed. Figure 19 shows my complications, which are (clockwise left to right) date, battery level, and what appears to be a world clock (set to London). The interesting thing here is that this database keeps a running history of all complications ever displayed. Because the column watch_face_component (blue box) displays which watch face displays which complications, an examiner can, by proxy, get a rough history of watch faces displayed on the watch. There are some watch faces that do not have complications, so those would be missing here. However, out of 31 watch faces available for my watch, only two did not have a complication, so the odds can be favorable.

In the same location is tile_config.db. This database contains information about the tiles that have been set. See Figure 23.

As with the complications database, tile_config.db is simple and straight forward. The table of interest here is tile_config. Figure 9 showed the tiles on my watch, and the list can be seen here in Figure 24. The column class_name (red box) tells the exact tile, but the package names (the app names) are in the package_name column (blue box). The column index (green box) contains information on the tile’s position relative to the home screen. For example, the Google Fit tile was the first tile I saw when swiping right to left on the home screen, so its index value is zero (0). The next tiles (continuing to swipe right to left) were Weather (index value of 1), News Feed (index value of 2), and Timer (index value of 3).

In the same app sandbox, the file launcherprefs.xml resides in the ./shared_prefs folder. See Figure 24.

The tag launcherorder (red box) refers to the pinned apps, which were seen in Figure 11.

The tag history (blue box) keeps a history of the last apps run, with the most recently run app listed first. I was able to see up to the last six (6) apps launched in this file. The apps I most recently launched in the order of most to least recent were:

Telegram
Fit Heart rate
Fit Workout
Weather
Messages
Settings

The order can be seen here. This appears to be related to the Recent apps in the app drawer. Figure 25 shows the Recent apps in the app drawer with the most recently launched app just above the pinned apps. Note, however, only the last three apps launched appear (Telegram, Fit Heart rate, and Fit Workout).

The file HatsPref.xml contains some general information about the device itself; specifically, the build of the watch (red box), and the time the device was first activated (blue box). The time stamp in the green box, system_update_timestamp, while not exactly the same, is very close to the same time stamp from the bt_config.conf file seen in Figure 13. They differ by approximately 50 seconds. See Figure 26.

The file seen in Figure 27, com.google.android.wearable.app_preferences.xml, is interesting. This file contains data about what is currently presented on the Google Assistant screen (a sample is seen in Figure 6) Take a look.

The string in the green box indicates which Google account is currently recognized by Assistant. This is a good indicator about which account is signed into the device. The area in the red box contains quite a bit of data. It is protobuf data that is base64 encoded. CyberChef makes quick work of it, though. See Figure 28.

The portion of Figure 28 in the red box shows the current weather conditions, along with a timestamp. The timestamp, based on my testing, looks to be the last time the weather conditions were updated. Figure 29 shows the corresponding Google Assistant screen.

Figure 30 shows the bottom portion of the protobuf data that contains an inspirational quote, and Figure 31 shows how it appears on the Google Assistant screen.

Revisiting Figure 27 for just a moment, the timestamp in the blue box appears to be the time the base64 encoded data was updated.

There is other data in the protobuf that requires more research to determine what it is and what, if any, value it may hold.

The file location_name_prefs.xml resides in the same directory. See Figure 32.

This file contains a city name (where I live) and a set of GPS coordinates (redacted). I thought that this might change as the phone detected movement but I was unable to get any change to occur in the file, even after several reboots in a different physical location (about five miles from my home). An interesting note here is that right after I installed TWRP and re-imaged the watch I took a baseline image, and location_name_prefs.xml is absent. I took another image six days later and it was there, so something caused this file to get generated, but I do not know enough at this point to hypothesize at what may have caused its creation. For now, just know that it contained the name of my town and a set of GPS coordinates of a place that the watch was frequently located.

What About the Phone?

The focus of this article has been the watch, but I would be remiss if I did not mention a couple of things on the paired phone. The first, and most obvious, being the connection between the phone and the watch. There are at least two places to go to find this data. First, bt_config.conf in the /data/misc/bluedroid directory. See Figure 33.

The area in the red box in Figure 33 contains information about the paired watch, including the timestamp of when it was first connected (blue box). I have seen, at times, where no timestamp is present for some paired devices documented in this file, so, depending on the configuration of the watch and phone, the timestamp may or may not be present.

The second location is in the path /data/data/com.google.android.wearable.app/shared_prefs/. The file com.google.android.wearable.app_prefs.xml is of interest. See Figure 34.

This file contains the Bluetooth MAC address of the currently paired watch (blue box). Note that the watch name is in the file with the tag adb_hub_target (green box); I would not count on seeing this as this could be related to my ADB activity with the watch.

The next thing…or things…are seen in the red box in Figure 35.

Figure 35 shows /data/data/com.google.wearable.app/files/.  The .PNG files contain “hero-” and then a random 8-character alphanumeric string. These are photos that represent the watches that have been paired to the device; they look like stock promotional pictures (you can see the TicWatch picture in the top part of Figure 20). For testing, I paired the TicWatch to the phone two different times, and a Fossil Gen 5 watch once. The Fossil watch is represented by the file hero-63fd9775.png and the TicWatch is represented by the other two .PNG files. If it is suspected that more than one Wear OS watch has been paired to the phone the presence of multiple photos could indicate that. Just be aware that the same watch paired two different times may generate multiple photos (it would be the same photo with different file names), and further investigation would be required.

Winding Down

If you have read this far you may be wondering “What about the steps, heart rate, and movement that a smartwatch captures, and what about apps that can be used on a watch?” Because there was quite a bit to cover here I thought it wise to split general Wear OS information from health data and third party app usage. Understanding Wear OS is important when discussing certain health data in Android, so this article serves as both an intro into Wear OS and a stepping stone to future articles about Android health data.

Third party apps on a watch would also generate their own blog articles.  🙂

Wear OS has been around in one form or another for seven years, but it has yet to establish a solid share in the smartwatch/wearable market like Apple, Fitbit, Samsung, and Garmin. However, that may be changing with the Fitbit acquisition. Since there are times where a watch is the only evidence that has been recovered, it is important to understand what hurdles an examiner may face, what forensic artifacts are left in Wear OS, and how those artifacts can be used, especially since we may see more of Wear OS in the future.