Inside Android Samsung DHMS: Extracting Device Health, Thermal, and App-Control Data from Android - Part 1

As mentioned in my last post, I am currently researching Samsung system apps on Android.

In this post, I share some of my findings on the Samsung Device Health Management Service (SDHMS).

As the name suggests, SDHMS is responsible for monitoring the overall health of the device — including power consumption, temperature, and system load. It detects abnormal behavior (“anomalies”) in running apps, packages, and processes.

To do this, SDHMS records system health data. Some of this data may be valuable for forensic analysis.

App path: /data/data/com.sec.android.sdhms

Anomalies

First database I examined was anomaly.db

This database stores information about detected anomalies. On my test device, no anomalies were triggered, but one table stood out as particularly interesting to me:

Table "config_history": 

This table has four columns:

• time - Timestamp of the entry, stored as Unix epoch time in milliseconds
• config_key - The key of the configuration that was loaded
• config_version - The version of the loaded configuration
• reason - The reason why the entry was generated

In my test data, most entries in the reason column are BOOT_COMPLETED. I checked the last five entries, and they indeed correspond to my device reboots.

My results span approximately 1.5 years back, covering the full time span the device was in use. Additionally, I found entries with SYSPACKAGE_REMOVED, which likely indicate that a system package was removed from monitoring. This is less relevant for my current analysis.

From this, I was able to reconstruct a history of device (re)boots for my test device.

Table "anomaly_history":

On my test device, this table does not contain any data.

Based on the available columns, it appears that this table would record information about apps or packages that triggered an anomaly, including the type of anomaly and the timestamp of the event.

Generating meaningful test data for this table is challenging. Nevertheless, it seems designed to provide historical insight into anomalous app behavior when anomalies are detected.

Table "current_config":

I am confident that this table contains the current configuration or a reference to the config file.

• time - Timestamp of the entry in Unix epoch milliseconds
• config_key - Key of the configuration loaded
• config_version - Version of the loaded configuration
• config_data - The configuration data itself

The config_key and config_version correspond exactly to those referenced in the config_history table.

The config_data column holds a large amount of characters — for my device, 7,413 characters — which appears to be Base64-encoded.

Using CyberChef, it was possible to decode it:

1. From Base64

2. Protobuf Decode

3. JSON -> results in readable, structured data

The decoded content contains a lot of information, such as descriptions of anomaly types configured on the device. While it may not be immediately relevant to my current analysis, knowing how to read and decode this data will perhaps be useful in other cases.

Thermal Log

The next database I examined was thermal_log, which — as the name suggests — is responsible for thermal and system performance logging.

Table "NETSTAT": 

As the name implies, this table stores network usage statistics.

For my test device, data spans approximately 5 days.

• start_time - The start timestamp of measurement time window, Unix epoch time ms
• end_time - The end timestamp of measurement time window, Unix epoch time ms
• package_name - Package Name - related to the package that was measured
• uid - The App ID on the device
• net_usage - Bytes transferred in the measurement time window

This table allows you to track network activity per app over time.

Table "CPUSTAT": 

The CPUSTAT table seems to store data on CPU Usage statistics.

Again, for my test device, the data covers roughly 5 days.

• start_time - The start timestamp of measurement time window, Unix epoch time ms
• end_time - The end timestamp of measurement time window, Unix epoch time ms
• uptime - Uptime in seconds
• cputime - Total CPU time used by process since last boot
• process_name - Name of the process measured
• uid - Package ID related to the process
• pid - Process ID
• process_usage - CPU time used in measurement time windows

Note: CPU time values are scaled and depend on the number of cores. In general, the higher the process_usage value, the higher the CPU utilization and load generated by the process.

Table "TEMPERATURE":

This table contains temperature sensor data for the device.

For my test device, data covers roughly 5 days.

• timestamp - The start timestamp of measurement time window, Unix epoch time ms
• skin_temp - Chassis Temperature
• ap_temp - Processor Temperature
• bat_temp - Battery Temperature
• usb_temp - USB Temperature
• chg_temp - Charging IC Temperature
• pa_temp - Pulse Amplifier Temperature (Cell Radio)
• wifi_temp - WiFi Temperature

Notes on values:

• Temperatures are stored in degrees Celsius × 10, so divide by 10 to get °C.
• On devices with different regional settings, values may instead be stored in degrees Fahrenheit.
• Not all devices provide all sensor data, and some columns may aggregate readings from multiple sensors depending on the Hardware.

In general, this table allows you to get an overview of the device’s thermal state.

Conclusion

In the anomaly.db database, we can extract information such as when the device was rebooted. On my test device this data goes back for 1.5 years - the complete usage time frame of the device.

The thermal_log database provides detailed insights into system activity, including:

• CPU load generated by apps and processes
• Network usage per app
• Device temperature across multiple sensors

On my test device, this data spans roughly 5 days.

What's next?

There is still additional data stored by the app that I haven’t covered in this post. For example:

• Databases containing battery usage per app for the last 7 days — these require some mapping of numeric package IDs to package names.
• Log files that record e.g. which app was in use and which SIM card (slot) was active.

I will cover these findings and share further insights in a follow-up post on SDHMS.

I created parsers for ALEAPP for the results shared here - PR is open.