Изображение



📋 Оглавление


1. Введение: почему умные часы стали критическим источником доказательств

2. Архитектура WearOS: файловая система, разделы и хранилище данных

3. Правовые основы: допустимость доказательств и порядок изъятия

4. Первоначальные действия: изоляция устройства и предотвращение потери данных

5. Аппаратные методы извлечения: JTAG, ISP и Chip-Off

6. Программные методы: ADB, бэкапы и логическое извлечение

7. Облачная форензика WearOS: Google Fit, Wear OS Cloud и синхронизация

8. Анализ ключевых артефактов: геолокация, биометрия, активность

9. Форензика приложений WearOS: мессенджеры, платёжные системы, здоровье

10. Преодоление защиты: шифрование, PIN, биометрия и Trusted Environments

11. Продвинутые техники: реконструкция удалённых данных и timeline-анализ

12. Инструменты форензики WearOS: сравнение и практическое применение

13. Типичные ошибки при исследовании WearOS-устройств

14. FAQ: 12 горячих вопросов о форензике умных часов

15. Чек-лист: полное форензическое исследование WearOS-устройства

16. Заключение и теги



1. Введение: почему умные часы стали критическим источником доказательств


Умные часы на базе WearOS незаметно превратились в один из наиболее информативных источников криминалистических доказательств в современных расследованиях. Пока форензические эксперты десятилетиями оттачивали методологию работы со смартфонами, носимые устройства накапливали данные, которых нет больше нигде: непрерывная геолокация с шагом в несколько секунд, пульс и физиологические параметры, привязанные к точному времени и месту, данные о сне, стрессе и двигательной активности. Человек может оставить смартфон дома. Часы — снять крайне редко.

По данным исследований в области цифровой криминалистики, в делах об убийствах, ограблениях и корпоративном мошенничестве данные носимых устройств уже выступают ключевыми доказательствами в нескольких десятках задокументированных дел в год. Часы зафиксировали маршрут подозреваемого с точностью до улицы в момент преступления. Пульсоксиметр показал резкий физиологический стресс-ответ именно тогда, когда произошло событие. Шагомер опроверг алиби «я был дома весь вечер». Это не гипотетические сценарии — это реальные дела, описанные в профессиональной литературе по DFIR.

В 2026 году форензика WearOS столкнулась с целым рядом новых вызовов. Аппаратное шифрование методом файловой системы (FBE, File-Based Encryption) стало стандартом на всех устройствах. Биометрическая аутентификация защищает не только интерфейс, но и ключи расшифровки. Операционная система получила Trusted Execution Environment (TEE) с аппаратно-защищёнными ключами, недоступными даже при полном физическом доступе к микросхемам памяти. Тесная интеграция с облачной инфраструктурой Google означает, что часть критически важных данных никогда не хранится на устройстве в явном виде.

Для кого это руководство: для криминалистов-экспертов, специализирующихся на мобильной форензике; для следователей, которым нужно понять возможности и ограничения исследования WearOS; для специалистов DFIR в корпоративных расследованиях; для исследователей безопасности, изучающих архитектуру WearOS.

Руководство охватывает весь жизненный цикл форензического исследования: от изъятия устройства и первоначальных мер до продвинутого анализа артефактов и реконструкции удалённых данных. Все описанные методы и инструменты реально существуют и применяются в профессиональной практике.

> *💡 Руководство носит образовательный характер для специалистов в области цифровой криминалистики. Все описанные методы применяются исключительно в рамках законного расследования при наличии надлежащих правовых оснований.*



2. Архитектура WearOS: файловая система, разделы и хранилище данных


Глубокое понимание архитектуры WearOS — обязательный фундамент для любого форензического исследования. Эксперт, не знающий, где и как хранятся данные на целевом устройстве, работает вслепую и неизбежно пропускает критически важные артефакты.

Разделы WearOS и их форензическое значение


WearOS использует стандартную для Android-экосистемы схему разбиения на разделы, адаптированную под ограниченные аппаратные ресурсы носимых устройств. Форензическое значение разделов существенно различается:

РазделТочка монтированияФорензическое значениеШифрование
bootЯдро, ramdisk — для root-доступаНет
system/systemОС, системные приложения, конфигиНет
userdata/dataОсновное хранилище данных пользователяFBE (Android 10+)
cache/cacheВременные файлы, OTA-обновленияНет
vendor/vendorДрайверы производителя, HALНет
persist/persistПостоянные настройки, калибровкиНет
metadata/metadataМетаданные шифрования FBEНет

Раздел `/data` — главная цель форензического исследования. Именно здесь хранятся: пользовательские данные приложений (`/data/data/`), базы данных SQLite каждого приложения, ключи аутентификации, история звонков и сообщений (для часов с SIM-картой), геолокационная история и биометрические данные.

File-Based Encryption (FBE) в WearOS


Начиная с WearOS 3.x (Android 11 core), все устройства используют File-Based Encryption — пофайловое шифрование с разными ключами для разных директорий. Это принципиально важно для форензики:

Device Encrypted (DE) хранилище — данные зашифрованы ключом, привязанным к устройству. Доступны сразу после загрузки, до ввода PIN/пароля. Содержат: системные настройки, данные приложений, необходимых для работы часов до аутентификации.

Credential Encrypted (CE) хранилище — данные зашифрованы ключом, производным от PIN/пароля пользователя. Недоступны до первой аутентификации после перезагрузки (Before First Unlock — BFU состояние). Содержат: пользовательские данные большинства приложений, переписку, историю здоровья.

text
Форензическое следствие:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
BFU (Before First Unlock): часы не разблокированы
→ CE хранилище: зашифровано, данные недоступны
→ DE хранилище: доступно, но содержит минимум данных

AFU (After First Unlock): часы были разблокированы
→ CE хранилище: ключ активен в памяти, данные доступны
→ DE хранилище: доступно
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


Структура /data/data/ — расположение артефактов приложений


text
/data/data/
├── com.google.android.wearable.app/ # Системное WearOS-приложение
│ └── databases/
│ ├── wear_sync.db # Синхронизация с телефоном
│ └── notifications.db # История уведомлений

├── com.google.android.gms/ # Google Play Services
│ └── databases/
│ ├── metrics.db # Метрики устройства
│ └── icing.db # Поисковые данные

├── com.google.android.apps.fitness/ # Google Fit
│ └── databases/
│ ├── health_data.db # Данные о здоровье (КЛЮЧЕВОЙ артефакт)
│ └── activities.db # Активности с GPS

├── com.google.android.apps.maps/ # Google Maps на часах
│ └── databases/
│ └── gmm_myplaces.db # Избранные места и история

└── com.samsung.android.health/ # Samsung Health (Galaxy Watch)
└── databases/
└── health.db # Полная история биометрии


Специфика WearOS Qualcomm vs Samsung Exynos


Производители WearOS-устройств используют разные SoC, что влияет на методы извлечения:

Qualcomm-платформа (большинство устройств Google Pixel Watch, Mobvoi TicWatch): стандартный Qualcomm EDL (Emergency Download Mode) доступен через специальный USB-кабель; поддержка JTAG через тестовые точки на плате.

Samsung Exynos (Galaxy Watch серии): Samsung-специфический Download Mode (аналог EDL); инструменты Samsung Odin для работы на уровне прошивки; уникальная архитектура Knox Security, существенно усложняющая форензику.

> *⚠️ WearOS 4.x (2024–2026) в ряде устройств реализует Strongbox Keymaster — аппаратно изолированное хранилище ключей в отдельной микросхеме безопасности. Ключи шифрования CE-хранилища физически недоступны даже при Chip-Off атаке на основную память.*




Форензическое исследование без правовой базы — не исследование, а потенциальное уголовное дело против самого эксперта. Доказательства, полученные с нарушением процессуальных норм, не только теряют юридическую силу, но и могут поставить под угрозу всё расследование.

Правовое основание для доступа к WearOS-устройству


В рамках уголовного расследования: изъятие носимого устройства как вещественного доказательства осуществляется на основании постановления следователя или дознавателя (ст. 182 УПК РФ — обыск, ст. 183 — выемка). Для получения данных из облачных сервисов Google — судебное решение о предоставлении информации (ст. 185 УПК РФ — наложение ареста на почтово-телеграфные отправления, адаптируется для электронных данных).

В корпоративных расследованиях: умные часы, приобретённые сотрудником самостоятельно и содержащие личные данные, — личная собственность. Для доступа к ним даже в рамках корпоративного расследования требуется добровольное согласие сотрудника или судебный ордер. Исключение: устройства, выданные работодателем и являющиеся корпоративной собственностью, при наличии соответствующей политики использования.

Добровольная передача: владелец устройства вправе добровольно предоставить его для исследования. Факт добровольного согласия должен быть задокументирован письменно до начала любых действий с устройством.

Цепочка хранения доказательств (Chain of Custody)


Каждое действие с устройством с момента изъятия должно быть задокументировано:

text
АКТ ИЗЪЯТИЯ ЭЛЕКТРОННОГО УСТРОЙСТВА
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Устройство: Google Pixel Watch 3 (серийный номер: XXXXXXXXXXXX)
Место изъятия: [адрес]
Дата/время: 2026-02-15 / 14:32 MSK
Кем изъято: [ФИО, должность]
Состояние: включено/выключено/заряд XX%
Описание: [внешний вид, повреждения, наличие ремешка]
Упаковка: антистатический пакет #001, опечатан
Фотофиксация: IMG_001.jpg — IMG_010.jpg

Передано: [ФИО получателя, должность, дата/время]
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


Порядок работы с устройством до форензического исследования


1. Немедленно поместить устройство в клетку Фарадея или специальный RF-экранирующий пакет — предотвратить удалённую блокировку или стирание данных (функция «Найти устройство» Google)
2. Зафиксировать текущее состояние: включено или выключено, процент заряда батареи, наличие уведомлений на экране
3. Если устройство включено и разблокировано — сохранить это состояние критически важно (AFU vs BFU)
4. Обеспечить зарядку через RF-экранирующий пакет при необходимости
5. Не нажимать кнопки и не взаимодействовать с экраном до начала форензического исследования

> *⚠️ Включение или выключение WearOS-устройства без понимания последствий для шифрования — наиболее распространённая ошибка, которая может навсегда лишить доступа к CE-хранилищу. Если устройство включено и разблокировано (AFU) — сохраняйте это состояние любой ценой.*



4. Первоначальные действия: изоляция устройства и предотвращение потери данных


Первые минуты после получения WearOS-устройства определяют, насколько полные данные удастся извлечь. Ошибки на этом этапе — перевод устройства в BFU состояние, разряд батареи, удалённое стирание — необратимы. Этот раздел описывает систематический подход к первоначальным действиям.

Классификация состояния устройства при получении


Первый шаг — определить форензическое состояние устройства и его потенциал для извлечения данных:

text
СОСТОЯНИЕ А: Устройство включено, разблокировано (AFU)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Потенциал: МАКСИМАЛЬНЫЙ — CE ключ активен в памяти
Приоритет: немедленная изоляция от сети + работа с памятью
Риски: удалённое стирание через Google Find My Device

СОСТОЯНИЕ Б: Устройство включено, заблокировано (AFU-locked)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Потенциал: ВЫСОКИЙ — CE ключ активен, нужна аутентификация
Приоритет: изоляция от сети, попытка аутентификации
Риски: исчерпание попыток PIN → перезагрузка → BFU

СОСТОЯНИЕ В: Устройство выключено (BFU)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Потенциал: ОГРАНИЧЕННЫЙ — CE хранилище зашифровано
Доступно: DE хранилище, системные данные
Риски: минимальны при правильном хранении

СОСТОЯНИЕ Г: Устройство повреждено или не включается
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Потенциал: ЗАВИСИТ ОТ ТИПА ПОВРЕЖДЕНИЯ
Действия: аппаратные методы (JTAG/ISP/Chip-Off)


RF-изоляция: типы и применение


Изоляция от радиосетей — первоочередная мера для предотвращения удалённого стирания:

Клетка Фарадея — металлический экранирующий контейнер, блокирующий все радиосигналы (WiFi, Bluetooth, LTE, NFC). Профессиональные модели: Ramsey SE-3 Forensic Isolation Bag, Paraben Wireless StrongHold Bag. Обеспечивает полную изоляцию, но ограничивает физический доступ.

RF-экранирующие пакеты — одноразовые пакеты из металлизированного материала. Уступают профессиональным клеткам по уровню подавления, но достаточны для большинства сценариев. Требуют проверки целостности перед использованием.

Режим полёта — наименее надёжный вариант: программная блокировка радиомодулей может быть отменена удалённым командой при кратковременном восстановлении связи. Допустим только как временная мера до помещения в аппаратную клетку.

bash
<h2 id="vklyuchenie-rezhima-polyota-cherez-adb-esli-uzhe-est-adb-dostup">Включение режима полёта через ADB (если уже есть ADB-доступ)</h2>
adb shell settings put global airplane_mode_on 1
adb shell am broadcast -a android.intent.action.AIRPLANE_MODE --ez state true

<h2 id="proverka-sostoyaniya-setevyh-interfeysov">Проверка состояния сетевых интерфейсов</h2>
adb shell ip link show
<h2 id="vse-interfeysy-dolzhny-byt-v-sostoyanii-down">Все интерфейсы должны быть в состоянии DOWN</h2>


Документирование состояния до начала извлечения


bash
<h2 id="posle-ustanovki-adb-soedineniya-pervichnyy-snimok-sostoyaniya">После установки ADB-соединения — первичный снимок состояния</h2>

<h2 id="informatsiya-ob-ustroystve">Информация об устройстве</h2>
adb shell getprop ro.product.model # Модель
adb shell getprop ro.build.version.release # Версия Android
adb shell getprop ro.build.version.sdk # API level
adb shell getprop ro.serialno # Серийный номер

<h2 id="sostoyanie-batarei">Состояние батареи</h2>
adb shell dumpsys battery | grep -E "level|status|plugged"

<h2 id="vremya-ustroystva-vazhno-dlya-timezone-forenziki">Время устройства (важно для timezone форензики)</h2>
adb shell date
adb shell settings get system time_zone

<h2 id="sostoyanie-shifrovaniya">Состояние шифрования</h2>
adb shell getprop ro.crypto.state # encrypted / unencrypted
adb shell getprop ro.crypto.type # file / block

<h2 id="vklyuchyon-li-usb-debagging-autentifikatsionnyy-status">Включён ли USB-дебаггинг (аутентификационный статус)</h2>
adb shell getprop service.adb.tcp.port

<h2 id="hesh-tekuschego-sostoyaniya-proc-version-dlya-dokumentatsii">Хеш текущего состояния /proc/version (для документации)</h2>
adb shell cat /proc/version


Обеспечение заряда в условиях изоляции


Разряд батареи в процессе исследования может привести к потере данных из оперативной памяти (AFU → BFU переход) и прерыванию процессов извлечения. Профессиональное решение — RF-прозрачные зарядные решения, позволяющие подключить зарядку через экранирующий контейнер без нарушения RF-изоляции.

> *💡 Документируйте процент заряда батареи каждые 30 минут в ходе длительных процедур извлечения. Это позволит восстановить временну́ю шкалу работы с устройством и подтвердить непрерывность цепочки хранения доказательств.*



5. Аппаратные методы извлечения: JTAG, ISP и Chip-Off


Аппаратные методы извлечения применяются тогда, когда программные методы недоступны: устройство не реагирует на ADB, PIN неизвестен и устройство в BFU состоянии, или устройство физически повреждено. Эти методы требуют специализированного оборудования, навыков пайки и глубокого понимания аппаратной архитектуры.

JTAG: прямое чтение через отладочный интерфейс


JTAG (Joint Test Action Group) — стандартный отладочный интерфейс, реализованный в большинстве ARM-процессоров. Позволяет читать содержимое памяти через тестовые точки на PCB (печатной плате), минуя операционную систему.

Применимость для WearOS: JTAG-точки присутствуют на большинстве WearOS-устройств, но их расположение различается по моделям. Физически точки представляют собой небольшие контактные площадки на плате под 0,5–1 мм диаметром.

Оборудование: RIFF Box 2, JTAG Pro, Medusa PRO II — профессиональные JTAG/ISP боксы с поддержкой WearOS-чипов.

text
Процедура JTAG для WearOS (общий алгоритм):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Разборка корпуса часов (специфична для каждой модели)
2. Идентификация JTAG-точек по схеме (TDI, TDO, TCK, TMS, GND)
3. Пайка тонких проводов к тестовым точкам (0,1 мм провод)
4. Подключение к JTAG-боксу
5. Определение JTAG-цепи (boundary scan)
6. Чтение содержимого NAND/eMMC через JTAG
7. Получение физического образа памяти
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ограничения WearOS 2026:
- Физический образ зашифрован (FBE)
- Без ключей расшифровки данные нечитаемы
- JTAG может быть заблокирован (eFuse JTAG lock)


ISP: прямое чтение памяти через интерфейс программирования


ISP (In-System Programming) — метод чтения eMMC/UFS памяти напрямую через интерфейс NAND без демонтажа чипа. Более простой в реализации, чем JTAG.

Применимость: работает на устройствах с eMMC-памятью; UFS-устройства требуют специального адаптера; необходим физический доступ к контактам eMMC на плате.

isp
для eMMC WearOS:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Оборудование: Medusa PRO II / UFi Box / Easy JTAG Plus
1. Разборка устройства
2. Идентификация и обнажение eMMC-чипа
3. Подключение ISP-адаптера к контактам eMMC
(CLK, CMD, DAT0-7, VCC, VCCQ, GND)
4. Загрузка профиля чипа в программатор
5. Чтение всех разделов в образ (.bin)
6. Попытка расшифровки через известные ключи
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


Chip-Off: демонтаж и прямое чтение микросхемы памяти


Chip-Off — наиболее инвазивный метод: физический демонтаж микросхемы памяти с платы для прямого чтения через специализированный программатор. Применяется как последнее средство при невозможности использования JTAG и ISP.

Критическое предупреждение: демонтаж микросхемы при неправильном выполнении необратимо уничтожает устройство и данные. Метод требует профессиональных навыков пайки с применением горячего воздуха или BGA-ребольлинга.

chip
-Off: схема работы
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Оборудование: паяльная станция горячего воздуха + BGA-программатор
Профессиональные решения: UP828 Pro, TNM Flash Programmer

Этапы:
1. Тепловая карта платы — установить профиль температуры
2. Нанесение флюса на область eMMC/UFS чипа
3. Демонтаж чипа (220–260°C горячим воздухом)
4. Очистка контактов, reballing (восстановление шариков BGA)
5. Установка в BGA-программатор
6. Чтение содержимого в RAW-образ
7. Реконструкция логической структуры из RAW-данных

Ограничения 2026:
Если ключи шифрования хранятся в отдельном Secure Element
(Titan M2, Samsung Knox) — Chip-Off даёт только зашифрованный образ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


Сравнение аппаратных методов


МетодИнвазивностьОборудованиеДля WearOSШифрование
JTAGСредняяRIFF Box 2, Medusa PROБольшинствоОбходит ОС, не шифрование
ISPСредняяUFi Box, Easy JTAGeMMC-устройстваОбходит ОС, не шифрование
Chip-OffВысокаяBGA-станция + программаторПоследний вариантФизический образ зашифрован

> *⚠️ Аппаратные методы дают физический образ памяти, но не расшифровывают данные. Если ключи шифрования хранятся в Titan M2 (Pixel Watch) или Knox Vault (Galaxy Watch), физический образ содержит зашифрованные данные, которые без соответствующих ключей не поддаются прочтению.*



6. Программные методы: ADB, бэкапы и логическое извлечение


Программные методы — первый выбор для форензического исследования WearOS, поскольку они минимально инвазивны, воспроизводимы и не требуют разборки устройства. Применимость ограничена состоянием устройства: ADB должен быть включён или включаем, устройство должно быть в AFU-состоянии для полного доступа к данным.

ADB (Android Debug Bridge): основной программный инструмент


ADB — отладочный интерфейс Android, обеспечивающий доступ к командной строке устройства. В WearOS ADB доступен через WiFi (основной метод, так как большинство часов не имеет полноразмерного USB-разъёма) или через Bluetooth-ADB.

bash
<h2 id="podklyuchenie-adb-k-wearos-cherez-wifi">Подключение ADB к WearOS через WiFi</h2>
<h2 id="snachala-uznat-ip-adres-chasov">Сначала узнать IP-адрес часов:</h2>
<h2 id="nastroyki-o-chasah-sostoyanie-ip-adres">Настройки → О часах → Состояние → IP-адрес</h2>

<h2 id="podklyuchenie-port-5555-po-umolchaniyu">Подключение (порт 5555 по умолчанию)</h2>
adb connect 192.168.1.XXX:5555

<h2 id="proverka-podklyucheniya">Проверка подключения</h2>
adb devices
<h2 id="ozhidaemyy-vyvod-192-168-1-xxx-5555-device">Ожидаемый вывод: 192.168.1.XXX:5555 device</h2>

<h2 id="esli-trebuetsya-avtorizatsiya-prinyat-zapros-na-ekrane-chasov">Если требуется авторизация — принять запрос на экране часов</h2>

<h2 id="shell-dostup">Shell-доступ</h2>
adb shell

<h2 id="informatsiya-o-faylovoy-sisteme">Информация о файловой системе</h2>
adb shell df -h
adb shell mount | grep -E "(data|system|vendor)"


Логическое извлечение через ADB backup


ADB backup — встроенный механизм резервного копирования Android. В WearOS предоставляет ограниченный, но ценный набор данных:

bash
<h2 id="polnyy-adb-backup-trebuet-podtverzhdeniya-na-ekrane-chasov">Полный ADB backup (требует подтверждения на экране часов!)</h2>
adb backup -apk -shared -all -f wearos_backup_$(date +%Y%m%d_%H%M%S).ab

<h2 id="backup-konkretnogo-prilozheniya">Backup конкретного приложения</h2>
adb backup -apk com.google.android.apps.fitness \
-f google_fit_backup.ab

<h2 id="konvertatsiya-ab-fayla-v-chitaemyy-tar">Конвертация .ab файла в читаемый .tar</h2>
<h2 id="trebuet-pip-install-android-backup-extractor-ili-java">Требует: pip install android-backup-extractor или Java</h2>
java -jar abe.jar unpack wearos_backup.ab wearos_backup.tar
tar -xvf wearos_backup.tar -C ./extracted/

<h2 id="pryamoe-chtenie-bazy-dannyh-trebuet-root-ili-adb-s-povyshennymi-pravami">Прямое чтение базы данных (требует root или ADB с повышенными правами)</h2>
adb shell run-as com.google.android.apps.fitness \
cat /data/data/com.google.android.apps.fitness/databases/health_data.db \
> health_data.db


Извлечение данных через ADB pull


bash
<h2 id="sozdanie-forenzicheskoy-kopii-klyuchevyh-direktoriy">Создание форензической копии ключевых директорий</h2>
<h2 id="trebuet-root-dostup-ili-razblokirovannyy-bootloader">(требует root-доступ или разблокированный bootloader)</h2>

<h2 id="direktoriya-dannyh-prilozheniy">Директория данных приложений</h2>
adb pull /data/data/ ./extracted_data/ 2>/dev/null

<h2 id="konkretnye-bazy-dannyh-zdorovya">Конкретные базы данных здоровья</h2>
adb pull /data/data/com.google.android.apps.fitness/databases/ ./fitness_db/
adb pull /data/data/com.samsung.android.health/databases/ ./samsung_health_db/

<h2 id="logi-sistemy-dostupny-bez-root">Логи системы (доступны без root)</h2>
adb shell logcat -d -v time > system_logs.txt
adb bugreport > bugreport_$(date +%Y%m%d).zip

<h2 id="spisok-ustanovlennyh-prilozheniy">Список установленных приложений</h2>
adb shell pm list packages -f > installed_packages.txt

<h2 id="damp-aktivnyh-protsessov-i-pamyati">Дамп активных процессов и памяти</h2>
adb shell ps -A > running_processes.txt
adb shell dumpsys > dumpsys_full.txt

<h2 id="informatsiya-o-geolokatsii-iz-sistemnogo-servisa">Информация о геолокации из системного сервиса</h2>
adb shell dumpsys location > location_service.txt


Создание физического образа через ADB (root-доступ)


При наличии root-доступа (разблокированный bootloader или кастомный recovery):

bash
<h2 id="opredelit-ustroystvo-razdela-userdata">Определить устройство раздела userdata</h2>
adb shell ls -la /dev/block/by-name/userdata

<h2 id="sozdanie-pobitovogo-obraza-razdela">Создание побитового образа раздела</h2>
<h2 id="zamenit-dev-block-sda18-na-fakticheskoe-ustroystvo">(заменить /dev/block/sda18 на фактическое устройство)</h2>
adb shell "dd if=/dev/block/sda18 bs=4096 | gzip -9" \
| dd of=userdata_image_$(date +%Y%m%d).img.gz

<h2 id="proverka-tselostnosti-obraza">Проверка целостности образа</h2>
adb shell "md5sum /dev/block/sda18"
md5sum userdata_image_$(date +%Y%m%d).img.gz

<h2 id="alternativa-cherez-twrp-esli-ustanovlen">Альтернатива: через TWRP (если установлен)</h2>
<h2 id="adb-shell-twrp-backup-data-sdcard-forensic-backup">adb shell twrp backup data /sdcard/forensic_backup/</h2>


Сравнение программных методов по полноте извлечения


МетодДоступностьRoot нуженПолнота данныхДоказательная сила
ADB logcatADB включёнНетНизкая (только логи)Средняя
ADB backupADB включён, AFUНетСредняя (приложения)Высокая
ADB pull /dataADB включён, rootДаВысокая (все файлы)Высокая
Физический образRoot + ADBДаМаксимальнаяМаксимальная

> *💡 Даже без root-доступа ADB предоставляет ценные данные: bugreport содержит системные логи, статистику батареи, историю сетевых подключений и другие артефакты, полезные для форензики WearOS.*



7. Облачная форензика WearOS: Google Fit, Wear OS Cloud и синхронизация


Особенность WearOS-экосистемы 2026 года состоит в том, что значительная часть данных хранится не на устройстве, а в облачной инфраструктуре Google. Данные Google Fit, история активностей, уведомления и настройки синхронизируются с Google-аккаунтом пользователя. Для форензики это означает доступ к более полным и долгосрочным данным, чем хранящиеся локально.

Типы данных WearOS в облаке Google


СервисДанныеСрок храненияПравовой запрос
Google Fit APIАктивности, шаги, пульс, сон, GPS-трекиДо 7 летMLAT / Запрос в Google
Google Location HistoryGeolocation timeline с часовДо удаления пользователемMLAT / Запрос в Google
Google TakeoutПолный экспорт всех данных аккаунтаПо запросуMLAT / С согласия владельца
Wear OS Cloud BackupНастройки, приложения, данные8 недель (Pixel Watch)MLAT / Запрос в Google
Google Pay / WalletИстория транзакций с часов18 месяцевMLAT / Запрос в Google

Google Takeout: добровольный экспорт данных аккаунта


Если аккаунт пользователя доступен (с его согласия или по судебному решению), Google Takeout даёт полный экспорт всех данных:

bash
<h2 id="dannye-takeout-ot-wearos-vklyuchayut">Данные Takeout от WearOS включают:</h2>
<h2 id="1-vse-dannye-google-fit-fitness-data-json-activities">1. Все данные Google Fit (fitness_data.json, activities/)</h2>
<h2 id="2-istoriya-mestopolozheniy-semantic-location-history">2. История местоположений (Semantic Location History/)</h2>
<h2 id="3-google-pay-tranzaktsii">3. Google Pay транзакции</h2>
<h2 id="4-dannye-prilozheniy-esli-prilozheniya-podderzhivayut-eksport">4. Данные приложений (если приложения поддерживают экспорт)</h2>

<h2 id="struktura-takeout-arhiva-dlya-wearos-dannyh">Структура Takeout архива для WearOS-данных:</h2>
Takeout/
├── Fit/ # Google Fit данные
│ ├── Daily activity metrics/ # Ежедневная активность
│ ├── Heart Points/ # Очки активности сердца
│ └── All Sessions/ # Тренировки с GPS

├── Maps/ # Google Maps данные
│ └── My Activity/ # История поиска и навигации

├── Location History/ # История местоположений
│ ├── Semantic Location History/
│ │ └── 2025/
│ │ └── 2025_February.json # Пути + остановки по месяцам
│ └── Records.json # Все точки GPS в хронологии

└── Pay/ # Google Pay транзакции
└── transactions.csv


Программный доступ к данным Google Fit через API


При наличии OAuth-токена аккаунта (например, полученного из устройства) возможен API-доступ к данным Fit:

python
<h2 id="google-fit-extractor-py">google_fit_extractor.py</h2>
<h2 id="trebuet-pip-install-google-auth-google-auth-oauthlib-google-auth-httplib2">Требует: pip install google-auth google-auth-oauthlib google-auth-httplib2</h2>
<h2 id="dokumentatsiya-developers-google-com-fit-rest-v1-get-started">Документация: developers.google.com/fit/rest/v1/get-started</h2>

from google.oauth2.credentials import Credentials
from googleapiclient.discovery import build
import datetime
import json

def extract_fitness_data(access_token: str, start_date: str, end_date: str):
"""
Извлечь данные Google Fit через API.
start_date, end_date: формат 'YYYY-MM-DD'
"""
credentials = Credentials(token=access_token)
service = build('fitness', 'v1', credentials=credentials)

# Конвертация дат в nanoseconds Unix timestamp
start_ns = int(datetime.datetime.strptime(
start_date, '%Y-%m-%d').timestamp() * 1e9)
end_ns = int(datetime.datetime.strptime(
end_date, '%Y-%m-%d').timestamp() * 1e9)

# Список datasources (источников данных)
datasources = service.users().dataSources().list(
userId='me').execute()

results = {}
for ds in datasources.get('dataSource', []):
ds_id = ds['dataStreamId']
try:
data = service.users().dataSources().datasets().get(
userId='me',
dataSourceId=ds_id,
datasetId=f"{start_ns}-{end_ns}"
).execute()

if data.get('point'):
results[ds_id] = data['point']
print(f"✅ {ds_id}: {len(data['point'])} точек данных")

except Exception as e:
pass

return results

<h2 id="eksport-geolokatsii-iz-google-timeline">Экспорт геолокации из Google Timeline</h2>
def extract_location_history(access_token: str):
"""Извлечь историю местоположений из Google Maps Timeline"""
import requests
headers = {'Authorization': f'Bearer {access_token}'}
url = ('https://www.googleapis.com/drive/v3/files'
'?q=name+contains+"Location+History"&spaces=appDataFolder')
response = requests.get(url, headers=headers)
return response.json()


Извлечение токенов Google-аккаунта с устройства


bash
<h2 id="esli-adb-dostup-s-root-est-izvlech-tokeny-autentifikatsii">Если ADB-доступ с root есть — извлечь токены аутентификации</h2>
<h2 id="tokeny-hranyatsya-v-accountmanager">Токены хранятся в AccountManager</h2>

adb shell dumpsys account | grep -A 5 "com.google"

<h2 id="ili-cherez-bazu-dannyh-accountmanager">Или через базу данных AccountManager</h2>
adb pull /data/system/accounts_ce.db ./accounts_ce.db

<h2 id="analiz-bazy-dannyh-tokenov-sqlite">Анализ базы данных токенов (SQLite)</h2>
sqlite3 accounts_ce.db ".dump"
sqlite3 accounts_ce.db "SELECT * FROM accounts;"
sqlite3 accounts_ce.db "SELECT * FROM authtokens;"


> *✅ Google Location History — один из наиболее ценных форензических артефактов WearOS. Автоматически записывает перемещения с точностью до 10–20 метров, включает данные о длительности остановок в конкретных местах, способе передвижения (пешком, на машине) и посещённых заведениях. Хранится в облаке значительно дольше, чем на устройстве.*



8. Анализ ключевых артефактов: геолокация, биометрия, активность


Форензическая ценность WearOS определяется не технологиями извлечения, а качеством анализа артефактов. Именно в этом разделе данные превращаются в доказательства. WearOS генерирует три категории уникальных артефактов, которые отличают её от смартфона: непрерывная геолокация, биометрия и детальная история физической активности.

Геолокационные артефакты


bash
<h2 id="izvlechenie-gps-trekov-iz-google-fit-sqlite">Извлечение GPS-треков из Google Fit SQLite</h2>
sqlite3 health_data.db "
SELECT
datetime(start_time_millis/1000, 'unixepoch', 'localtime') AS start_time,
datetime(end_time_millis/1000, 'unixepoch', 'localtime') AS end_time,
data_type,
value
FROM data_point
WHERE data_type LIKE '%location%'
OR data_type LIKE '%activity%'
ORDER BY start_time_millis DESC
LIMIT 200;
"

<h2 id="konvertatsiya-v-gpx-dlya-vizualizatsii-marshruta">Конвертация в GPX для визуализации маршрута</h2>
python3 -c "
import sqlite3, xml.etree.ElementTree as ET
from datetime import datetime

conn = sqlite3.connect('health_data.db')
gpx = ET.Element('gpx', version='1.1')
trk = ET.SubElement(gpx, 'trk')
trkseg = ET.SubElement(trk, 'trkseg')

rows = conn.execute('''
SELECT start_time_millis, latitude, longitude, altitude
FROM gps_data ORDER BY start_time_millis
''').fetchall()

for ts, lat, lon, alt in rows:
trkpt = ET.SubElement(trkseg, 'trkpt',
lat=str(lat), lon=str(lon))
time_elem = ET.SubElement(trkpt, 'time')
time_elem.text = datetime.utcfromtimestamp(
ts/1000).strftime('%Y-%m-%dT%H:%M:%SZ')

ET.ElementTree(gpx).write('route.gpx')
print('GPX-маршрут сохранён: route.gpx')
"


Биометрические артефакты: пульс и стресс-ответ


python
<h2 id="biometric-analyzer-py-analiz-biometricheskih-dannyh-dlya-forenziki">biometric_analyzer.py — анализ биометрических данных для форензики</h2>

import sqlite3
import json
from datetime import datetime, timedelta

def analyze_heart_rate_events(db_path: str, event_time: str,
window_minutes: int = 60):
"""
Анализ пульса в окне вокруг события.
Позволяет выявить физиологический стресс-ответ.
event_time: 'YYYY-MM-DD HH:MM:SS'
"""
conn = sqlite3.connect(db_path)
event_dt = datetime.strptime(event_time, '%Y-%m-%d %H:%M:%S')
start_ms = int((event_dt - timedelta(minutes=window_minutes)).timestamp() * 1000)
end_ms = int((event_dt + timedelta(minutes=window_minutes)).timestamp() * 1000)

rows = conn.execute("""
SELECT
datetime(timestamp/1000, 'unixepoch', 'localtime') AS time,
heart_rate,
heart_rate_accuracy
FROM heart_rate_data
WHERE timestamp BETWEEN ? AND ?
ORDER BY timestamp
""", (start_ms, end_ms)).fetchall()

if not rows:
return {"error": "Нет данных пульса в указанном периоде"}

rates = [r[1] for r in rows if r[1] > 0]
event_ms = int(event_dt.timestamp() * 1000)

# Базовый пульс (30 мин до события)
baseline_rows = conn.execute("""
SELECT avg(heart_rate) FROM heart_rate_data
WHERE timestamp BETWEEN ? AND ?
AND heart_rate > 0
""", (start_ms, event_ms - 300000)).fetchone()

baseline = baseline_rows[0] if baseline_rows[0] else 0

# Пиковый пульс в 15 мин после события
peak_rows = conn.execute("""
SELECT max(heart_rate), datetime(timestamp/1000, 'unixepoch', 'localtime')
FROM heart_rate_data
WHERE timestamp BETWEEN ? AND ?
AND heart_rate > 0
""", (event_ms, event_ms + 900000)).fetchone()

return {
"event_time": event_time,
"baseline_hr_bpm": round(baseline, 1),
"peak_hr_bpm": peak_rows[0] if peak_rows else None,
"peak_hr_time": peak_rows[1] if peak_rows else None,
"delta_bpm": round((peak_rows[0] or 0) - baseline, 1),
"data_points": len(rates),
"all_readings": [(r[0], r[1]) for r in rows]
}

conn.close()


Анализ данных сна


bash
<h2 id="dannye-sna-tsennyy-hronologicheskiy-artefakt">Данные сна — ценный хронологический артефакт</h2>
<h2 id="pozvolyaet-ustanovit-kogda-lyog-spat-kogda-prosnulsya">Позволяет установить: когда лёг спать, когда проснулся,</h2>
<h2 id="kachestvo-sna-fazy-preryvaniya">качество сна (фазы), прерывания</h2>

sqlite3 health_data.db "
SELECT
datetime(start_time/1000, 'unixepoch', 'localtime') AS sleep_start,
datetime(end_time/1000, 'unixepoch', 'localtime') AS sleep_end,
round((end_time - start_time) / 3600000.0, 2) AS duration_hours,
sleep_stage,
CASE sleep_stage
WHEN 1 THEN 'Awake'
WHEN 2 THEN 'Sleep (generic)'
WHEN 3 THEN 'Out of bed'
WHEN 4 THEN 'Light sleep'
WHEN 5 THEN 'Deep sleep'
WHEN 6 THEN 'REM'
END AS stage_name
FROM sleep_sessions
ORDER BY start_time DESC;
"


Данные шагомера: опровержение или подтверждение алиби


python
def analyze_activity_for_alibi(db_path: str,
alibi_start: str, alibi_end: str):
"""
Анализ физической активности для проверки алиби.
Подозреваемый утверждает, что находился дома (алиби).
Проверяем: были ли характерные паттерны движения.
"""
conn = sqlite3.connect(db_path)
start_ms = int(datetime.strptime(
alibi_start, '%Y-%m-%d %H:%M:%S').timestamp() * 1000)
end_ms = int(datetime.strptime(
alibi_end, '%Y-%m-%d %H:%M:%S').timestamp() * 1000)

# Шаги по часам за период алиби
steps_query = conn.execute("""
SELECT
datetime(bucket_start/1000, 'unixepoch', 'localtime') AS hour,
SUM(steps) AS steps_in_hour
FROM step_count
WHERE bucket_start BETWEEN ? AND ?
GROUP BY strftime('%Y-%m-%d %H', datetime(bucket_start/1000, 'unixepoch'))
ORDER BY bucket_start
""", (start_ms, end_ms)).fetchall()

# Тип активности
activity_query = conn.execute("""
SELECT
datetime(start_time/1000, 'unixepoch', 'localtime') AS time,
activity_type,
duration_ms / 60000 AS duration_min
FROM activity_segments
WHERE start_time BETWEEN ? AND ?
AND activity_type != 3 -- исключить 'Still' (неподвижность)
ORDER BY start_time
""", (start_ms, end_ms)).fetchall()

total_steps = sum(r[1] for r in steps_query if r[1])
active_minutes = sum(r[2] for r in activity_query if r[2])

return {
"period": f"{alibi_start} — {alibi_end}",
"total_steps": total_steps,
"active_minutes": round(active_minutes),
"activity_events": len(activity_query),
"hourly_steps": [(r[0], r[1]) for r in steps_query],
"activities": [(r[0], r[1], r[2]) for r in activity_query]
}


> *✅ В одном из задокументированных дел (США, 2023) показания подозреваемого о том, что он «спал всю ночь», были опровергнуты данными умных часов: в период предполагаемого сна фиксировалась ходьба (2 300 шагов в 02:15–03:40) с сохранённым GPS-треком, выводившим за пределы дома.*



9. Форензика приложений WearOS: мессенджеры, платёжные системы, здоровье


Приложения, установленные на WearOS-устройстве, генерируют собственные артефакты, дополняющие системные данные. Мессенджеры содержат переписку, платёжные приложения — транзакции, медицинские приложения — данные о приёме медикаментов и физиологических показателях.

Мессенджеры на WearOS


WearOS-версии мессенджеров хранят сокращённый набор данных по сравнению с телефонными клиентами, но даже эти данные форензически ценны:

bash
<h2 id="telegram-wearos-baza-dannyh">Telegram WearOS — база данных</h2>
adb pull /data/data/org.telegram.messenger/databases/ ./telegram_db/

sqlite3 telegram_db/cache4.db "
SELECT
datetime(date, 'unixepoch', 'localtime') AS msg_time,
message,
from_id,
to_id,
media_type
FROM messages
ORDER BY date DESC
LIMIT 100;
"

<h2 id="whatsapp-wearos">WhatsApp WearOS</h2>
adb pull /data/data/com.whatsapp/databases/msgstore.db ./whatsapp_db/

sqlite3 whatsapp_db/msgstore.db "
SELECT
datetime(timestamp/1000, 'unixepoch', 'localtime') AS msg_time,
key_remote_jid AS contact,
data AS message_text,
status
FROM messages
ORDER BY timestamp DESC
LIMIT 100;
"


Google Pay / Wallet: форензика транзакций с часов


bash
<h2 id="google-pay-hranit-dannye-tranzaktsiy-lokalno">Google Pay хранит данные транзакций локально</h2>
adb pull /data/data/com.google.android.apps.walletnfcrel/databases/ ./gpay_db/

sqlite3 gpay_db/wallet.db "
SELECT
datetime(transaction_time/1000, 'unixepoch', 'localtime') AS time,
merchant_name,
amount,
currency,
last_four_digits,
transaction_type
FROM transactions
ORDER BY transaction_time DESC;
"

<h2 id="nfc-tranzaktsii-v-sistemnom-loge">NFC-транзакции в системном логе</h2>
adb shell dumpsys nfc | grep -i "transaction\|payment\|tap"


Samsung Health: наиболее детальная база биометрии


Samsung Health (на Galaxy Watch) хранит значительно более подробные биометрические данные, чем стандартный Google Fit:

bash
adb pull /data/data/com.samsung.android.health/databases/ ./samsung_health/

<h2 id="polnaya-shema-bazy-dannyh">Полная схема базы данных</h2>
sqlite3 samsung_health/health.db ".tables"

<h2 id="klyuchevye-tablitsy">Ключевые таблицы:</h2>
<h2 id="com-samsung-health-step-count-shagi-gps">com_samsung_health_step_count — шаги + GPS</h2>
<h2 id="com-samsung-health-heart-rate-puls-kazhduyu-minutu">com_samsung_health_heart_rate — пульс каждую минуту</h2>
<h2 id="com-samsung-health-sleep-detalizirovannye-fazy-sna">com_samsung_health_sleep — детализированные фазы сна</h2>
<h2 id="com-samsung-health-stress-uroven-stressa-hrv">com_samsung_health_stress — уровень стресса (HRV)</h2>
<h2 id="com-samsung-health-oxygen-saturation-spo2">com_samsung_health_oxygen_saturation — SpO2</h2>
<h2 id="com-samsung-health-blood-pressure-davlenie-galaxy-watch-6">com_samsung_health_blood_pressure — давление (Galaxy Watch 6+)</h2>

<h2 id="izvlech-dannye-pulsa-s-gps">Извлечь данные пульса с GPS</h2>
sqlite3 samsung_health/health.db "
SELECT
datetime(start_time/1000, 'unixepoch', 'localtime') AS time,
heart_rate,
latitude,
longitude,
accuracy
FROM com_samsung_health_heart_rate
WHERE latitude IS NOT NULL
ORDER BY start_time DESC
LIMIT 500;
"


Приложения для мониторинга медикаментов


bash
<h2 id="medication-reminder-prilozheniya-hranyat-dannye-o-priyome-lekarstv">Medication reminder приложения хранят данные о приёме лекарств</h2>
<h2 id="forenzicheski-znachimo-v-delah-svyazannyh-s-otravleniyami-ili-peredozirovkoy">(форензически значимо в делах, связанных с отравлениями или передозировкой)</h2>

adb shell pm list packages | grep -i "medication\|health\|pill\|reminder"

<h2 id="tipichnye-puti-dannyh">Типичные пути данных</h2>
adb pull /data/data/com.medisafe.android.client/databases/ ./medisafe/
adb pull /data/data/com.roundhealth.roundhealth/databases/ ./roundhealth/


> *⚠️ Данные здоровья в приложениях WearOS могут содержать особые категории персональных данных согласно GDPR и 152-ФЗ. Обращайтесь с биометрическими данными с повышенным уровнем осторожности и документируйте правовое основание для их обработки.*



10. Преодоление защиты: шифрование, PIN, биометрия и Trusted Environments


Защита WearOS 2026 значительно усложнилась по сравнению с предыдущими поколениями. Понимание архитектуры защиты позволяет выбрать методологически правильный подход к конкретному устройству.

Архитектура защиты WearOS 4.x


text
Уровни защиты WearOS 4.x (2024–2026):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Уровень 1: PIN/Пароль/Паттерн
└─ Используется для производства ключей CE хранилища

Уровень 2: Биометрия (оптический датчик запястья)
└─ Биометрическое разблокирование в AFU-состоянии
└─ НЕ используется для производства ключей (только аутентификация)

Уровень 3: Trusted Execution Environment (TEE)
└─ ARM TrustZone — изолированная среда выполнения
└─ Keymaster / KeyMint — управление ключами

Уровень 4: Dedicated Security Element (DSE)
└─ Titan M2 (Pixel Watch 3) — отдельный чип безопасности
└─ Knox Vault (Galaxy Watch 6/7) — отдельный процессор безопасности
└─ Ключи шифрования физически изолированы от основного процессора
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


Методы преодоления PIN-защиты


Словарная атака через ADB — применима при отсутствии счётчика попыток или при его обнулении:

bash
<h2 id="proverka-nalichiya-ogranicheniya-na-popytki">Проверка наличия ограничения на попытки</h2>
adb shell getprop persist.lockscreen.maxattempts

<h2 id="bruteforce-cherez-adb-input-tolko-pri-otklyuchyonnom-rate-limiting">Bruteforce через ADB input (только при отключённом rate-limiting)</h2>
<h2 id="ostorozhno-prevyshenie-popytok-factory-reset-na-bolshinstve-ustroystv">ОСТОРОЖНО: превышение попыток → Factory Reset на большинстве устройств!</h2>

<h2 id="bezopasnaya-proverka-odnogo-pin">Безопасная проверка одного PIN</h2>
adb shell input text "1234"
adb shell input keyevent 66 # Enter
adb shell dumpsys deviceidle | grep "locked"

<h2 id="pin-kody-iz-naibolee-chasto-ispolzuemyh-po-statistike">PIN-коды из наиболее часто используемых (по статистике):</h2>
<h2 id="1234-0000-1111-1212-7777-1004-2000-4444-2222-6969">1234, 0000, 1111, 1212, 7777, 1004, 2000, 4444, 2222, 6969</h2>


NAND mirroring — создание резервной копии памяти перед каждой попыткой PIN позволяет «обнулять» счётчик попыток. Требует физического доступа к eMMC через ISP:

nand
Mirroring для обхода счётчика попыток:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. Создать ISP-образ /data раздела (до первой попытки)
2. Попробовать PIN через ADB
3. Если неверный — восстановить ISP-образ (обнуление счётчика)
4. Повторять с новым PIN
Применимость: eMMC-устройства без Titan M2/Knox Vault
НЕ применимо: счётчик попыток в Titan M2 hardware-protected


Titan M2 и Knox Vault: аппаратные ограничения


Titan M2 (Pixel Watch 3) и Knox Vault (Galaxy Watch 7) реализуют hardware-enforced throttling — замедление между попытками физически на уровне чипа безопасности. NAND mirroring бессилен против этой защиты:

titan
M2 Anti-Bruteforce (Pixel Watch 3):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Попытки 1-5: без задержки
Попытки 6-10: 30 секунд между попытками
Попытки 11-20: 30 минут между попытками
Попытки 21-30: 1 час между попытками
После 30: Factory Reset или постоянная блокировка
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Ключевое: счётчик хранится в Titan M2, NAND mirroring не помогает


Форензически доступные данные без PIN (BFU-состояние)


bash
<h2 id="dazhe-bez-pin-forenzicheski-dostupny">Даже без PIN форензически доступны:</h2>

<h2 id="1-sistemnaya-informatsiya-iz-de-hranilischa">1. Системная информация из DE-хранилища</h2>
adb shell getprop | grep -E "(model|build|serial|brand)"

<h2 id="2-spisok-ustanovlennyh-prilozheniy-ne-trebuet-razblokirovki">2. Список установленных приложений (не требует разблокировки)</h2>
adb shell pm list packages

<h2 id="3-sistemnye-logi-ogranichennyy-dostup">3. Системные логи (ограниченный доступ)</h2>
adb shell logcat -d -t 500

<h2 id="4-informatsiya-o-seti">4. Информация о сети</h2>
adb shell dumpsys wifi | head -100
adb shell dumpsys bluetooth | head -100

<h2 id="5-dannye-iz-de-hranilischa-ne-zaschischeny-pin">5. Данные из DE-хранилища (не защищены PIN)</h2>
adb pull /data/system/packages.xml ./packages.xml # список приложений с путями


> *💡 При исследовании устройства с неизвестным PIN — начните с облачной форензики. Если аккаунт Google доступен, данные из Google Fit, Location History и Drive могут содержать всю необходимую информацию без необходимости взлома устройства.*



11. Продвинутые техники: реконструкция удалённых данных и timeline-анализ


Реконструкция удалённых данных и построение временно́й шкалы событий — высший уровень форензики WearOS. Именно на этом этапе разрозненные артефакты складываются в связную картину, позволяющую ответить на ключевые вопросы расследования: где был, что делал, с кем взаимодействовал.

Реконструкция удалённых записей SQLite


SQLite — стандартная база данных для хранения данных приложений в Android/WearOS. При удалении записей SQLite не всегда немедленно перезаписывает занятые страницы, оставляя восстановимые данные.

python
<h2 id="sqlite-recovery-py-rekonstruktsiya-udalyonnyh-zapisey">sqlite_recovery.py — реконструкция удалённых записей</h2>
<h2 id="trebuet-pip-install-sqliteparse">Требует: pip install sqliteparse</h2>

import struct
import os

def extract_sqlite_freelist(db_path: str) -> list:
"""
Извлечь данные из свободных страниц SQLite (freelist).
Содержат удалённые, но ещё не перезаписанные записи.
"""
PAGE_SIZE = 4096 # Стандартный размер страницы SQLite
recovered = []

with open(db_path, 'rb') as f:
# Читаем заголовок SQLite (первые 100 байт)
header = f.read(100)
if header[:16] != b'SQLite format 3\x00':
return {"error": "Не является файлом SQLite"}

# Размер страницы из заголовка
page_size = struct.unpack('>H', header[16:18])[0]
if page_size == 1:
page_size = 65536

# Первая страница freelist
freelist_trunk = struct.unpack('>I', header[32:36])[0]
freelist_count = struct.unpack('>I', header[36:40])[0]

print(f"Размер страницы: {page_size} байт")
print(f"Страниц в freelist: {freelist_count}")

# Читаем данные из freelist-страниц
f.seek(0, 2)
file_size = f.tell()
num_pages = file_size // page_size

for page_num in range(1, num_pages + 1):
f.seek((page_num - 1) * page_size)
page_data = f.read(page_size)
# Поиск ASCII/UTF-8 строк в удалённых страницах
strings = extract_strings_from_page(page_data, min_length=8)
if strings:
recovered.extend([(page_num, s) for s in strings])

return recovered

def extract_strings_from_page(data: bytes, min_length: int = 8) -> list:
"""Извлечь читаемые строки из бинарных данных страницы"""
result = []
current = []
for byte in data:
if 32 <= byte < 127: # Printable ASCII
current.append(chr(byte))
else:
if len(current) >= min_length:
result.append(''.join(current))
current = []
return result


Инструмент Autopsy для форензического анализа WearOS


Autopsy (sleuthkit.org/autopsy) — открытая форензическая платформа с поддержкой Android-образов:

bash
<h2 id="podgotovka-obraza-wearos-dlya-autopsy">Подготовка образа WearOS для Autopsy</h2>
<h2 id="1-sozdat-obraz-diska-cherez-adb-ili-apparatnye-metody">1. Создать образ диска через ADB или аппаратные методы</h2>
adb shell "dd if=/dev/block/sda18 | gzip" | dd of=wearos_userdata.img.gz

<h2 id="2-raspakovat-obraz">2. Распаковать образ</h2>
gunzip wearos_userdata.img.gz

<h2 id="3-otkryt-v-autopsy">3. Открыть в Autopsy:</h2>
<h2 id="new-case-add-data-source-disk-image-or-vm-file">New Case → Add Data Source → Disk Image or VM File</h2>
<h2 id="vybrat-wearos-userdata-img">Выбрать wearos_userdata.img</h2>
<h2 id="vklyuchit-moduli-android-analyzer-keyword-search-timeline">Включить модули: Android Analyzer, Keyword Search, Timeline</h2>

<h2 id="4-autopsy-avtomaticheski-izvlekaet">4. Autopsy автоматически извлекает:</h2>
<h2 id="sms-i-mms-esli-est-sim-karta">- SMS и MMS (если есть SIM-карта)</h2>
<h2 id="kontakty-i-istoriya-zvonkov">- Контакты и история звонков</h2>
<h2 id="brauzernaya-istoriya">- Браузерная история</h2>
<h2 id="gps-artefakty">- GPS артефакты</h2>
<h2 id="bazy-dannyh-prilozheniy">- Базы данных приложений</h2>


Построение форензической временно́й шкалы (Timeline)


python
<h2 id="timeline-builder-py-obedinenie-artefaktov-v-edinuyu-vremennu-yu-shkalu">timeline_builder.py — объединение артефактов в единую временну́ю шкалу</h2>

import sqlite3
from datetime import datetime
import json

class WearOSTimeline:
"""Построение форензической временно́й шкалы из нескольких источников"""

def __init__(self):
self.events = []

def add_heart_rate_events(self, db_path: str):
"""Добавить значимые события пульса (резкие изменения)"""
conn = sqlite3.connect(db_path)
rows = conn.execute("""
SELECT timestamp, heart_rate FROM heart_rate_data
WHERE heart_rate > 0 ORDER BY timestamp
""").fetchall()

prev_hr = None
for ts, hr in rows:
if prev_hr and abs(hr - prev_hr) > 25: # Резкое изменение > 25 bpm
self.events.append({
"timestamp": ts,
"time_str": datetime.utcfromtimestamp(
ts/1000).strftime('%Y-%m-%d %H:%M:%S'),
"source": "heart_rate",
"type": "spike" if hr > prev_hr else "drop",
"value": hr,
"delta": hr - prev_hr,
"description": f"Пульс: {prev_hr} → {hr} bpm"
})
prev_hr = hr
conn.close()

def add_location_events(self, db_path: str):
"""Добавить ключевые точки маршрута"""
conn = sqlite3.connect(db_path)
rows = conn.execute("""
SELECT timestamp, latitude, longitude, accuracy
FROM gps_data WHERE accuracy < 50
ORDER BY timestamp
""").fetchall()

for ts, lat, lon, acc in rows:
self.events.append({
"timestamp": ts,
"time_str": datetime.utcfromtimestamp(
ts/1000).strftime('%Y-%m-%d %H:%M:%S'),
"source": "gps",
"type": "location",
"value": {"lat": lat, "lon": lon, "acc": acc},
"description": f"Координаты: {lat:.6f}, {lon:.6f} (±{acc}м)"
})
conn.close()

def add_activity_events(self, db_path: str):
"""Добавить смены типа активности"""
conn = sqlite3.connect(db_path)
rows = conn.execute("""
SELECT start_time, activity_type, duration_ms
FROM activity_segments
ORDER BY start_time
""").fetchall()

activity_names = {0:'Unknown', 7:'Walking', 8:'Running',
1:'Bicycle', 3:'Still', 4:'Vehicle', 5:'Tilting'}
for ts, act, dur in rows:
self.events.append({
"timestamp": ts,
"time_str": datetime.utcfromtimestamp(
ts/1000).strftime('%Y-%m-%d %H:%M:%S'),
"source": "activity",
"type": "activity_change",
"value": act,
"description": f"Активность: {activity_names.get(act, act)} "
f"({round(dur/60000, 1)} мин)"
})
conn.close()

def export_sorted(self, output_file: str = "timeline.json"):
"""Экспорт временно́й шкалы в хронологическом порядке"""
sorted_events = sorted(self.events, key=lambda x: x["timestamp"])
with open(output_file, 'w', encoding='utf-8') as f:
json.dump(sorted_events, f, ensure_ascii=False, indent=2)
print(f"✅ Timeline: {len(sorted_events)} событий → {output_file}")
return sorted_events


> *💡 Форензическая временна́я шкала WearOS особенно эффективна при корреляции с другими источниками доказательств: видеозаписями камер наблюдения, банковскими транзакциями, CDR (детализацией звонков). Точные временны́е метки биометрических событий позволяют однозначно установить присутствие человека в конкретном месте в конкретный момент.*



12. Инструменты форензики WearOS: сравнение и практическое применение


Профессиональный рынок форензических инструментов для WearOS находится в активном развитии. В 2026 году большинство ведущих платформ добавили специализированную поддержку носимых устройств, хотя полнота извлечения существенно уступает работе со смартфонами.

Коммерческие форензические платформы


ИнструментПроизводительWearOS поддержкаСильные стороныСлабые стороны
Cellebrite UFEDCellebriteДа (с v7.50)Широкая база устройств, автоматизацияВысокая стоимость, BFU-ограничения
OXYGEN Forensic DetectiveOxygenДа (с v15.2)Детальный анализ приложений, облакоОграниченная поддержка WearOS 4.x
MSAB XRYMSABОграниченноНадёжность извлеченияСлабая поддержка WearOS-специфики
Magnet AXIOMMagnetДаКорреляция с телефономТребует полного образа
Belkasoft EvidenceBelkasoftОграниченноАнализ SQLite артефактовНет поддержки аппаратных методов

Открытые форензические инструменты


bash
<h2 id="autopsy-sleuthkit-bazovyy-forenzicheskiy-analiz-obraza">Autopsy + SleuthKit — базовый форензический анализ образа</h2>
<h2 id="sayt-sleuthkit-org-autopsy">Сайт: sleuthkit.org/autopsy</h2>
<h2 id="ustanovka">Установка:</h2>
sudo apt install autopsy sleuthkit

<h2 id="aleapp-android-logs-events-and-protobuf-parser">ALEAPP — Android Logs Events And Protobuf Parser</h2>
<h2 id="spetsializiruetsya-na-android-artefaktah-vklyuchaya-wearos">Специализируется на Android артефактах, включая WearOS</h2>
<h2 id="repozitoriy-github-com-abrignoni-aleapp">Репозиторий: github.com/abrignoni/ALEAPP</h2>
pip install iLeappForensics
python3 aleapp.py -t tar -i ./wearos_backup.tar -o ./aleapp_output/

<h2 id="adb-extractor-avtomatizirovannoe-izvlechenie-cherez-adb">ADB Extractor — автоматизированное извлечение через ADB</h2>
<h2 id="github-com-thomaspatzke-adb-extractor">github.com/thomaspatzke/adb-extractor</h2>
python3 adb_extractor.py --device <serial> --output ./extracted/

<h2 id="andriller-nabor-instrumentov-dlya-android-forenziki">ANDRILLER — набор инструментов для Android форензики</h2>
<h2 id="github-com-den4uk-andriller">github.com/den4uk/andriller</h2>
pip install andriller
andriller


Cellebrite UFED для WearOS: практические возможности


cellebrite
UFED 7.x — возможности для WearOS (2026):
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
ЛОГИЧЕСКОЕ ИЗВЛЕЧЕНИЕ (AFU, PIN известен):
✅ Данные здоровья (Google Fit, Samsung Health)
✅ GPS-треки и история местоположений
✅ Установленные приложения и их данные
✅ Системные логи и настройки
✅ Уведомления (кэшированные)
✅ NFC/платёжные данные (частично)

ФИЗИЧЕСКОЕ ИЗВЛЕЧЕНИЕ (с root/разблокованным bootloader):
✅ Полный образ разделов
✅ Данные удалённых приложений
✅ Восстановление удалённых файлов (ограниченно)
✅ Полный SQLite-анализ

ОБЛАЧНОЕ ИЗВЛЕЧЕНИЕ (с токеном аккаунта):
✅ Google Fit вся история
✅ Google Location History
✅ Google Pay транзакции
✅ Drive/Photos (при наличии)

НЕ ИЗВЛЕКАЕТСЯ (Titan M2 / Knox Vault):
❌ CE-хранилище в BFU состоянии
❌ Ключи шифрования из Secure Element
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━


ALEAPP: специализированный анализ Android/WearOS артефактов


bash
<h2 id="aleapp-analiziruet-izvlechyonnye-dannye-i-generiruet-html-otchyot">ALEAPP анализирует извлечённые данные и генерирует HTML-отчёт</h2>
<h2 id="s-sistematizirovannymi-artefaktami">с систематизированными артефактами</h2>

<h2 id="zapusk-analiza-tar-arhiva-izvlechyonnyh-dannyh">Запуск анализа tar-архива извлечённых данных</h2>
python3 aleapp.py \
--type tar \
--input ./wearos_extracted.tar \
--output ./aleapp_report/ \
--artifacts health gps calls sms accounts

<h2 id="aleapp-avtomaticheski-parsit">ALEAPP автоматически парсит:</h2>
<h2 id="google-fit-bazy-dannyh">- Google Fit базы данных</h2>
<h2 id="samsung-health-dannye">- Samsung Health данные</h2>
<h2 id="gps-artefakty-iz-raznyh-istochnikov">- GPS артефакты из разных источников</h2>
<h2 id="dannye-akkauntov-google">- Данные аккаунтов Google</h2>
<h2 id="istoriyu-uvedomleniy">- Историю уведомлений</h2>
<h2 id="bluetooth-wifi-istoriyu-podklyucheniy">- Bluetooth/WiFi историю подключений</h2>

<h2 id="rezultat-html-otchyot-s-tablitsami-kartami-vremenno-y-shkaloy">Результат: HTML-отчёт с таблицами, картами, временно́й шкалой</h2>
firefox aleapp_report/index.html


> *💡 При выборе между коммерческим и открытым инструментом ориентируйтесь на задачу: коммерческие платформы (Cellebrite, OXYGEN) быстрее и автоматизированнее, но открытые инструменты (Autopsy + ALEAPP) дают больший контроль над процессом и лучше подходят для сложных нестандартных случаев.*



13. Типичные ошибки при исследовании WearOS-устройств


Ошибки в форензике носимых устройств стоят дороже, чем ошибки в других видах цифровой криминалистики: данные часто уникальны, не воспроизводимы после перехода в BFU, а суд не признаёт доказательства, полученные с нарушением процедуры.

Ошибка 1: Нарушение RF-изоляции — разрешить удалённое стирание


Самая дорогостоящая ошибка. Владелец через Google Find My Device или Samsung Find My Mobile может удалённо стереть данные на подключённых часах. Один момент WiFi/LTE подключения к сети — и данные уничтожены необратимо. Защита: немедленная RF-изоляция — первое действие при любом контакте с устройством.

Ошибка 2: Перезагрузка часов в AFU-состоянии


Разряженное устройство «вроде бы нужно зарядить» — интуитивная реакция, уничтожающая доступ к CE-хранилищу. После перезагрузки устройство переходит в BFU, CE ключ из памяти удаляется. Данные зашифрованы и без PIN недоступны. Защита: зарядка без перезагрузки через специализированные RF-прозрачные зарядные решения.

Ошибка 3: Игнорирование облачных данных


Эксперт часами пытается преодолеть PIN-защиту устройства, не зная, что Google Location History за три года с полными GPS-треками доступна через судебный запрос к Google в течение 10–14 дней. Облачные данные часто превосходят локальные по объёму и глубине истории.

Ошибка 4: Неверная временна́я зона при анализе


WearOS хранит временны́е метки в UTC миллисекундах Unix. Приложения и сервисы могут использовать локальное время или UTC в зависимости от реализации. Неучёт разницы часовых поясов при анализе даёт ошибку в привязке событий ко времени — критично при проверке алиби с точностью до минуты.

bash
<h2 id="vsegda-fiksiruyte-timezone-ustroystva">Всегда фиксируйте timezone устройства</h2>
adb shell settings get system time_zone
<h2 id="naprimer-europe-moscow-utc-3">Например: Europe/Moscow (UTC+3)</h2>

<h2 id="pri-analize-sqlite-vsegda-yavno-ukazyvayte-timezone">При анализе SQLite всегда явно указывайте timezone:</h2>
<h2 id="datetime-timestamp-1000-unixepoch-localtime-ispolzuet-sistemnyy-timezone">datetime(timestamp/1000, &#039;unixepoch&#039;, &#039;localtime&#039;) — использует системный timezone</h2>
<h2 id="datetime-timestamp-1000-unixepoch-utc">datetime(timestamp/1000, &#039;unixepoch&#039;) — UTC</h2>


Ошибка 5: Запуск нестандартных инструментов без создания образа


Запуск форензических инструментов напрямую на живом устройстве без предварительного создания форензического образа изменяет состояние файловой системы — время доступа к файлам (atime), системные логи, кэши. Это нарушает доказательную силу: защита в суде поставит под сомнение любые «находки» на изменённом устройстве.

Ошибка 6: Недокументирование отрицательных результатов


«Данных не обнаружено» — это тоже форензический вывод, требующий обоснования: какие источники проверялись, какими инструментами, в каком состоянии было устройство. Отчёт, в котором написано только «данных нет», без описания процесса проверки — не профессиональный форензический документ.

> *⚠️ Наиболее распространённая причина признания форензических доказательств недопустимыми в суде — нарушение цепочки хранения доказательств и ненадлежащая документация процедуры извлечения. Документируйте каждый шаг, даже если результат отрицательный.*



14. FAQ: 12 горячих вопросов о форензике умных часов


Q 01 Какие данные WearOS наиболее ценны в криминалистическом расследовании?


A Три категории данных обладают наибольшей доказательной силой: непрерывная геолокация (GPS-треки с шагом в секунды — устанавливает местонахождение точнее, чем CDR сотового оператора); биометрический стресс-ответ (резкое учащение пульса в конкретный момент времени может быть скоррелировано с событием); данные активности (шаги, тип движения) — позволяют опровергнуть или подтвердить алиби о нахождении дома или в конкретном месте.

Q 02 Можно ли восстановить данные WearOS после Factory Reset?


A В большинстве случаев — нет при современном шифровании. Factory Reset уничтожает ключи шифрования CE-хранилища — данные остаются на флеш-памяти, но без ключей расшифровки физически нечитаемы. Исключения: данные, синхронизированные в облако до сброса (Google Fit, Location History), сохраняются в облаке и доступны через запрос к Google; некоторые метаданные в DE-хранилище могут сохраниться.

Q 03 Насколько точны GPS-данные умных часов как доказательство?


A GPS в WearOS-устройствах обеспечивает точность 3–15 метров при хорошем сигнале. Дополнительные источники локализации (WiFi, Bluetooth, сотовые сети) увеличивают погрешность до 50–300 метров. Для судебного использования важно задокументировать: тип источника координат (GPS vs network), значение accuracy из метаданных, наличие/отсутствие облачности и других факторов, влияющих на точность GPS в конкретный день.

Q 04 Что делать, если умные часы и телефон синхронизированы?


A Телефон — приоритетная цель для параллельного форензического исследования. WearOS синхронизирует данные с компаньон-приложением на смартфоне (Google Wear OS App, Samsung Galaxy Wearable), которое хранит дублирующий набор данных. В ряде случаев на телефоне сохраняются данные, уже удалённые с часов. Всегда исследуйте оба устройства при наличии.

Q 05 Как установить, что данные с часов не были изменены?


A Доказательная сила определяется процедурой: создание верифицированного образа (dd + SHA-256 хеш до и после), работа исключительно с копией образа, документация всех инструментов и версий ПО. Если образ не создавался и работа велась напрямую с устройством — доказательная сила существенно снижена. Для судебного использования: хранение исходного устройства в опечатанном виде как «мастер-копии».

Q 06 Возможна ли форензика WearOS без специализированных инструментов?


A Базовый уровень — да. ADB + SQLite browser + Excel для анализа данных — достаточно для логического извлечения и анализа ключевых артефактов при наличии PIN и AFU-состоянии. Профессиональные инструменты (Cellebrite, OXYGEN) ускоряют работу и автоматизируют анализ, но не открывают принципиально недоступные данные. Аппаратные методы (JTAG, ISP, Chip-Off) требуют специализированного оборудования.

Q 07 Каков правовой порядок получения данных от Google по WearOS?


A Для российских следователей: данные Google доступны через MLAT (Договор о взаимной правовой помощи) между Россией и США — процесс занимает от нескольких недель до нескольких месяцев. Для срочных запросов Google имеет механизм аварийного раскрытия данных при угрозе жизни. Для корпоративных расследований с согласия пользователя: Google Takeout или прямой API-доступ с OAuth-токеном.

Q 08 Как форензически значима информация об уведомлениях на часах?


A Высоко значима. WearOS кэширует уведомления от всех приложений смартфона, синхронизированных с часами. В кэше уведомлений могут содержаться: фрагменты текста сообщений из мессенджеров, входящие звонки с именами контактов, уведомления приложений (банки, такси, доставка). Это позволяет восстановить коммуникационный контекст даже если смартфон недоступен.

Q 09 Что такое «companion device» форензика и почему она важна?


A Companion Device Forensics — параллельное исследование смартфона, с которым синхронизированы часы. Google Wear OS и Samsung Galaxy Wearable на смартфоне создают собственные базы данных с зеркальными данными часов. Кроме того, смартфон логирует Bluetooth-подключения к часам — это формирует дополнительную доказательную временну́ю шкалу.

Q 10 Как обнаружить попытку уничтожения доказательств с WearOS?


A Признаки намеренного уничтожения данных: Factory Reset по данным из persist-раздела (логи сброса); отключение синхронизации непосредственно перед изъятием; выход из Google-аккаунта (разрывает синхронизацию); физическое повреждение устройства. Google-сервисы логируют выход из аккаунта и отключение синхронизации с временными метками — это доступно через судебный запрос.

Q 11 Какая версия WearOS наиболее сложна для форензического исследования?


A WearOS 4.x с Titan M2 (Pixel Watch 3, 2024–2026) — наиболее защищённая конфигурация: Titan M2 hardware-protected throttling делает PIN-брутфорс нереалистичным (годы при 4-значном PIN); ключи CE-хранилища физически изолированы в Titan M2; Chip-Off не помогает — ключи хранятся вне основной памяти. Путь: облачная форензика через Google-аккаунт или PIN от подозреваемого.

Q 12 Каковы перспективы форензики WearOS в ближайшие годы?


A Две противоположные тенденции. Данных становится больше и они богаче: ЭКГ, анализ крови (неинвазивный глюкоз), расширенный SpO2, детекция аномалий сна — всё это создаёт новые форензически ценные артефакты. Одновременно защита ужесточается: распространение Secure Element, шифрование по умолчанию, аппаратный anti-bruteforce делают устройства без согласия владельца практически непреодолимыми. Будущее форензики WearOS — облачная и компаньон-форензика, а не взлом устройства.



15. Чек-лист: полное форензическое исследование WearOS-устройства


Структурированный алгоритм форензического исследования WearOS от изъятия до составления отчёта. Применяется в рамках уголовного расследования или корпоративного расследования при наличии надлежащих правовых оснований.

Блок A: Изъятие и первичная обработка (на месте)


- [ ] Зафиксировать состояние устройства (включено/выключено, заряд батареи)
- [ ] Сфотографировать устройство до любых действий (минимум 5 ракурсов)
- [ ] Составить акт изъятия с серийным номером, моделью, временем, местом
- [ ] Немедленно поместить в RF-экранирующий пакет (клетку Фарадея)
- [ ] Если устройство включено и разблокировано (AFU) — сохранить это состояние
- [ ] НЕ нажимать кнопки, НЕ касаться экрана
- [ ] Обеспечить зарядку без нарушения RF-изоляции при необходимости
- [ ] Задокументировать timezone устройства (если экран виден)

Блок B: Идентификация и документирование


- [ ] Определить модель, производителя, версию WearOS
- [ ] Зафиксировать серийный номер (IMEI при наличии SIM)
- [ ] Определить тип памяти (eMMC vs UFS) по модели
- [ ] Определить наличие Secure Element (Titan M2 — Pixel Watch 3+; Knox Vault — Galaxy Watch 6+)
- [ ] Зафиксировать состояние шифрования: `adb shell getprop ro.crypto.state`
- [ ] Зафиксировать версию Android: `adb shell getprop ro.build.version.release`
- [ ] Создать SHA-256 хеш устройства в текущем состоянии (по возможности)

Блок C: Логическое извлечение (AFU + ADB)


- [ ] Установить ADB-соединение через WiFi: `adb connect IP:5555`
- [ ] Принять запрос авторизации ADB на устройстве (если появится)
- [ ] Выполнить `adb bugreport` — системный отчёт
- [ ] Получить список приложений: `adb shell pm list packages -f`
- [ ] Выполнить ADB backup основных приложений
- [ ] Извлечь базы данных Google Fit: `adb pull /data/data/com.google.android.apps.fitness/`
- [ ] Извлечь базы данных Samsung Health (для Galaxy Watch)
- [ ] Извлечь данные GPS: `adb shell dumpsys location`
- [ ] Снять логи: `adb shell logcat -d > system_log.txt`
- [ ] Извлечь `dumpsys` сервисов: battery, wifi, bluetooth, nfc

Блок D: Анализ артефактов


- [ ] Установить временну́ю зону устройства для корректного анализа
- [ ] Проанализировать базы данных Google Fit / Samsung Health в SQLite
- [ ] Извлечь GPS-треки и конвертировать в GPX
- [ ] Проанализировать данные пульса на предмет резких изменений
- [ ] Проанализировать данные активности (шаги, тип движения по часам)
- [ ] Проанализировать данные сна (время засыпания/пробуждения)
- [ ] Проанализировать кэш уведомлений
- [ ] Проанализировать NFC и платёжные данные (Google Pay)
- [ ] Восстановить удалённые записи из SQLite freelist (при необходимости)

Блок E: Облачная форензика


- [ ] Определить привязанный Google-аккаунт устройства
- [ ] Подготовить запрос в Google (MLAT или с согласия владельца)
- [ ] Запросить Google Location History за релевантный период
- [ ] Запросить данные Google Fit
- [ ] Запросить историю транзакций Google Pay
- [ ] Запросить данные Wear OS Cloud Backup
- [ ] При наличии согласия — выполнить Google Takeout

Блок F: Аппаратные методы (при необходимости)


- [ ] Принять решение об использовании аппаратных методов (только при отсутствии программного доступа)
- [ ] Идентифицировать тип памяти (eMMC / UFS) и SoC по схеме платы
- [ ] Выбрать метод: JTAG (если тестовые точки доступны) / ISP / Chip-Off
- [ ] Создать физический образ с верификацией хеша
- [ ] Попытаться расшифровать образ (только при наличии ключей из CE-хранилища)

Блок G: Построение временно́й шкалы и отчётность


- [ ] Объединить артефакты из всех источников в единую временну́ю шкалу
- [ ] Скоррелировать данные WearOS с другими доказательствами по делу
- [ ] Составить форензический отчёт по стандарту (введение, методология, находки, выводы)
- [ ] Задокументировать все отрицательные результаты (что проверялось и не найдено)
- [ ] Приложить хеши всех извлечённых файлов
- [ ] Сохранить исходное устройство в опечатанном виде

> *✅ Форензическое исследование WearOS, выполненное по этому чек-листу, обеспечивает: полноту охвата доступных источников данных; документально подтверждённую цепочку хранения доказательств; воспроизводимость результатов при независимой экспертизе; соответствие требованиям допустимости доказательств в судебном процессе.*



16. Заключение


Форензика WearOS в 2026 году — это дисциплина на пересечении мобильной криминалистики, IoT-безопасности и облачной форензики. Умные часы стали хранилищем данных, которых нет нигде больше — непрерывного биометрического и геолокационного потока, отражающего физическое состояние и перемещения человека с точностью, недостижимой для любого другого устройства.

Главное противоречие 2026 года: чем ценнее данные, тем надёжнее их защита. Titan M2 и Knox Vault сделали физический взлом современных WearOS-устройств практически нереалистичным для форензики. Ответ профессионального сообщества — смещение от «взлома устройства» к «экосистемной форензике»: облачные данные Google, компаньон-приложения на смартфоне, данные WiFi-роутеров и других IoT-устройств дополняют или заменяют недоступные локальные данные.

Ключевые принципы, которые нужно вынести из этого руководства: RF-изоляция раньше всего — одна секунда соединения с сетью может уничтожить все доказательства; AFU vs BFU определяет доступность данных — никогда не перезагружайте включённое устройство без понимания последствий; облако часто богаче устройства — Google Location History хранит данные дольше и полнее, чем локальное хранилище; документирование важнее извлечения — доказательства без надлежащей цепочки хранения не имеют юридической силы.

Следите за развитием форензики носимых устройств через профессиональные ресурсы: SANS DFIR Blog (dfir.blog), Forensic Focus (forensicfocus.com), Journal of Digital Forensics, Security and Law, выступления на конференциях DFRWS и Cellebrite APAC Summit.

Пять правил форензика WearOS


1. Изоляция — первое действие — RF-пакет раньше любых других шагов; удалённое стирание необратимо

2. Состояние определяет метод — AFU открывает CE-хранилище; BFU закрывает; никогда не меняй состояние случайно

3. Облако — обязательный источник — Google Location History часто содержит больше, чем само устройство

4. Хеши и документация — основа доказательной силы — без верифицированного образа и цепочки хранения данные не убедят суд

5. Временны́е метки — основа анализа — всегда фиксируй timezone, конвертируй в UTC, верифицируй через независимые источники