Wearable Forensics Guide

• Fitness trackers: Fitbit Charge, Fitbit Sense, Fitbit Versa, Garmin Venu, Garmin Forerunner, Xiaomi Mi Band, Samsung Galaxy Fit.
• Smartwatches: Apple Watch, Samsung Galaxy Watch, Google Pixel Watch, Garmin smartwatches.
• Performance and recovery monitors: WHOOP, Oura Ring, Polar H10, Garmin HRM series.
• Medical-grade wearables: Dexcom CGM, Abbott FreeStyle Libre, Zio Patch, AliveCor KardiaMobile, Masimo and Nonin pulse oximeters.
• Other wearables: smart glasses, smart clothing, GPS ankle monitors, and body cameras.

• Heart rate sampled at high frequency using optical PPG.
• Heart rate variability calculated during sleep.
• Respiratory rate calculated during sleep.
• Skin temperature captured during sleep.
• Blood oxygen on supported models.
• Automatic workout detection with start and end timestamps.
• Sleep detection with light, REM, deep, and awake staging.
• Daily strain, recovery, and calories as derived summary metrics.

WHOOP Strap
  -> Bluetooth sync
WHOOP App on iOS or Android
  -> Cellular or Wi-Fi upload
WHOOP Cloud
  -> Web dashboard, app export, legal return, or API access

LAYER 1: DEVICE
Physical wearable hardware
On-board storage and recent sensor buffer

  Bluetooth sync

LAYER 2: PAIRED APP
Smartphone companion app
Local SQLite databases, caches, logs, preferences

  Internet upload

LAYER 3: CLOUD
Manufacturer cloud servers
Historical data, account logs, login history, API-accessible records

• Most wearables have limited local storage and keep a rolling buffer before sync.
• Physical acquisition is difficult because connectors, storage, firmware, and debug interfaces are proprietary.
• Practical physical evidence often includes serial number, MAC address, firmware version, battery state, and packaging/device labels.
• For most cases, the physical device should be preserved, but the phone app and cloud are more useful for acquisition.

# Android app database examples
/data/data/com.fitbit.FitbitMobile/databases/
/data/data/com.garmin.android.apps.connectmobile/databases/
/data/data/com.sec.android.app.shealth/databases/
/data/data/com.whoop.whoop/databases/
/data/data/com.ouraring.oura/databases/

# Apple Health on iOS full file system extraction
/private/var/mobile/Library/Health/healthdb.sqlite
/private/var/mobile/Library/Health/healthdb_secure.sqlite

Settings -> Privacy & Security -> Health -> Export All Health Data

Typical export contents:
export.xml
export_cda.xml
electrocardiograms/
workout-routes/

SELECT
  datetime(startDate, 'unixepoch') AS start_time,
  datetime(endDate, 'unixepoch') AS end_time,
  value AS heart_rate,
  sourceName AS device
FROM samples
JOIN source ON samples.source_id = source.ROWID
WHERE dataType = 5
ORDER BY startDate;

• Cloud data is often the most complete and reliable source because it may include full historical data and server-side timestamps.
• Access methods include voluntary export, valid legal process to the manufacturer, or credentialed API access.
• For API acquisition, record tool versions, account, date range, request parameters, raw responses, and hashes.

# WHOOP-style API acquisition pattern
import requests

token = "ACCESS_TOKEN"
headers = {"Authorization": f"Bearer {token}"}

cycles = requests.get(
    "https://api-7.whoop.com/users/me/cycles",
    headers=headers,
    params={"limit": 30}
)

hr_data = requests.get(
    "https://api-7.whoop.com/users/me/metrics/heart_rate",
    headers=headers,
    params={
        "start": "2024-01-01T00:00:00.000Z",
        "end": "2024-01-31T23:59:59.000Z"
    }
)

print(cycles.json())

# Fitbit-style conceptual API flow
# OAuth2 credentials are required before querying activity, sleep, or heart-rate endpoints.

• Confirm or contradict an alibi.
• Show whether someone was asleep, active, stationary, or moving.
• Reveal heart-rate spikes consistent with exertion, stress, or medical events.
• Correlate GPS location, steps, phone activity, CCTV, and communications.
• In serious cases, cessation of heart-rate data may help narrow a time-of-death window.

import datetime

# Unix epoch seconds
unix_ts = 1705312800
print(datetime.datetime.utcfromtimestamp(unix_ts))

# Millisecond epoch
ms_ts = 1705312800000
print(datetime.datetime.utcfromtimestamp(ms_ts / 1000))

# ISO 8601
from datetime import datetime
dt = datetime.fromisoformat("2024-01-15T10:00:00.000Z".replace("Z", "+00:00"))
print(dt)

# Apple Cocoa timestamp: seconds since 2001-01-01 UTC
cocoa_ts = 726480000
apple_epoch = datetime.datetime(2001, 1, 1)
print(apple_epoch + datetime.timedelta(seconds=cocoa_ts))

# Garmin FIT timestamp: seconds since 1989-12-31 UTC
garmin_ts = 883612800
garmin_epoch = datetime.datetime(1989, 12, 31)
print(garmin_epoch + datetime.timedelta(seconds=garmin_ts))

• Cloud databases commonly store timestamps in UTC while the app displays local time.
• Daylight saving transitions can create repeated or missing local-time hours.
• Travel can change displayed local time while UTC remains stable.
• Best practice: analyze in UTC and convert to local time only for reporting, clearly labelling the time zone.

• They can show the wearable was within Bluetooth range of the paired phone at a specific time.
• They create cloud upload events with independent server-side timestamps.
• They can reveal gaps where the wearable was removed, dead, blocked, or out of range.
• They help explain why cloud data may stop even though the device still existed physically.

Fitbit:
Fitbit device -> Bluetooth -> Fitbit app -> Internet -> Fitbit cloud
Common pattern: automatic sync when in range plus manual sync options

WHOOP:
WHOOP strap -> Bluetooth -> WHOOP app -> Internet -> WHOOP cloud
Common pattern: near-continuous or periodic background sync; strap buffer if app unavailable

Garmin:
Garmin device -> Bluetooth -> Garmin Connect app -> Garmin cloud
Garmin device -> Wi-Fi -> Garmin cloud
Garmin device -> USB -> Garmin Express

Apple Watch:
Apple Watch -> Bluetooth or Wi-Fi -> Paired iPhone -> Apple services
Health data aggregates in Apple Health on the iPhone

# Fitbit-style local sync log example
sqlite3 /data/data/com.fitbit.FitbitMobile/databases/fitbit.db \
  "SELECT * FROM sync_log ORDER BY sync_time DESC LIMIT 50;"

# Samsung Health-style sync history example
sqlite3 /data/data/com.sec.android.app.shealth/databases/health.db \
  "SELECT * FROM sync_history ORDER BY sync_date DESC;"

# Android logcat sync filtering
adb logcat | grep -i "bluetooth\|sync\|fitbit\|whoop\|garmin"

# iOS Apple Watch / Health sync areas from full file system extraction
/private/var/mobile/Library/Caches/com.apple.MobileBackup/
/private/var/mobile/Library/HealthKit/
/private/var/mobile/Library/Health/sync_log/

• The device was not worn or was removed.
• The wearable battery died.
• The wearable was outside Bluetooth range of the paired phone.
• The device was powered off or placed in a signal-blocking environment.
• The phone app was closed, uninstalled, not permitted background access, or malfunctioning.

• Strengths: worn 24/7, high-resolution heart-rate capture, strong sleep and workout boundaries, cloud-first retention.
• Acquisition: voluntary app/web export, legal process to provider, or credentialed API where authorised.
• Key exports: physiological cycles, sleeps, workouts, heart rate, metrics, and journal entries.

• Strengths: large installed base, long history, intraday HR on many models, sleep staging, GPS on supported devices.
• Acquisition: Fitbit account export, legal process through Google/Fitbit legal channels, OAuth2 API access where authorised.
• Investigative use: activity, sleep, heart-rate cessation, disability/insurance activity analysis, and alibi testing.

• Strengths: detailed HealthKit aggregation, ECG, fall detection, emergency SOS, crash detection, irregular rhythm notifications, GPS.
• Acquisition: paired iPhone extraction, Apple Health export, iCloud/Apple legal process where available and lawful.
• Important path: /private/var/mobile/Library/Health/healthdb.sqlite and healthdb_secure.sqlite from full file system extraction.

-- Apple Health heart-rate style query
SELECT
  datetime(startDate + 978307200, 'unixepoch') AS timestamp,
  value AS bpm,
  sourceName
FROM samples s
JOIN source src ON s.source_id = src.ROWID
WHERE dataType = 5
ORDER BY startDate;

-- Workout sessions
SELECT
  datetime(startDate + 978307200, 'unixepoch') AS start,
  datetime(endDate + 978307200, 'unixepoch') AS end,
  duration,
  totalDistance,
  totalEnergyBurned
FROM workouts
ORDER BY startDate;

• Strengths: GPS accuracy, FIT files, long local device storage on many models, Body Battery, stress, respiration, athletic metrics.
• Acquisition: Garmin Connect export, phone app extraction, FIT files from device or cloud export.
• FIT files can contain timestamps, GPS coordinates, altitude, heart rate, cadence, power, speed, and temperature.

# Parse a Garmin FIT file with fitparse
pip install fitparse

python3 << 'EOF'
import fitparse

fitfile = fitparse.FitFile("activity.fit")

for record in fitfile.get_messages("record"):
    data = {}
    for field in record:
        data[field.name] = field.value
    print(data)
EOF

• Strengths: often worn continuously, strong sleep staging, temperature, HRV, respiratory rate, readiness score, unobtrusive form factor.
• Acquisition: Oura cloud export, API access with credentials, legal process to the provider where appropriate.
• Forensic value: sleep/wake windows, temperature trends, recovery changes, activity and readiness patterns.

• Evidence is distributed across physical wearable, companion phone, and cloud provider.
• Cloud data can be dynamic because additional syncs may occur after seizure.
• The physical device may have less evidentiary data than the cloud account.
• Data is health data and may trigger heightened privacy requirements.
• Manufacturer returns should be hashed immediately and logged with receipt method and time.

WEARABLE DEVICE EVIDENCE LOG

Case Number:
Examiner Name:
Date/Time of Seizure (UTC):

DEVICE DETAILS
Manufacturer:
Model:
Serial Number:
Bluetooth MAC Address:
Firmware Version:
Battery Level at Seizure:
Device State: Powered ON / Powered OFF / Unknown
Was it being worn: Yes / No / Unknown
Screen condition:
Physical damage:
Accessories present:

PAIRED PHONE DETAILS
Phone make/model:
Phone serial:
Companion app installed:
Companion app version:
Last sync displayed:

CLOUD ACCOUNT
Platform:
Account email:
Account created date:
Data export requested: Yes / No
Legal process served: Yes / No
Date served:

STORAGE AND HANDLING
Evidence bag type:
Charging maintained: Yes / No
Evidence locker location:
Custody transfer notes:

# Hash all files in an evidence directory
find /evidence/wearable_data/ -type f -exec sha256sum {} \; > evidence_hashes.txt

# Verify later
sha256sum -c evidence_hashes.txt

# Hash a single file
sha256sum physiological_cycles.csv

import datetime
import hashlib
import json

acquisition_log = {
    "acquisition_date_utc": datetime.datetime.utcnow().isoformat(),
    "platform": "WHOOP",
    "method": "API",
    "account": "user@email.com",
    "examiner": "Your Name",
    "tool": "Python requests",
    "data_range": {
        "start": "2024-01-01T00:00:00Z",
        "end": "2024-01-31T23:59:59Z"
    }
}

with open("whoop_hr_data.json", "w", encoding="utf-8") as f:
    json.dump(hr_data, f)

with open("whoop_hr_data.json", "rb") as f:
    acquisition_log["file_hash_sha256"] = hashlib.sha256(f.read()).hexdigest()

with open("acquisition_log.json", "w", encoding="utf-8") as f:
    json.dump(acquisition_log, f, indent=2)

• GpsPrune: visualise GPS tracks from GPX, KML, and compatible route exports.
• Garmin FIT CSV Tool: convert FIT files to CSV for review.
• Health Auto Export: scheduled Apple Health export to CSV or JSON.
• iLEAPP: parse Apple Health and HealthKit artifacts from iOS extractions.
• DB Browser for SQLite: inspect wearable app databases and HealthKit databases.
• Pandas and Matplotlib: build custom charts and forensic timelines from CSV exports.

# Garmin FIT CSV Tool
java -jar FitCSVTool.jar activity.fit

# Plot WHOOP-style heart-rate CSV data
import pandas as pd
import matplotlib.pyplot as plt
import matplotlib.dates as mdates

hr_df = pd.read_csv("hr.csv", parse_dates=["Timestamp"])
hr_df = hr_df.sort_values("Timestamp")

day_data = hr_df[hr_df["Timestamp"].dt.date == pd.Timestamp("2024-01-15").date()]

fig, ax = plt.subplots(figsize=(14, 5))
ax.plot(day_data["Timestamp"], day_data["Heart Rate"], color="red", linewidth=0.8)
ax.set_title("Heart Rate - January 15, 2024")
ax.set_xlabel("Time (UTC)")
ax.set_ylabel("BPM")
ax.xaxis.set_major_formatter(mdates.DateFormatter("%H:%M"))
plt.tight_layout()
plt.savefig("hr_timeline_jan15.png", dpi=150)

• Look for last recorded heart-rate timestamp.
• Assess sudden spike followed by cessation, gradual decline, or normal sleep pattern ending unexpectedly.
• Correlate with GPS, phone activity, messages, CCTV, neighbour reports, and cloud/server timestamps.

• Confirm claimed sleep with sleep detection, low HR, HRV, and no step activity.
• Check GPS and phone proximity to support location claims.
• Look for device removal, data gaps, elevated HR, or movement during claimed rest periods.

• Compare claimed disability with step counts, GPS tracks, active minutes, workouts, and HR patterns.
• Check whether claimed injury time aligns with HR spikes, sudden movement, fall detection, GPS, or app activity.
• Document limitations: derived metrics are not direct proof and should be corroborated.

• Authenticity: data must be tied to the relevant device, account, export, or provider return.
• Integrity: hash files and maintain an audit trail showing no alteration after acquisition.
• Reliability: document wear state, device operation, battery, sync history, and known gaps.
• Relevance: explain why the data helps prove or disprove a fact in issue.

• Australia: Privacy Act 1988, Australian Privacy Principles, and health record obligations may apply.
• European Union: GDPR treats health data as special category data.
• United States: HIPAA may apply to medical sources; state biometric laws may also apply.
• Best practice: obtain consent, warrant, court order, or other lawful authority before acquisition.