
📋 Оглавление
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 атаке на основную память.*
3. Правовые основы: допустимость доказательств и порядок изъятия
Форензическое исследование без правовой базы — не исследование, а потенциальное уголовное дело против самого эксперта. Доказательства, полученные с нарушением процессуальных норм, не только теряют юридическую силу, но и могут поставить под угрозу всё расследование.
Правовое основание для доступа к 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 JTAG | eMMC-устройства | Обходит ОС, не шифрование |
| 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 logcat | ADB включён | Нет | Низкая (только логи) | Средняя |
| ADB backup | ADB включён, AFU | Нет | Средняя (приложения) | Высокая |
| ADB pull /data | ADB включён, 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 History | Geolocation 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 UFED | Cellebrite | Да (с v7.50) | Широкая база устройств, автоматизация | Высокая стоимость, BFU-ограничения |
| OXYGEN Forensic Detective | Oxygen | Да (с v15.2) | Детальный анализ приложений, облако | Ограниченная поддержка WearOS 4.x |
| MSAB XRY | MSAB | Ограниченно | Надёжность извлечения | Слабая поддержка WearOS-специфики |
| Magnet AXIOM | Magnet | Да | Корреляция с телефоном | Требует полного образа |
| Belkasoft Evidence | Belkasoft | Ограниченно | Анализ 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, 'unixepoch', 'localtime') — использует системный timezone</h2>
<h2 id="datetime-timestamp-1000-unixepoch-utc">datetime(timestamp/1000, 'unixepoch') — 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, верифицируй через независимые источники