Exploring The Samsung Galaxy Watch4 Smartwatch
TL;DR
- Explored the Samsung Galaxy Watch4 Smartwatch to look for potential artifacts of interest.
- I was unable to obtain a full logical or physical acquisition of the smartwatch (root access is needed).
- Limited smartwatch information can be obtained from a traditional logical acquisition of a non-rooted paired Android smartphone
- Detailed health and activity-related smartwatch data can be obtained by downloading user data from the Samsung Health application. Acquisition of this data only requires physical access to the paired Android smartphone and the user’s Samsung account credentials.
Introduction
Back around late August 2021, I got my first smartwatch which was the Samsung Galaxy Watch4 Classic. Ever since then, I’ve been wearing it myself and found it useful for viewing my physical activities, health-related data, controlling the music player on my phone, viewing notifications, and much more. As a student studying digital forensics, I have heard many stories from my professors about how investigators were able to utilize data from wearables to solve a case. Considering that I got one of Samsung’s latest smartwatches, I was wondering what kinds of data I could extract from the device which may be useful for an investigation. As such, I decided to do some research and testing on my smartwatch and smartphone to figure this out.
Devices
For this project, I used my personal smartwatch and smartphone as those were the only devices that I had available to me. The smartwatch I was testing is the Samsung Galaxy Watch4 Classic 46mm with Bluetooth and Wifi capabilities. Going to Settings>About watch reveals that the smartwatch model number is SM-R890. The specifications of the smartwatch listed below were obtained from Samsung’s website.
- OS: Wear OS Powered by Samsung
- Memory: 1.5GB RAM & 16GB Internal Memory
- Connectivity: Bluetooth 5.0, Wi-Fi 802.11 a/b/g/n 2.4+5GHz, NFC
- Sensors: Accelerometer, Barometer, Gyro Sensor, Geomagnetic Sensor, Light Sensor, Optical Heart Rate Sensor, Electrical heart sensor, Bioelectrical Impedance Analysis Sensor, Hall Sensor
- Compatibility: Android 6.0 or higher
For ease of use, I removed the passcode lock on the smartwatch to make it easier to work with.
The phone that was used to pair with the smartwatch was my personal Samsung Galaxy S21 Ultra 5G with 128GB of storage. The model number of this phone is SM-G998U1. This smartphone has not been rooted, as such, we will be limited to performing a logical acquisition of this device.
Extracting Data Directly From The Smartwatch
My first course of action was to see whether it is possible to obtain data directly from the smartwatch. Compared to previous iterations of Samsung’s smartwatches which utilized the Tizen operating system, the Samsung Galaxy Watch4 utilizes Google’s Wear OS. As such, one would have to use Google’s Android Debug Bridge (ADB) rather than the Tizen SDK and SDB program to interact with the device.
Unfortunately, as the device has no physical connectors that would allow one to connect the smartwatch directly to a computer for acquisition, one would have to perform the acquisition using Wi-Fi. Before this was done, I disabled Bluetooth capabilities on my device to disconnect it from the paired phone. To enable ADB debugging over Wi-Fi on the smartwatch, the following steps need to be accomplished:
- Go to Settings>About watch>Software
- Tap the Software version box until you see “Developer mode turned on”
a. This will reveal the “Developer options” menu under Settings - Go to Settings>Developer options
- Enable ADB debugging
- Enable Debug over Wi-Fi
At this point, you would then connect the smartwatch to your lab’s Wi-Fi testing network by going to Settings>Connections>Wi-Fi and check if your network is available under “Available networks”. Once connected, you can then click on that network on the smartwatch to reveal the IP address assigned to the device. This is the IP address that will be used to connect to the device via ADB.
I then connected to the smartwatch using adb connect and used adb devices to verify if it was connected.
Once connected, I then tried to perform an adb backup utilizing adb backup -all, however, this did not yield any results as the generated backup.ab file was zero bytes.
I was able to utilize adb shell to view the files on the smartwatch. Seeing the folders here, I attempted to use adb pull to see if I can transfer those files over to my computer, however, the folders of interest such as the data and cache folders could not be copied since I did not have root access on the device.
The only folder that can be pulled without root access which may have artifacts of interest would be the sdcard folder. This folder is similar to the sdcard folder found in other Android phones in which users may use it to store documents, music, downloads, and more.
Unfortunately, I was unable to do a full logical acquisition of the smartwatch as we do not have root access to the device. Based on my research online, there has not been a rootkit developed yet in order to root the device. Additionally, even if there is a rootkit available, one would have to unlock the bootloader on the smartwatch which would automatically perform a factory reset of the device — I discovered this by accident. As such, it would be advisable to not root the device in an active investigation.
While it may not be feasible to do a full logical acquisition of the smartwatch, one can obtain the list of all packages installed on the smartwatch by entering the adb shell and utilizing pm list packages. This list can help assist investigators in discovering what applications may be installed on the device. Furthermore, this can give an idea of what applications may be installed on the paired smartphone as some of these smartwatch apps are intended to be companion apps to their smartphone counterparts.
Extracting Smartwatch Data From The Paired Smartphone
Seeing that not much information was obtainable directly from the smartwatch, I decided to see whether a logical acquisition of the paired smartphone would contain data pertaining to the smartwatch. Based on my knowledge and everyday use of my smartwatch, the smartphone applications of interest would be the following:
Galaxy Wearable (Samsung Gear)
- Package ID: com.samsung.android.app.watchmanager
- The primary application used to manage wearable devices via the connected smartphone. It can also be used to perform automatic or manual backups of smartwatch data.
Galaxy Watch4 Plugin
- Package ID: com.samsung.android.waterplugin
- A plugin that is required for the Galaxy Wearable application to interact with a Samsung Galaxy Watch4 device.
Samsung Health
- Package ID: com.sec.android.app.shealth
- An application used to track physical activities and overall health. With the Samsung Galaxy Watch4, this application can be used to track workout intensity, state of sleep, heart rate, stress, oxygen level in the blood, and more.
Samsung Health Monitor
- Package ID: com.samsung.android.shealthmonitor
- An application used to track ECG data from the smartwatch.
To begin, I first enabled ADB debugging on my smartphone and performed a Quick Acquisition utilizing Magnet AXIOM Process. Only Quick Acquisition was available as my device was not rooted. A quick acquisition will attempt to acquire the live data, perform an adb backup, acquire data from the SD card, and run Magnet AXIOM’s acquisition agent on the smartphone to get more data. While this acquisition should be straightforward, I have experienced consistent issues in this process. Of note, Magnet AXIOM’s acquisition agent would consistently fail, and the adb backup process would fail after extracting the “shared storage” portion of the phone. With regards to the adb backup issue, after obtaining the shared storage, a notification on the smartphone would appear saying “Operation Timed Out” right before attempting to perform ADB backup on “android”. Furthermore, when attempting to open the resulting adb backup file utilizing tools such as Bandizip (a file compression and decompression software), an error would pop up indicating that the archive is broken. Nevertheless, Magnet AXIOM Examine was still able to open the incomplete adb backup file.
In Magnet AXIOM Examine, I went to the file system viewer to look for folders with the Package IDs listed above. This was done by going to adb-data.tar\apps. None of the applications of interest were found within this folder. There is one application that may appear to be of interest which had the package name of com.samsung.android.app.watchmangerstub, however this folder only contained a file called _manifest which does not appear to have any interesting information.
I then decided to look in the acquired SD card data under the sdcard.tar.gz\sdcard\Android\data folder. In here I was able to find folders belonging to Samsung Health Monitor, Samsung Health, and com.samsung.android.app.watchmangerstub. Only the Samsung Health Monitor folder contained files under \com.samsung.android.shealthmonitor\files. Here, I found PDF files containing ECG records from the times when I performed a manual ECG reading in the past. Each PDF pertains to a single manual ECG reading. The numbers in the files appear to be associated with the dates the readings were performed in UTC-0000. The date format appears to be ECG_MMDD_hhmm_ss[ms][ms].
Overall, it appears that aside from the ECG PDF reports from Samsung Health Monitor, no other interesting information pertaining to the smartwatch was found. It is possible to be able to identify if a smartwatch was connected to the Android phone by looking at the live data via Dumpsys. Here we can identify that the smartwatch has a Bluetooth MAC address of 58:A6:39:CB:1A:FF.
Extracting Samsung Health Smartwatch Data From Smartphone Applications
Seeing that extracting smartwatch data directly from the device or from a logical acquisition of the paired smartphone did not yield many results, I decided to see whether either of the applications of interest had the capabilities to export data. The only applications capable of exporting data were the Samsung Health and Samsung Health Monitor apps. Both applications will export the data directly into the sdcard partition of the phone.
Note that to perform these acquisitions, you will need physical access to the paired smartphone. Direct access to the smartwatch is not needed. Furthermore, you would only need the user’s Samsung credentials in order to download data from the Samsung Health app. User credentials are not needed for the Samsung Health Monitor app.
To export data from the Samsung Health Monitor app you will have to do the following:
- Open the application
- Click on the Menu (hamburger icon located at the top left)
- Go to Data>Download ECG data
- Tap the download button and allow access to the filesystem if requested
- Once the download is complete, make note of the download location
To export data from the Samsung Health app you will have to do the following (requires user’s Samsung credentials):
- Open the application
- Click on the three vertical dots located at the top right of the application
- Click on Settings
- Click on Download personal data
- Tap the Download button
- Enter the password associated with the Samsung account and click ok (Note: a fingerprint can also be used instead of a username and password)
- Once the download is complete, make note of the download location
Once downloaded, you can then copy these files to your workstation by connecting the phone to your workstation via a USB cable. No logical or physical acquisition of the device via forensics tools is needed.
Another point that I did not explore here is the possibility of extracting the data via a web interface. When I was extracting the data from the Samsung Health application, there was a pop-up that did mention that it would be downloading some of the user data stored in Samsung’s servers. I am currently unaware if there is a method of extracting it from one of Samsung’s websites or not.
Understanding Samsung Health Monitor Files
Based on my testing, the data provided by the Samsung Health Monitor application only provides CSV files for each manual ECG measurement performed by the user. The naming format for the CSV files is YYYYMMDDhhmmss.csv in which the time represents the created time of the file. Some of the notable artifacts are that you can find the name and date of birth of the user associated with the ECG data. Furthermore, there exist fields that detail what device was used and what software version was running on that device.
Aside from those identifiers at the beginning of the file, the remainder of the file simply contains ECG data. I could not find any further documentation online regarding the files generated by Samsung Health Monitor.
Understanding Samsung Health Files
Based on my testing, the data provided by the Samsung Health application includes the following items:
- A folder named “files” which contains PDF files generated by the Samsung Health Monitor when manually monitoring ECG using the smartwatch. These are the same PDF files discovered in \com.samsung.android.shealthmonitor\files, however the file names will differ from what was found in the previous section.
- A folder named “jsons” which contains several JSON files.
- Several CSV files which contain health and activity-related data. The numbers at end of each CSV file pertain to the date these files were obtained. The format of this date is YYYYMMDDhhmm. For ease of writing, I will be excluding this timestamp when talking about the CSV files. These CSV files will be the main focus of this report.
Device Data
Perhaps the first CSV file that one should take a look at would be the com.samsung.health.device_profile file as this contains information on the devices used to provide health tracking data to the application. Some items of importance include the create_time field which I have determined to be related to the time when the smartwatch was paired with the phone, the capability field which indicates the name of the JSON file that details the capabilities of the smartwatch, and the deviceuuid field which is used to denote which device recorded the health data.
In the example above it can be seen that there are three different entries for the Galaxy Watch4 Classic. These different create_time values correspond to the times when I paired my smartwatch to my smartphone either after opening it from the box, or from a factory reset via unlocking the bootloader. Furthermore, with each pairing, it appears that this generates a new deviceuuid rather than utilizing the pre-existing ID. As such, with regards to the Galaxy Watch4 Classic, this field can be used to determine when the device was paired with the smartphone. The deviceuuid of my smartwatch are the following:
- kJu3WMkDT6
- uCOWoAaw12
- lWxECVG9Re
As for the device named “My Device” this corresponds to my smartphone, and although the create_time is listed on the day 8/30/2021, this does not correspond to when I bought the phone. Rather, it represents the time when I installed the Samsung Health application on my phone, as I never really had the need to use this application until I received my smartwatch which happens to be on the same day.
The JSON files specified in the capabilities field can be found under jsons\com.samsung.health.device_profile. Viewing the JSON folder reveals the capabilities of the associated device. This includes the overall device features and whether certain health trackers have support for continuous measuring or manual measuring. Furthermore, characteristics of the smartwatch such as the Bluetooth name of the device and the Bluetooth address used by the device can be found. It should be noted that if there are multiple smartwatch entries in the device_profile CSV file, the Bluetooth name can be used to help distinguish whether this is the same smartwatch or another device. As seen in the image below, the Bluetooth name of my device is “Galaxy Watch4 Classic (SZ9K)” which I also observed in the other capabilities JSON files. Additionally, the Bluetooth address found here is the same as what was previously identified during the logical acquisition of the smartphone.
The device features can be found under the device_feature field and are further sorted into other fields such as pedometer, hrm, sleep, floor, etc. Under each feature field is included a list of the various health statistics that can be recorded. For example, the hrm field states that the heart rate, alerted heart rate, and oxygen saturation can be recorded.
Furthermore, scrolling downwards, one can find detailed information regarding the smartwatch's features. For example, under the stress_feature field, one can see that the smartwatch has the ability to continuously and manually measure stress. This does not mean that the smartwatch has been set by the user to enable continuous measurement. As another example, under activity_recognition, the smartwatch can also recognize walking, running, and cycling activities.
There are more fields within this JSON file, however, I have been unable to find any resources which document this JSON file.
Health Data
A wealth of information can be obtained from all the other CSV files, this can include health statistics such as the user’s heart rate, stress, BMI, and more, but also activities such as steps taken, floors climbed, hours slept, and etc. Luckily, a lot of the health data is documented by Samsung’s Developer website which can be accessed here.
To determine which files contained health data generated by the smartwatch, I went to each file and looked for whether there were entries that contained the deviceuuids associated with the smartwatch I found in the device_profile CSV file. As all the CSV files contain prefixes that start with com.samsung.health or com.samsung.shealth, I will be omitting these for writing purposes.
Furthermore, it should be noted that the smartwatch-related CSV files had entries that go as far back as when I first bought the watch on August 2021. The only exception to this is the tracker.pedometer_step_count CSV file which only retains data as far as 35 days since the acquisition of the Samsung Health data.
Across all of the CSV files, the entries within these files have the following timestamp fields associated with each entry:
Health Data Analysis
Rather than rewriting the documentation provided by Samsung, I decided it would probably be more beneficial to determine whether the smartwatch is able to accurately record the user’s activities as they go throughout their day. To test this, I wore the watch and manually kept a log of major activities that I’ve done along such as whether I started or stopped walking, running, climbing the stairs, lying down, or sleeping. I’ve recorded these activities up to the minute and not the seconds place. Once I’ve worn the watch for approximately 24 hours, I removed it and then extracted my Samsung Health data to obtain the CSV files in order to compare the smartwatch’s recorded data with the activities I manually noted.
The CSV files called height, user_profile, weight, preferences, and tracker.pedometer_recommendation will be excluded as these primarily contain data that the user had to manually input into the device. Additionally, the breathing CSV file will not be included as this only tracks the breathing sessions a user has done after obtaining a high-stress value from the stress measurement application.
One common characteristic between all of the recorded data is that all of the timestamps are recorded in UTC-0000. However, most, if not all, CSV files will contain a column that contains the field “time_offset” which contains entries specifying the timezone offset that should be applied to the UTC-0000 timestamps in order to get the timestamps based on the device’s location. In my case, as I was operating in the EDT timezone, the time_offset recorded during testing was UTC-0400.
Additionally, I noticed that while most of the entries generated during testing utilized the deviceuuid of uCOWoAaw12 — which corresponds to the most recent deviceuuid assigned to my smartwatch — the CSV files step_daily_trend and tracker.pedometer_day_summary contained entries with the deviceuuid of kJuWMkDT6. Both deviceuuid values are still the same smartwatch, but I am unsure as to why there are different values between different CSV files. Regardless, based on my testing, this does not change the validity of the data.
floors_climbed
During my testing, I’ve climbed a total of three floors at my house and two floors at my university. Likewise, I have also gone down the same set of floors at both locations. The three floors recorded at my house were three separate runs of going up and down one floor. The two floors recorded at my university are a continuous set of stairs done in one run. An important factor to consider is that the stairs I climbed at my house consisted of 13 steps, whereas the floors at the university building consisted of 24 steps per floor.
Based on my findings, it appears that the smartwatch only records the floors climbed and does not record if the user went down a number of floors. The smartwatch was able to correctly detect the number of floors I climbed at the university building, however when it came to detecting the floors climbed at my house, it was only able to record one run.
The fact that it was not reliable at detecting the stairs at my home is somewhat explained by Samsung’s documentation in which it states that a floor is measured at three meters — whether this is three meters high or three meters diagonally is not explained, but based on my testing, it would appear to be talking about the distance climbed vertically. Each step at my home is approximately eight inches (20.32 cm) tall meaning that the stairs climbed would amount to 104 inches or 2.64 meters. As such, the entry with a create_time of 4/20/22 5:29:56 PM can be considered a mistake as this should technically have not been recorded at all. I am not sure how to explain why this was recorded other than attributing it to sensor errors or noisy user movement.
That being said, when it did record the floors climbed, the timestamps measured are accurate. Additionally, it also correctly measured the number of floors climbed at the university building. Each step in the university building I tested is about 6.5 inches (16.51 cm). Thus, each floor was 156 inches or 3.96 meters tall. If I had climbed three floors instead of two, perhaps the smartwatch may have registered it as four floors instead due to sensor errors or noisy user movement.
One item of note is that the create_time timestamps occur after the recorded end_time of the activities. I am not entirely sure why this may be the case, but perhaps the watch only records the raw data which is then pushed to the paired smartphone which does processing on the raw data in order to categorize the activities.
exercise
During my testing, the smartwatch did not record any entries in the exercise dataset. This is due to the fact that I did not manually start an exercise using the smartwatch app, and that I did not perform any activities for at least 10 minutes to trigger the auto-recording capabilities. From my experience, when I am performing an activity for at least 10 minutes, this will trigger the smartwatch to auto-record the activity as an exercise. As I did not do such activities during my testing this did not yield any results based on my testing timeframe.
I did find entries outside of my testing which correlates to times when I was performing an activity for more than 10 minutes. There is one entry on 4/15/2022 in which I do remember that I took more than 10 minutes to walk from one university building to another. The data recorded for that walk is shown in the table below.
I am inclined to say that the timestamps are at least accurate as this was certainly around the time that I had to walk to a university building in order to make it to a class I had at 7:20 PM. The end_time recorded is 4/15/2022 11:01:48 PM, which when applied with the time_offset of UTC-0400, becomes 4/15/2022 7:01:48 PM. Furthermore, based on Samsung’s documentation, the exercise_type is identified as 1001 which corresponds to walking.
I have not tested all different types of exercise as there are multiple predefined exercise types in Samsung’s documentation and I do not have the physical capabilities to perform all of these for 10 minutes. Samsung does have documentation on the exercise_type values it supports.
sleep
The smartwatch appears to correctly identify when the user has fallen asleep and has fully woken up. Furthermore, simply lying down and attempting to sleep by staying still will not trigger the smartwatch to record a sleep session. I went to bed on 4/21/2022 at around 2:41 AM and definitely had some trouble falling asleep. During the time I was trying to sleep I got up around 4:04 AM and visited the washroom and promptly went back to bed. Based on the sleep records, I fell asleep at 6:00 AM and eventually woke up at 11:13 AM. While I cannot exactly verify whether the timestamp of when my sleep started is accurate — as I would need to be awake in order to manually record that — the time recorded by the smartwatch of when I woke up is fairly accurate. Based on my manual logs, I woke up at around 11:12 AM which accounts for a one-minute difference between my records and the smartwatch’s records. One hypothesis for this minute difference is perhaps that the watch was monitoring to see whether I would go back to sleep or not since one of the stages in the “stages of sleep” includes brief periods of being awake. The picture below shows what the Samsung Health application shows in regards to my sleep chart.
Only one entry was created as I had only one sleep session. The contents of this entry are below.
The variables which I currently cannot determine are the factor_## fields. Unfortunately, Samsung does not appear to have documentation for this information. Perhaps these variables may have something to do with the sleep chart shown in the Samsung Health app, however, I cannot confidently say that is the case. I do notice that the sleep_duration is listed as 313, this appears to be measured in minutes as this is exactly the number of minutes between the start_time and the end_time.
With regards to the mental_recovery and physical_recovery fields, there is no documentation on Samsung’s website. Exploring the Samsung Health application reveals that these fields are associated with the user’s REM sleep and deep sleep respectively.
step_daily_trend
From a first glance, there appears to be no entries generated by my smartwatch for the day I started testing it on 4/20/2022. But, upon inspecting the day_time column and comparing it to Samsung’s documentation, the values in this column represent UNIX timestamps that indicate 00:00:00 UTC of the date exactly. Converting the UNIX time 1650412800000 reveals that this represents 4/20/2022 00:00:00 UTC+0000. As such the entry with the create_time 4/21/2022 5:45:44 AM appears to coincide with the date I started testing my smartwatch. Checking the other timestamps 1650240000000 and 1650499200000 reveals them to represent 4/18/2022 00:00:00 UTC+0000 and 4/21/2022 00:00:00 UTC+0000 respectively. Interestingly, it appears that the smartwatch did not generate a record for 4/19/2022 — this is simply because I did not wear the smartwatch during that day.
The primary benefit of this data source is that it can help give an idea of the number of steps, the distance, and the average speed of the user during a given day. Note that the units for speed, distance, and calories are meters per second, meters, and kilocalories respectively.
stress
During testing, I manually recorded my stress levels using the smartwatch at around 1:59 PM EST. Looking at the stress CSV file reveals one entry that corresponds to this time. The data is shown below.
Based on my experience with the device, the stress scale goes from 0 to 100 as I have had stress scores over 50 in the past. Overall, this entry shows that I was relaxed during the time as I had a really low score of nine. One aspect to revisit is the fact that the smartwatch has the capability to continuously monitor stress levels. I was not aware of this until after testing, and one would have to manually enable automatic measuring for stress on the smartwatch to obtain this feature.
stress.histogram
Only one record was found in the CSV file. The record points to the JSON file which contains the stress histogram data. The update_time coincides with the time I manually performed a stress measurement. As for the create_time, it appears to coincide with the last time I performed a manual stress measurement which was outside of the testing period.
Viewing the histogram file in \jsons\com.samsung.shealth.stress.histogram\ does not appear to reveal that much interesting information. Perhaps if I had enabled the continuous stress measurement, the data shown in this histogram may have been different.
tracker.heart_rate
During the time I tested the smartwatch, a total of 117 entries were recorded. Based on the data obtained, the smartwatch attempts to automatically record the user’s heart rate every 10 minutes starting at the 0 minutes position at the clock and it will also create an entry when the user performs a manual heart rate measurement. Although, the smartwatch appears to record every 10 minutes, it appears that there are occasions where it fails to record the user’s heart rate as there are some missing entries that I found.
Furthermore, it also does not appear to start immediately recording the user’s heart rate upon wearing the watch as I started wearing the watch on 1:28 PM EDT, however, the first heart rate entry begins at 4/20/2022 5:41:44 PM UTC-0000 (1:41:44 PM EDT).
Considering that the smartwatch records every 10 minutes, I would not consider this an extremely reliable data source for tracking the user’s heart rate as a person’s heart rate could drastically change between the 10-minute interval. For example, since I walked up the stairs in a university building at around 5:56:15 PM UTC-0000, I would expect to have an elevated heart rate, however, when checking the heart rate data, the smartwatch was not able to record this as the periodic measurement did not happen while I was climbing the stairs. As such, using the smartwatch heart rate data may not be useful in attempting to track user activities that may be shorter than 10 minutes. It does however appear to be useful in reconfirming the times when the user is either awake or asleep as I noticed that my heart rate tended to be much lower during the periods I was asleep.
Another uncertainty is whether the heart_rate values are a measurement only during the time it was measured, or if it is an average measurement over the span of 10 minutes. Samsung does not have any specific documentation regarding this. Taking an educated guess, we can compare the start_time and end_time as these relate to when the measurement started and ended. Considering that those two timestamps appear to be equal, I am inclined to say that the heart_rate values are not an average measurement over the span of 10 minutes. Perhaps more testing should be done to determine the nature of the heart_rate values.
Another potential area for further research would be to check whether the smartwatch would have a higher measuring frequency when the user is performing an exercise — either by manually starting it on the watch, or performing an action for 10 minutes straight. From my experience, when an exercise is performed, the watch will display the user’s heart rate and is able to show the user’s historical heart rate during the period of the exercise as a graph.
tracker.oxygen_saturation
During my testing, I did not perform any manual blood oxygen saturation measurements. However, I did find entries from the past where I did perform those manual measurements. As those entries are outside of my testing timeframe, they will be ignored. That being said, I found one entry that had a start_time timestamp that was around the time I was still sleeping. The details of the entry are shown below:
This entry was automatically taken while I was asleep. This may be evidence towards the fact that the smartwatch is continuously monitoring the user’s blood oxygen, but doesn’t create a record of all of it unless the user’s blood oxygen level falls to a certain threshold.
tracker.pedometer_day_summary
The data recorded in this CSV file is quite similar to those found previously in the step_daily_trend CSV file. The entries serve to summarize the user’s pedometer-related data for each day. Just like the step_daily_trend, the day_time value “165041800000” represents the day 4/20/2022 00:00:00 UTC+0000. New variables of interest include active_time, run_step_count, calorie, and walk_step_count. Unfortunately, I could not find any Samsung documentation explaining some of these variables. The value of active_time recorded during testing is 1654681, but the units are not listed. I initially assumed it was seconds, however, this resulted in an active_time of 459 hours. Assuming the units are milliseconds, active_time then becomes 0.45 hours which I may suspect to be the case — although I also find it hard to believe that I was actively walking for only 0.45 hours. More testing is definitely needed to determine the units of active_time.
tracker.pedometer_step_count
During the testing period, the smartwatch generated a total of 89 entries that detail the number of steps taken by a user. Unfortunately, I did not manually count all of the steps I took when I performed during testing, but based on what I’ve recorded, I find that the entries are fairly accurate. That being said I can count at least two outlying records where the smartwatch recorded steps even though I was either driving or lying down. Perhaps I was making arm movements that may have resembled walking to the smartwatch, but the steps recorded for these entries were on the order of 10 steps. Despite these outliers, I still do think that these records are fairly accurate as it was able to detect me running during testing.
Aside from the usual speed, distance, and calorie fields for each record, this CSV file also contains fields that pertain to how many of the steps taken were done by either running or walking. There is also a field called duration, however, there are no units attached to this field. To add more to the confusion, the start_time and end_time fields for each record are exactly one minute apart. As such, I think it is fair to say that the duration field does not reflect the difference between the start_time and end_time.
It is important to reiterate that while tracker.pedometer_step_count CSV file contains detailed information regarding the user’s movement on a given day, the data goes only as far as 35 days since the data was acquired. All the other CSV files on the other hand retained data as far back as the day I first paired the watch with my smartphone.
Further Research
There is definitely more research that can be done with regards to the health data produced by the smartwatch. Additional testing could include the following:
- enable all possible automatic measurements (ex. stress)
- manually start an exercise event via the smartwatch
- automatically start an exercise event via the smartwatch (occurs after 10 minutes of performing an activity)
- determine whether heart_rate values are a spot measurement or an average measurement over 10 minutes
Aside from those, while my research primarily went over the CSV files produced by the smartwatch via the Samsung Health app, it would also be good to look further into the JSON files to see if these files provide any more useful or detailed information. The folders containing the JSON files obtained from the Samsung Health data acquisition are shown below.
According to the folder properties, there is a total of 2798 files across these folders. I would imagine some of these JSON files would contain much more detailed information regarding the user’s activities, but, I did not have the time to look over these.
Conclusion
Currently, I see no possible methods of obtaining smartwatch-related data from a non-rooted Samsung Galaxy Watch4 smartwatch or a non-rooted paired Android smartphone. It is possible to extract user health and activity-related data from the Samsung Health and Samsung Health Monitor applications. Extracting this data does not require access to the smartwatch watch, but it does require access to the paired Android smartphone and the user’s Samsung credentials. Most of the artifacts of interest will be from the Samsung Health application. While there may be some slight errors in recording due to sensor interference or noisy user movement, I find that the data recorded by the smartwatch is accurate for the majority of the time.
In this report, I intentionally focused my efforts on the CSV files produced by the Samsung Health application which had entries produced by my smartwatch. As my smartphone has pedometer capabilities, there exist entries in some of the CSV files analyzed that were generated by the smartphone. In order to determine which entries belonged to which device, one would have to consult the device_profile CSV file. Perhaps one could use the smartphone entries to verify or fill in gaps in the smartwatch data.