
Статья
1. Введение: что Bluetooth-история говорит следователю
2. Базовые концепции: paired, detected, connected — три разных состояния
3. Методология и правовые основы Bluetooth-форензики
4. Android: архитектура хранения Bluetooth-артефактов
5. Android: анализ bt_config.conf — список сопряжённых устройств
6. Android: bluetooth.db — история соединений и переданных файлов
7. Android: системные логи и events.db — временны́е метки соединений
8. iOS: архитектура и пути к Bluetooth-артефактам
9. iOS: ledevices.paired.db — база сопряжённых BLE-устройств
10. iOS: MobileBluetooth.devices.plist — классические Bluetooth-устройства
11. iOS: ledevices.other.db — «виденные» устройства в радиусе
12. Корреляция: связать Bluetooth-данные с другими артефактами
13. Инструменты: ADB, SQLite3, UFED, Cellebrite, Magnet AXIOM, iLEAPP
14. FAQ: 12 горячих вопросов о Bluetooth-форензике
15. Чек-лист: Bluetooth-форензика мобильного устройства за один сеанс
16. Заключение и теги
1. Введение: что Bluetooth-история говорит следователю
Bluetooth-логи — одна из наиболее недооценённых категорий мобильных артефактов. Большинство форензических расследований фокусируется на сообщениях, геолокации и браузерной истории. Между тем история Bluetooth-соединений способна ответить на вопросы, которые другие источники не закрывают.
Bluetooth-соединения часто фигурируют в расследованиях широкого спектра дел: от ДТП до установления местонахождения. Конкретные вопросы, на которые отвечает Bluetooth-форензика:
Установление факта присутствия. Телефон видел конкретное Bluetooth-устройство — значит, телефон находился в пределах ~10 метров от него. Если это устройство установлено (наушники конкретного человека, автомобильная аудиосистема, умные часы), это привязывает телефон к месту или человеку.
Отвлечение за рулём. Доказать, был ли водитель отвлечён перед смертельным ДТП — распространённая задача. Был ли телефон подключён к автомобилю по Bluetooth? Можно ли это подтвердить? Данные об «обнаруженных» Bluetooth-устройствах позволяют установить приблизительное местонахождение подозреваемого в конкретный момент времени.
Реконструкция событий. Время сопряжения, время обнаружения, время последнего соединения — вместе они создают временну́ю шкалу взаимодействия с конкретными устройствами.
Идентификация периферии. MAC-адреса сопряжённых устройств (наушников, колонок, умных часов, медицинских приборов) могут связать телефон с конкретным человеком или местом.
| Вопрос расследования | Источник Bluetooth-данных |
|---|---|
| Был ли телефон в конкретном автомобиле? | bt_config.conf / MobileBluetooth.plist |
| Когда произошло сопряжение с устройством? | ledevices.paired.db / btopp.db |
| Какие устройства находились рядом, но не были сопряжены? | ledevices.other.db |
| Передавались ли файлы по Bluetooth? | btopp.db (Android OBEX Push) |
| Когда последний раз телефон подключался к устройству? | Метки last_seen / последнего соединения |
> *💡 Статья рассчитана на специалистов по цифровой форензике, следователей, работающих с мобильными устройствами, и студентов программ информационной безопасности. Все описанные методы применяются только в образовательных целях.*
2. Базовые концепции: paired, detected, connected — три разных состояния
Прежде чем анализировать артефакты, важно разграничить три состояния Bluetooth-взаимодействия — они хранятся в разных местах и несут разную доказательную нагрузку.
Paired (сопряжено)
Сопряжение — это процесс установки доверенного соединения между двумя устройствами. Требует активных действий пользователя: подтверждения PIN-кода или нажатия кнопки на обоих устройствах. После сопряжения устройства запоминают друг друга и подключаются автоматически.
Что это значит для форензики: пользователь намеренно инициировал связь с этим устройством. Имя устройства, MAC-адрес и (часто) временна́я метка первого сопряжения хранятся долгосрочно.
Detected / Seen (обнаружено)
Устройство попало в радиус действия Bluetooth (обычно до 10 метров) и было зафиксировано в процессе сканирования. Никакого пользовательского взаимодействия не требуется — пассивное обнаружение происходит автоматически, пока Bluetooth включён.
Что это значит для форензики: телефон находился рядом с этим устройством. Если устройство идентифицировано, это фиксирует присутствие телефона в определённом месте или рядом с определённым человеком. Устройство может быть обнаружено, а затем впоследствии сопряжено. Это полезно, поскольку указывает время отключения устройства — когда сопряжение прекратилось.
Connected (подключено)
Активное соединение — обмен данными между сопряжёнными устройствами. Требует, чтобы оба устройства находились в радиусе и были включены. Временны́е метки подключения хранятся в нескольких местах.
text
Иерархия хранимости:
Paired — хранится долго (до явного удаления сопряжения)
Connected — временна́я метка последнего подключения
Detected — ротируется по мере поступления новых записей
BLE vs. Classic Bluetooth
Современные устройства используют два режима:
Bluetooth Classic (BR/EDR) — для аудио (наушники, автомобиль), файловых передач (OBEX). Требует явного сопряжения. Дальность — до 10–100 м в зависимости от класса.
Bluetooth Low Energy (BLE) — для IoT-устройств, фитнес-трекеров, смарт-устройств, AirTag, AirPods. Меньше энергопотребление, иначе хранится. iOS хранит BLE-устройства отдельно от Classic в разных базах данных.
3. Методология и правовые основы Bluetooth-форензики
Принципы форензически корректного исследования
Форензика мобильных устройств строится на четырёх принципах ACPO (Association of Chief Police Officers), принятых как международный стандарт:
1
. Не изменять цифровые данные на изъятом устройстве
2. Если изменение неизбежно — задокументировать, обосновать,
подписать ответственным лицом
3. Все действия с устройством и данными документируются
и могут быть воспроизведены независимым экспертом
4. Ответственный за расследование несёт полную ответственность
за соблюдение процедур
Порядок действий при получении устройства
text
Шаг 1: Изоляция устройства
Поместить в клетку Фарадея или режим «в самолёте»
Предотвратить удалённое уничтожение данных (Find My, Android Find)
Задокументировать состояние: включено/выключено, уровень заряда
Шаг 2: Документирование внешнего состояния
Фотофиксация устройства и состояния экрана
Запись IMEI, модели, версии iOS/Android
Фиксация времени изъятия (для корреляции с UTC-временем в логах!)
Шаг 3: Извлечение данных
Выбор метода (см. раздел по инструментам)
Создание образа и верификация хэша (MD5, SHA-256)
Шаг 4: Анализ только на копии
Все операции — только на скопированных данных
Оригинальный образ хранится нетронутым
Важное: вопрос часовых поясов
Предполагалось, что временны́е метки будут в UTC — большинство баз данных и plist-файлов используют UTC. Однако для некоторых Bluetooth-файлов это оказалось не так.
Это критически важно: неправильная интерпретация временно́го пояса смещает всю временну́ю шкалу на несколько часов. Всегда:
- Фиксировать временну́ю зону устройства в момент изъятия
- Сверять найденные временны́е метки с известными событиями для верификации
- Проверять, используется ли формат Unix timestamp, Apple Cocoa timestamp или ISO 8601
4. Android: архитектура хранения Bluetooth-артефактов
Форензические артефакты Bluetooth на Android хранят ценные метаданные, касающиеся соединений устройств, истории сопряжения, журналов коммуникации и информации об обменянных файлах. Эксперты цифровой форензики могут использовать эту информацию для реконструкции Bluetooth-активности на Android-устройстве.
Ключевые пути к Bluetooth-артефактам Android
text
Основные файлы:
/data/misc/bluedroid/bt_config.conf
→ Список всех сопряжённых устройств (MAC, имена, метаданные)
/data/misc/bluedroid/bt_config.bak
→ Резервная копия bt_config.conf (может содержать
удалённые сопряжения!)
/data/data/com.android.bluetooth/databases/bluetooth.db
→ SQLite-база с историей и ОБМЕН файлами (btopp.db)
/data/misc/bluedroid/btsnoop_hci.log
→ Низкоуровневый HCI-снифф (если включена отладка)
Содержит необработанные BT-пакеты
Вспомогательные файлы:
/data/misc/bluetooth/
→ Вспомогательные конфигурации некоторых производителей
/data/system/users/0/settings_secure.xml
→ Имя Bluetooth-адаптера телефона, видимость
Изменения в новых версиях Android
Задача отслеживания Bluetooth-соединений на Android-устройствах становится всё сложнее с новыми версиями ОС. Более старые Android-системы хранили обширные данные в доступных файлах, таких как `/data/com.android.connectivity.metrics/databases/events.db`, которые более не доступны в последних версиях. Этот сдвиг существенно затруднил прямой доступ к логам, отслеживающим Bluetooth, NFC, USB и другие типы соединений.
android
9 и ниже:
/data/com.android.connectivity.metrics/databases/events.db
→ Содержал подробные временны́е метки всех Bluetooth-событий
→ В Android 10+ этот файл более не создаётся
Android 10+:
Большинство событийных данных переместилось в системные
логи (logcat), которые не являются персистентными и
перезаписываются при перезагрузке
Практический вывод: на современных Android-устройствах
bt_config.conf + bluetooth.db — основные персистентные источники.
На устройствах до Android 10 — дополнительно events.db.
Требования к извлечению
Файлы Bluetooth-артефактов на Android хранятся в защищённом разделе `/data`. Для их извлечения необходимо:
text
Вариант A: Root-доступ к устройству
adb root && adb pull /data/misc/bluedroid/bt_config.conf
Вариант B: Коммерческий форензический инструмент
UFED (Cellebrite), Magnet AXIOM, OXYGEN Forensic Detective
Используют собственные методы обхода защиты
Вариант C: Производственный режим (EDL, Qualcomm QDLOAD)
Для устройств на чипах Qualcomm — полное извлечение flash
Требует специализированного оборудования
Вариант D: Резервная копия ADB (ограниченный результат)
adb backup com.android.bluetooth
Может дать btopp.db, но не bt_config.conf
5. Android: анализ bt_config.conf — список сопряжённых устройств
`bt_config.conf` — главный источник информации о сопряжённых устройствах на Android. Помимо MAC-адресов сопряжённых устройств, он предоставляет их стандартные или назначенные пользователем имена, а также временны́е метки первого сопряжения с устройством.
Структура файла
bt_config.conf — текстовый INI-файл. Каждое сопряжённое устройство представлено отдельной секцией:
ini
[Adapter]
Address = AA:BB:CC:DD:EE:FF # MAC-адрес самого телефона
Name = Samsung Galaxy S23 # Bluetooth-имя телефона
DevClass = 5243908
DiscoveryTimeout = 120
Timestamp = 1705000000 # UNIX timestamp первого использования BT
# ВНИМАНИЕ: это НЕ время сопряжения конкретного устройства!
[00:1A:7D:DA:71:11] # MAC-адрес сопряжённого устройства
Timestamp = 1705412783 # UNIX timestamp
Name = AirPods Pro # Имя устройства
DevClass = 2360344 # Класс устройства (кодирует тип)
LinkKeyType = 4
PinLength = 0
LinkKey = A1B2C3D4E5F6... # Ключ шифрования сопряжения (форензически ценен)
[B8:27:EB:12:34:56]
Timestamp = 1703876543
Name = Nissan Rogue Audio # Автомобиль
DevClass = 786432 # Класс = автомобильная аудиосистема
...
[E8:D0:3C:AA:BB:CC]
Timestamp = 1706100234
Name = Mi Band 8 # Смарт-браслет
DevClass = 7936
...
Декодирование DevClass
DevClass — числовое поле, кодирующее тип Bluetooth-устройства по стандарту Bluetooth SIG:
python
def decode_devclass(devclass: int) -> str:
"""Декодировать DevClass в читаемый тип устройства."""
major_class = (devclass >> 8) & 0x1F
classes = {
0x01: "Computer",
0x02: "Phone",
0x03: "Networking",
0x04: "Audio/Video", # наушники, колонки, автомобиль
0x05: "Peripheral", # клавиатуры, мыши
0x06: "Imaging", # принтеры, сканеры
0x07: "Wearable", # умные часы, фитнес
0x08: "Toy",
0x09: "Health", # медицинские приборы
}
return classes.get(major_class, f"Unknown (0x{major_class:02X})")
<h2 id="primery">Примеры:</h2>
<h2 id="2360344-audio-video-naushniki-kolonki">2360344 → Audio/Video (наушники/колонки)</h2>
<h2 id="786432-audio-video-avtomobilnaya-audiosistema">786432 → Audio/Video (автомобильная аудиосистема)</h2>
<h2 id="5243908-phone">5243908 → Phone</h2>
<h2 id="7936-wearable">7936 → Wearable</h2>Расшифровка UNIX timestamp
python
from datetime import datetime, timezone
def parse_bt_timestamp(ts_str: str) -> str:
"""Конвертировать UNIX timestamp из bt_config.conf в UTC."""
ts = int(ts_str)
dt = datetime.fromtimestamp(ts, tz=timezone.utc)
return dt.strftime("%Y-%m-%d %H:%M:%S UTC")
<h2 id="primer">Пример:</h2>
<h2 id="1705412783-2024-01-16-14-46-23-utc">"1705412783" → "2024-01-16 14:46:23 UTC"</h2>Предупреждение: timestamp секции [Adapter]
Timestamp, найденный в начале файла bt_config.conf, указывает не на момент установки Bluetooth-соединения, а на время первичной настройки устройства. Убедитесь, что ваш инструмент не интерпретирует это как временну́ю метку подключения.
Форензический анализ bt_config.conf — Python-скрипт
python
#!/usr/bin/env python3
"""
bt_config_parser.py — парсинг Android bt_config.conf
Извлекает список сопряжённых устройств с временны́ми метками.
"""
import re
import sys
from datetime import datetime, timezone
DEVCLASS_MAP = {
0x01: "Computer", 0x02: "Phone", 0x03: "Networking",
0x04: "Audio/Video", 0x05: "Peripheral", 0x06: "Imaging",
0x07: "Wearable", 0x08: "Toy", 0x09: "Health Device",
}
def decode_class(val: int) -> str:
major = (val >> 8) & 0x1F
return DEVCLASS_MAP.get(major, f"Other (0x{major:02X})")
def parse_bt_config(filepath: str):
with open(filepath, encoding="utf-8", errors="replace") as f:
content = f.read()
# Разбить по секциям
sections = re.split(r'\n(?=\[)', content)
devices = []
for section in sections:
lines = section.strip().splitlines()
if not lines:
continue
header = lines[0].strip("[]")
# Пропустить секцию [Adapter] (это сам телефон)
if header == "Adapter":
continue
# Проверить, что заголовок — MAC-адрес
if not re.match(r'^([0-9A-Fa-f]{2}:){5}[0-9A-Fa-f]{2}$', header):
continue
props = {}
for line in lines[1:]:
if "=" in line:
k, _, v = line.partition("=")
props[k.strip()] = v.strip()
ts_raw = props.get("Timestamp", "")
ts_human = ""
if ts_raw.isdigit():
ts_human = datetime.fromtimestamp(
int(ts_raw), tz=timezone.utc
).strftime("%Y-%m-%d %H:%M:%S UTC")
devclass_raw = props.get("DevClass", "0")
devclass_human = ""
if devclass_raw.isdigit():
devclass_human = decode_class(int(devclass_raw))
devices.append({
"mac": header,
"name": props.get("Name", ""),
"timestamp": ts_human,
"devclass": devclass_human,
"linkkey": props.get("LinkKey", "")[:8] + "..."
if props.get("LinkKey") else "",
})
return devices
if __name__ == "__main__":
path = sys.argv[1] if len(sys.argv) > 1 else "bt_config.conf"
devices = parse_bt_config(path)
print(f"\n{'MAC-адрес':<20} {'Временна́я метка':<25} "
f"{'Тип':<20} {'Имя'}")
print("-" * 85)
for d in sorted(devices, key=lambda x: x["timestamp"], reverse=True):
print(f"{d['mac']:<20} {d['timestamp']:<25} "
f"{d['devclass']:<20} {d['name']}")
print(f"\nВсего сопряжённых устройств: {len(devices)}")
bt_config.bak — скрытый резервный источник
bash
<h2 id="vazhno-rezervnaya-kopiya-mozhet-soderzhat-udalyonnye-sopryazheniya">ВАЖНО: резервная копия может содержать удалённые сопряжения!</h2>
<h2 id="esli-polzovatel-udalil-ustroystvo-iz-spiska-bt">Если пользователь удалил устройство из списка BT —</h2>
<h2 id="ono-mozhet-ostatsya-v-bak-fayle">оно может остаться в .bak файле</h2>
<h2 id="sravnit-bt-config-conf-i-bt-config-bak">Сравнить bt_config.conf и bt_config.bak:</h2>
diff bt_config.conf bt_config.bak
<h2 id="ustroystva-prisutstvuyuschie-tolko-v-bak-udalyonnye-sopryazheniya">Устройства, присутствующие только в .bak — удалённые сопряжения</h2>6. Android: bluetooth.db — история соединений и переданных файлов
`bluetooth.db` — SQLite-база данных, содержащая детальную историю Bluetooth-соединений и OBEX-передач файлов. Перекрёстная ссылка данных из этого файла с bt_config.conf помогает определить, когда сопряжённые Bluetooth-устройства использовались.
Расположение и структура
text
/data/data/com.android.bluetooth/databases/bluetooth.db
/data/data/com.android.bluetooth/databases/btopp.db
(на некоторых версиях — отдельный файл для OBEX Push)
sql
-- Просмотр таблиц в bluetooth.db
sqlite3 bluetooth.db ".tables"
-- Обычные таблицы:
-- bthf_client_calls → история звонков через Bluetooth-гарнитуру
-- sdp → записи Service Discovery Protocol
-- btopp → OBEX Object Push (передача файлов)
-- Просмотр структуры таблицы btopp:
sqlite3 bluetooth.db ".schema btopp"
Анализ btopp — таблица передачи файлов OBEX
OBEX Push — протокол передачи файлов по Bluetooth. Каждая отправленная или принятая запись фиксируется в таблице btopp:
sql
-- Извлечь историю файловых передач
SELECT
_id,
datetime(timestamp/1000, 'unixepoch') AS transfer_time,
direction, -- 0=исходящий, 1=входящий
filename,
mimetype,
total_bytes,
current_bytes,
destination, -- MAC-адрес устройства
status -- 200=успешно, другие=ошибка/отмена
FROM btopp
ORDER BY timestamp DESC;
text
Пример вывода:
_id | transfer_time | dir | filename | bytes | destination | status
----+---------------------+-----+-------------------+---------+-------------------+-------
12 | 2026-01-15 14:22:31 | 0 | contract_draft.pdf| 2048000 | 00:1A:7D:DA:71:11 | 200
11 | 2026-01-14 09:15:44 | 1 | photo_001.jpg | 819200 | B8:27:EB:12:34:56 | 200
10 | 2026-01-12 18:03:12 | 0 | report_q4.xlsx | 1536000 | 00:1A:7D:DA:71:11 | 200
Форензическая ценность: можно доказать, что файл был передан с конкретного телефона на конкретное устройство (по MAC) в конкретное время.
Поиск записей звонков через Bluetooth-гарнитуру
sql
-- История входящих/исходящих звонков через BT-гарнитуру
-- (если хранится в bthf_client_calls)
SELECT
name,
number,
type, -- 0=исходящий, 1=входящий, 2=пропущенный
datetime(date/1000, 'unixepoch') AS call_time
FROM bthf_client_calls
ORDER BY date DESC
LIMIT 50;
7. Android: системные логи и events.db — временны́е метки соединений
На Android до версии 10 файл `events.db` содержал детальную событийную историю всех сетевых подключений.
events.db (Android 9 и ниже)
text
Путь:
/data/com.android.connectivity.metrics/databases/events.db
Таблица events содержит:
- тип события (Bluetooth On/Off, Connect, Disconnect, Pair)
- временну́ю метку (наносекунды от загрузки системы или Unix time)
- MAC-адрес участвующего устройства
- дополнительные параметры
sql
-- Анализ events.db для BT-событий (Android ≤ 9)
SELECT
datetime(time_ms/1000, 'unixepoch') AS event_time,
type,
uid,
data
FROM events
WHERE data LIKE '%bluetooth%'
OR type IN (1, 2, 3, 4) -- типы BT-событий, зависят от прошивки
ORDER BY time_ms DESC
LIMIT 100;
Системный logcat (волатильные данные)
Logcat — кольцевой буфер логов Android. При включённом устройстве содержит Bluetooth-события последних нескольких часов. После перезагрузки — очищается. Чрезвычайно ценен при «горячей» работе с устройством.
bash
<h2 id="izvlech-bluetooth-sobytiya-iz-logcat-na-vklyuchyonnom-ustroystve-s-adb">Извлечь Bluetooth-события из logcat (на включённом устройстве с ADB):</h2>
adb logcat -d -s "bt_btif" "bluetooth" "BluetoothAdapter" \
> bluetooth_logcat.txt
<h2 id="filtratsiya-po-klyuchevym-sobytiyam">Фильтрация по ключевым событиям:</h2>
adb logcat -d | grep -i "bluetooth" | grep -E "(connect|pair|bond|scan)"
<h2 id="sohranit-polnyy-logcat-dlya-analiza">Сохранить полный logcat для анализа:</h2>
adb logcat -d > full_logcat.txt
grep -i -E "(bluetooth|bt_)" full_logcat.txt > bt_logcat.txt
Исследования показали: в буфере событий можно обнаружить использование Bluetooth вплоть до 6 часов после произошедших событий. Специфический лог-файл Samsung предоставлял ценную информацию — имена переданных файлов, MAC-адреса сопряжённых устройств, количество переданных байт и временны́е метки.
HCI Snoop Log — низкоуровневый трафик
bash
<h2 id="hci-snoop-log-esli-vklyuchena-otladka-po-bluetooth">HCI snoop log (если включена отладка по Bluetooth):</h2>
/sdcard/btsnoop_hci.log
<h2 id="ili">или</h2>
/data/misc/bluedroid/btsnoop_hci.log
<h2 id="analiz-v-wireshark">Анализ в Wireshark:</h2>
<h2 id="otkryt-btsnoop-hci-log-avtomaticheski-raspoznayotsya-kak-bt-hci">Открыть btsnoop_hci.log → автоматически распознаётся как BT HCI</h2>
<h2 id="filtr-v-wireshark-dlya-sopryazheniy">Фильтр в Wireshark для сопряжений:</h2>
bthci_evt.code == 0x04 # Connection Complete
bthci_evt.code == 0x06 # Disconnection Complete
bthci_cmd.opcode == 0x0419 # Remote Name Request
HCI snoop log содержит полный поток Bluetooth HCI-команд и событий — это самый подробный источник, но он доступен только при включённой отладке Bluetooth и имеет ограниченный размер буфера.
8. iOS: архитектура и пути к Bluetooth-артефактам
iOS хранит Bluetooth-данные принципиально иначе, чем Android — несколько специализированных баз данных и plist-файлов вместо одного конфигурационного файла.
Ключевые пути к Bluetooth-артефактам iOS
text
Основные базы данных:
/private/var/containers/Shared/SystemGroup/<GUID>/Library/
Database/com.apple.MobileBluetooth.ledevices.paired.db
→ Сопряжённые BLE-устройства (AirPods, Apple Watch, и др.)
Database/com.apple.MobileBluetooth.ledevices.other.db
→ «Виденные» BLE-устройства (не сопряжённые)
/private/var/containers/Shared/SystemGroup/<GUID>/Library/
Preferences/com.apple.MobileBluetooth.devices.plist
→ ВСЕ Bluetooth-устройства: Classic + BLE, включая автомобили
Вспомогательные источники:
/private/var/mobile/Library/Logs/CrashReporter/
→ Crash-логи BT-стека при сбоях
Unified Logs (системный журнал iOS):
→ Записи com.apple.bluetooth subsystem
→ Доступен через idevicesyslog или форензические инструменты
Где находится GUID
GUID в пути — это идентификатор SystemGroup. Он уникален для каждого устройства. Форензические инструменты (Cellebrite, Magnet AXIOM) разрешают его автоматически. При ручном анализе:
bash
<h2 id="na-razblokirovannom-ustroystve-cherez-ssh-jailbreak">На разблокированном устройстве через SSH (jailbreak):</h2>
ls /private/var/containers/Shared/SystemGroup/ | grep -v "\.plist$"
<h2 id="ili-nayti-po-imeni-fayla">Или найти по имени файла:</h2>
find /private/var/containers/Shared/SystemGroup/ \
-name "com.apple.MobileBluetooth.*" 2>/dev/null
Методы извлечения iOS Bluetooth-данных
text
Тип извлечения Доступность BT-данных
───────────────────────────────────────────────────
iTunes Backup ❌ Не включает системные BT-базы
Logical (AFC) ❌ Нет доступа к SystemGroup
AFC2 / iBridge ⚠️ Только на старых устройствах
Full File System ✅ Полный доступ (требует exploit)
Checkm8 exploit ✅ Для A7–A11 (iPhone X и старше)
Bluetooth-ключи доступны даже при BFU (Before First Unlock) состоянии устройства — они относятся к классу защиты D (не зависят от пользовательского пароля). Это означает, что базовые BT-данные можно извлечь даже с заблокированного устройства при наличии соответствующего инструмента.
9. iOS: ledevices.paired.db — база сопряжённых BLE-устройств
iOS устройства поддерживают список BLE-устройств с низким энергопотреблением, которые могут подключаться к устройству пользователя — так называемые сопряжённые устройства. Они хранятся в базе данных `com.apple.MobileBluetooth.ledevices.paired.db`, в таблице PairedDevices. Эта таблица содержит список устройств, их имена, MAC-адреса и временны́е метки последнего обнаружения.
Анализ PairedDevices
sql
-- Открыть базу:
-- sqlite3 com.apple.MobileBluetooth.ledevices.paired.db
-- Просмотр структуры:
.tables
-- PairedDevices ZPAIREDDEVICES и другие варианты в зависимости от версии iOS
-- Основной запрос:
SELECT
ZADDRESS AS mac_address,
ZNAME AS device_name,
-- Временны́е метки в формате Apple Cocoa (секунды от 01.01.2001):
datetime(ZLASTSEEN + 978307200, 'unixepoch') AS last_seen_utc,
datetime(ZFIRSTPAIRED + 978307200, 'unixepoch') AS first_paired_utc,
ZDEVICETYPE AS device_type
FROM ZPAIREDDEVICES
ORDER BY ZLASTSEEN DESC;
Конвертация Apple Cocoa Timestamp
iOS использует Core Data timestamp: секунды от 1 января 2001 года (не от 1970, как Unix). Это частая причина ошибок интерпретации.
python
from datetime import datetime, timezone, timedelta
COCOA_EPOCH = datetime(2001, 1, 1, tzinfo=timezone.utc)
def cocoa_to_utc(cocoa_ts: float) -> str:
"""Конвертировать Apple Cocoa timestamp в UTC."""
dt = COCOA_EPOCH + timedelta(seconds=cocoa_ts)
return dt.strftime("%Y-%m-%d %H:%M:%S UTC")
<h2 id="primery">Примеры:</h2>
<h2 id="726000000-2024-01-04-04-00-00-utc">726000000 → 2024-01-04 04:00:00 UTC</h2>
<h2 id="0-0-2001-01-01-00-00-00-utc-nulevoe-znachenie">0.0 → 2001-01-01 00:00:00 UTC (нулевое значение)</h2>
<h2 id="63113904000-primerno-1000-01-01-yavno-nekorrektnoe">-63113904000 → примерно 1000-01-01 (явно некорректное)</h2>
<h2 id="proverka-esli-poluchaete-datu-do-2007-goda-vypusk-pervogo-iphone">Проверка: если получаете дату до 2007 года (выпуск первого iPhone) —</h2>
<h2 id="veroyatno-nevernaya-konvertatsiya-ili-povrezhdyonnye-dannye">вероятно, неверная конвертация или повреждённые данные</h2>Что рассказывают данные о типе устройства
sql
-- Анализ типов устройств в paired.db:
SELECT
ZNAME,
ZADDRESS,
ZDEVICETYPE,
-- Расшифровка типа на основе OUI MAC-адреса (первые 3 октета)
SUBSTR(ZADDRESS, 1, 8) AS oui
FROM ZPAIREDDEVICES;
-- Известные OUI в контексте iOS BT-форензики:
-- 00:00:00 — AirPods/Apple
-- F4:F1:5A — Apple Watch
-- 7C:04:D0 — Apple MagSafe
-- BC:9F:E4 — Beats headphones (Apple)
10. iOS: MobileBluetooth.devices.plist — классические Bluetooth-устройства
`com.apple.MobileBluetooth.devices.plist` отслеживает ВСЁ сопряжение Bluetooth — не только BLE-устройства. Именно здесь фигурируют автомобили. Если нужно доказать, что человек ехал с hands-free подключением в момент звонка или отправки сообщения — это первое место для поиска.
Структура plist-файла
xml
<!-- Упрощённый пример структуры com.apple.MobileBluetooth.devices.plist -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" ...>
<plist version="1.0">
<dict>
<!-- Каждое устройство — ключ = MAC-адрес -->
<key>00:1A:7D:DA:71:11</key>
<dict>
<key>Name</key>
<string>BMW iDrive Audio</string>
<key>BatteryLevel</key> <!-- если поддерживается -->
<integer>-1</integer>
<key>LastNameUpdate</key>
<real>726047823.5</real> <!-- Apple Cocoa timestamp -->
<key>PairedAt</key>
<real>720000000.0</real> <!-- Apple Cocoa timestamp -->
<key>ServiceNames</key> <!-- поддерживаемые профили BT -->
<array>
<string>Hands-Free Audio Gateway</string>
<string>Advanced Audio Distribution</string>
<string>Audio/Video Remote Control</string>
</array>
<key>DeviceClass</key>
<integer>786432</integer> <!-- то же кодирование, что в Android -->
</dict>
<key>F4:F1:5A:AA:BB:CC</key>
<dict>
<key>Name</key>
<string>Apple Watch Series 9</string>
...
</dict>
</dict>
</plist>
Парсинг plist в Python
python
#!/usr/bin/env python3
"""
ios_bt_plist_parser.py — парсинг MobileBluetooth.devices.plist
"""
import plistlib
import sys
from datetime import datetime, timezone, timedelta
COCOA_EPOCH = datetime(2001, 1, 1, tzinfo=timezone.utc)
def cocoa_ts(val) -> str:
if val is None or val == 0:
return "N/A"
dt = COCOA_EPOCH + timedelta(seconds=float(val))
return dt.strftime("%Y-%m-%d %H:%M:%S UTC")
def decode_class(val: int) -> str:
major = (val >> 8) & 0x1F
classes = {
1: "Computer", 2: "Phone", 3: "Network",
4: "Audio/Video", 5: "Peripheral", 6: "Imaging",
7: "Wearable", 8: "Toy", 9: "Health",
}
return classes.get(major, f"Other")
def parse_plist(path: str):
with open(path, "rb") as f:
data = plistlib.load(f)
devices = []
for mac, props in data.items():
if not isinstance(props, dict):
continue
devices.append({
"mac": mac,
"name": props.get("Name", ""),
"paired_at": cocoa_ts(props.get("PairedAt")),
"last_update": cocoa_ts(props.get("LastNameUpdate")),
"class": decode_class(props.get("DeviceClass", 0)),
"services": ", ".join(props.get("ServiceNames", [])),
})
return devices
if __name__ == "__main__":
path = sys.argv[1] if len(sys.argv) > 1 else \
"com.apple.MobileBluetooth.devices.plist"
devices = parse_plist(path)
print(f"\n{'MAC':<20} {'Имя':<25} {'Сопряжение':<25} {'Тип':<12} {'Профили'}")
print("-" * 110)
for d in sorted(devices, key=lambda x: x["paired_at"], reverse=True):
print(f"{d['mac']:<20} {d['name']:<25} {d['paired_at']:<25} "
f"{d['class']:<12} {d['services'][:40]}")
11. iOS: ledevices.other.db — «виденные» устройства в радиусе
`com.apple.MobileBluetooth.ledevices.other.db` — эта база данных логирует BLE-устройства с низким энергопотреблением, которые iOS-устройство обнаружило или с которыми оказалось в одном радиусе действия.
Это наиболее форензически интересная, но и наиболее сложная база: она содержит устройства, с которыми телефон не был сопряжён, но которые находились рядом.
Форензическое значение «виденных» устройств
Сценарии применения:
- Алиби / антиалиби. Если телефон «видел» специфическое устройство (например, AirTag конкретного человека или BT-маяк конкретного заведения) — это размещает телефон в конкретном месте.
- Хронология событий. Повторное появление одних и тех же MAC-адресов — паттерн, указывающий на регулярное присутствие рядом с определёнными людьми или объектами.
- Связь между устройствами. Телефон обвиняемого «видел» телефон потерпевшего — они находились в одном месте.
Структура и анализ
sql
-- Анализ ledevices.other.db
-- (структура таблицы аналогична paired.db, но без данных ключей)
SELECT
ZADDRESS AS mac_address,
ZNAME AS device_name,
datetime(ZLASTSEEN + 978307200, 'unixepoch') AS last_seen_utc,
datetime(ZFIRSTSEEN + 978307200, 'unixepoch') AS first_seen_utc,
ZRSSI AS signal_strength -- RSSI: чем меньше абс. значение, тем ближе
FROM ZDEVICES
ORDER BY ZLASTSEEN DESC
LIMIT 100;
RSSI как индикатор близости
RSSI (Received Signal Strength Indicator) — сила сигнала при обнаружении. Значения отрицательные: -40 означает очень близко (~1 м), -80 — далеко (~10 м).
python
def rssi_to_distance_estimate(rssi: int) -> str:
"""Грубая оценка расстояния по RSSI (зависит от окружения)."""
if rssi >= -50:
return "очень близко (<1 м)"
elif rssi >= -60:
return "близко (1–3 м)"
elif rssi >= -70:
return "средне (3–7 м)"
elif rssi >= -80:
return "далеко (7–15 м)"
else:
return "очень далеко (>15 м)"
> ⚠️ Значения RSSI ненадёжны для точного определения расстояния — они зависят от препятствий, материалов стен, ориентации устройств. Используйте как индикатор, не как доказательство конкретного расстояния.
Ротация MAC-адресов в BLE: важное ограничение
С iOS 14 Apple ввела рандомизацию MAC-адресов BLE: устройства в режиме «Resolvable Private Address» периодически меняют свой MAC-адрес. Это означает:
text
Если чужое устройство использует случайный MAC (большинство
современных смартфонов в режиме сканирования) — его появление
в ledevices.other.db будет записано под разными MAC-адресами.
Постоянные MAC-адреса имеют:
- AirPods и другие Apple-аксессуары
- Большинство Bluetooth Classic устройств
- IoT-устройства без рандомизации
- Старые смартфоны и автомобили
12. Корреляция: связать Bluetooth-данные с другими артефактами
Максимальная ценность Bluetooth-данных реализуется при корреляции с другими источниками.
Bluetooth + GPS/геолокация
text
Логика корреляции:
Если в 14:32 телефон был сопряжён с "BMW X5 Audio"
(автомобильная аудиосистема)
И в 14:31–15:47 GPS-трек фиксирует движение по маршруту
от точки A до точки B
→ Доказательство: человек ехал в автомобиле с работающим
Bluetooth-соединением по данному маршруту в данное время
Bluetooth + история звонков / SMS
sql
-- Корреляция: звонок и BT-подключение к автомобилю
-- (использовал ли телефон гарнитуру?)
-- Получить временны́е метки входящих звонков из call_history.db iOS
SELECT
datetime(Z_ZDATE + 978307200, 'unixepoch') AS call_time,
ZADDRESS AS number,
ZDURATION AS duration,
ZORIGINATED AS direction -- 0=входящий, 1=исходящий
FROM ZCALLRECORD
WHERE Z_ZDATE + 978307200 BETWEEN
strftime('%s','2026-01-15 14:00:00') AND
strftime('%s','2026-01-15 16:00:00');
-- Затем сверить временны́е метки со временем BT-подключения
-- к автомобилю из MobileBluetooth.devices.plist
Bluetooth + передача файлов
python
<h2 id="sopostavit-btopp-db-android-s-drugimi-svidetelstvami-peredachi-faylov">Сопоставить btopp.db (Android) с другими свидетельствами передачи файлов</h2>
def correlate_bt_file_transfer(btopp_records, mac_from_bt_config):
"""
Если MAC устройства из btopp.db совпадает с MAC
в bt_config.conf → передача подтверждена конкретному
идентифицированному устройству.
"""
for record in btopp_records:
mac = record['destination']
if mac in mac_from_bt_config:
device_name = mac_from_bt_config[mac]['name']
print(f"Файл '{record['filename']}' передан устройству "
f"'{device_name}' ({mac}) в {record['transfer_time']}")
Bluetooth + Unified Logs (iOS)
Unified Logs — централизованная система логирования iOS, содержащая детальные записи системных событий. Подсистема `com.apple.bluetooth` фиксирует все BT-события с наносекундной точностью.
bash
<h2 id="izvlechenie-unified-logs-s-ios-ustroystva-cherez-forenzicheskiy-instrument">Извлечение Unified Logs с iOS-устройства (через форензический инструмент</h2>
<h2 id="ili-na-zhivom-ustroystve-s-jailbreak">или на живом устройстве с jailbreak):</h2>
<h2 id="s-macos-cherez-idevice">С macOS через idevice:</h2>
idevicesyslog -u <UDID> | grep -i bluetooth > bt_unified_log.txt
<h2 id="analiz-konkretnogo-vremenno-go-diapazona">Анализ конкретного временно́го диапазона:</h2>
log show --predicate 'subsystem == "com.apple.bluetooth"' \
--start "2026-01-15 14:00:00" \
--end "2026-01-15 16:00:00" > bt_events.txt
13. Инструменты: ADB, SQLite3, UFED, Cellebrite, Magnet AXIOM, iLEAPP
Бесплатные инструменты для ручного анализа
ADB (Android Debug Bridge):
bash
<h2 id="poluchit-spisok-ustroystv">Получить список устройств:</h2>
adb devices
<h2 id="izvlech-bt-config-conf-trebuet-root">Извлечь bt_config.conf (требует root):</h2>
adb root
adb pull /data/misc/bluedroid/bt_config.conf ./
<h2 id="izvlech-bluetooth-db">Извлечь bluetooth.db:</h2>
adb pull /data/data/com.android.bluetooth/databases/bluetooth.db ./
<h2 id="poluchit-hci-snoop-log">Получить HCI snoop log:</h2>
adb pull /sdcard/btsnoop_hci.log ./
<h2 id="snyat-obraz-razdela-data-forenzicheski-korrektno">Снять образ раздела /data (форензически корректно):</h2>
adb shell "su -c 'dd if=/dev/block/by-name/userdata bs=4096'" > userdata.img
SQLite3 (CLI):
bash
<h2 id="bystryy-analiz-bt-bazy-dannyh">Быстрый анализ bt базы данных:</h2>
sqlite3 bluetooth.db <<EOF
.mode column
.headers on
SELECT datetime(timestamp/1000,'unixepoch') AS time,
filename, total_bytes, destination, status
FROM btopp ORDER BY timestamp DESC LIMIT 20;
EOF
DB Browser for SQLite (GUI): Бесплатный графический редактор SQLite. Открывает .db файлы, позволяет выполнять SQL-запросы, экспортировать в CSV. Незаменим для быстрого первичного анализа.
iLEAPP (iOS Logs, Events, And Plists Parser):
bash
<h2 id="besplatnyy-open-source-parser-ios-artefaktov">Бесплатный open-source парсер iOS-артефактов</h2>
<h2 id="github-com-abrignoni-ileapp">github.com/abrignoni/iLEAPP</h2>
pip install iLEAPP
ileapp -t fs -i /path/to/ios/extraction/ -o /output/report/
<h2 id="avtomaticheski-parsit">Автоматически парсит:</h2>
<h2 id="com-apple-mobilebluetooth-devices-plist">- com.apple.MobileBluetooth.devices.plist</h2>
<h2 id="ledevices-paired-db">- ledevices.paired.db</h2>
<h2 id="ledevices-other-db">- ledevices.other.db</h2>
<h2 id="generiruet-html-otchyot-s-tablitsami">- Генерирует HTML-отчёт с таблицами</h2>ALEAPP (Android Logs Events And Protobuf Parser):
bash
<h2 id="github-com-abrignoni-aleapp">github.com/abrignoni/ALEAPP</h2>
<h2 id="analog-ileapp-dlya-android-artefaktov">Аналог iLEAPP для Android-артефактов</h2>
<h2 id="parsit-bt-config-conf-i-bluetooth-db-avtomaticheski">Парсит bt_config.conf и bluetooth.db автоматически</h2>
python aleapp.py -t fs -i /path/to/android/extraction/ -o /output/
Коммерческие инструменты
| Инструмент | Производитель | BT-артефакты | Особенности |
|---|---|---|---|
| Cellebrite UFED + Physical Analyzer | Cellebrite | ✅ Полный парсинг Android + iOS | Промышленный стандарт, автоматическая корреляция |
| Magnet AXIOM | Magnet Forensics | ✅ Полный парсинг | Хорошая визуализация временно́й шкалы |
| OXYGEN Forensic Detective | Oxygen Forensics | ✅ Полный парсинг | Поддержка широкого спектра устройств |
| Belkasoft X | Belkasoft | ✅ bt_config.conf, bluetooth.db | Российский производитель |
В Belkasoft X профиль bt_config.conf отображается в окне Artifacts на вкладке Structure в разделе System files → bt_config.conf → Paired Bluetooth devices.
Верификация через Wireshark (btsnoop_hci.log)
1
. Открыть Wireshark
2. File → Open → выбрать btsnoop_hci.log
3. Wireshark автоматически распознаёт формат BTSnoop
4. Фильтры для анализа:
bthci_cmd — все HCI-команды
bthci_evt.code == 0x04 — Connection Complete
bthci_evt.code == 0x06 — Disconnection Complete
btatt — Bluetooth Attribute Protocol (BLE данные)
5. Statistics → Conversations → показывает все BT-пары
14. FAQ: 12 горячих вопросов о Bluetooth-форензике
Q 01 Можно ли получить историю BT без root на Android?
A Полный доступ к bt_config.conf и bluetooth.db требует root или коммерческого форензического инструмента с методами обхода защиты. Без root через ADB backup можно получить только данные некоторых приложений — системные BT-файлы недоступны. Исключение: если устройство изъято следственными органами, коммерческие инструменты (UFED) используют методы, не требующие предварительного root-доступа на поддерживаемых моделях.
Q 02 Что происходит с bt_config.conf при сбросе настроек Bluetooth?
A При сбросе настроек BT (не сбросе к заводским настройкам) bt_config.conf очищается от записей сопряжённых устройств. Однако bt_config.bak может содержать предыдущее состояние. Полный factory reset удаляет оба файла, но на уровне flash-памяти данные могут быть восстановимы при низкоуровневом извлечении — зависит от типа хранилища устройства.
Q 03 Насколько точны временны́е метки в BT-артефактах?
A Точность зависит от источника. Timestamp в bt_config.conf отражает момент первого сопряжения с секундной точностью. Временны́е метки в HCI snoop log — миллисекундные. Unified Logs iOS — наносекундные. Главная ошибка: неверная интерпретация временно́го пояса. Всегда верифицируйте временны́е метки по нескольким источникам с известными событиями.
Q 04 Можно ли по MAC-адресу в BT-логах идентифицировать конкретного человека?
A MAC-адрес идентифицирует устройство, не человека напрямую. Цепочка: MAC → модель устройства (по OUI) → серийный номер (при наличии у производителя) → владелец. На практике: MAC наушников у конкретного производителя с конкретным именем («AirPods Ивана»), найденный в логах телефона, — сильная косвенная улика, требующая подтверждения другими доказательствами.
Q 05 Как обнаружить попытку удаления BT-истории?
A Признаки: bt_config.conf существует, но пуст или содержит только секцию [Adapter] без устройств; bt_config.bak содержит данные, которых нет в bt_config.conf — удалённые устройства; несоответствие между временны́ми метками в разных источниках; присутствие устройства в ledevices.other.db (iOS), но отсутствие в paired.db при ожидаемом сопряжении.
Q 06 Что значит запись в ledevices.other.db без последующего сопряжения?
A Устройство оказалось в радиусе BT-сканирования, но пользователь не инициировал сопряжение. Форензически это означает пространственную близость, не взаимодействие. Ценность зависит от контекста: если это BT-маяк конкретного магазина, маркер на транспортном средстве или уникальный гаджет с известным MAC — это доказательство присутствия в конкретном месте.
Q 07 Работает ли рандомизация MAC на iOS так же, как на Android?
A iOS использует рандомизацию MAC для собственного сканирования в режиме Bluetooth advertising (когда iPhone сам сканируется другими). Однако внутри ledevices.other.db записываются обнаруженные ЧУЖИЕ устройства — их MACs. Если чужое устройство использует случайный MAC, он ротируется, и его записи будут под разными MAC в разные периоды. Apple-устройства между собой используют Identity Resolving Key (IRK) для разрешения рандомных MAC в стабильные идентификаторы.
Q 08 Можно ли по BT-логам доказать факт вождения?
A Доказать сопряжение несложно при наличии данных. Сложнее — установить временны́е метки конкретного подключения, если речь идёт о автомобиле. Для этого нужно исследовать множество файлов: время начала соединения, время активности и время завершения. Прямое доказательство требует корреляции BT-соединения с автомобилем, геолокационных данных и временны́х меток телефонных звонков или SMS.
Q 09 Что делать, если btsnoop_hci.log недоступен?
A HCI snoop log создаётся только при включённой отладке Bluetooth (Developer Options). На большинстве устройств, не находившихся в режиме разработчика, он отсутствует. В этом случае опирайтесь на bt_config.conf, bluetooth.db, Unified Logs и данные корреляции из других артефактов.
Q 10 Как интерпретировать записи с «нулевым» именем устройства?
A Безымянные записи (Name = "" или NULL) появляются при: обнаружении устройства без рассылки имени (Silent BLE device), неудавшемся сопряжении (MAC сохранён, имя не получено), устройствах, которые скрывают своё имя из соображений конфиденциальности. Для идентификации — OUI-поиск по первым трём октетам MAC и перекрёстный анализ с другими источниками.
Q 11 Влияет ли версия iOS/Android на полноту BT-артефактов?
A Существенно. Android 10+ убрал events.db — основной источник детальных временны́х меток. iOS 13+ изменила структуру ledevices-баз. Каждое обновление ОС потенциально меняет расположение и структуру артефактов. Всегда проверяйте актуальные ресурсы (josh hickman's test images, DFIR.pubpub.org) для конкретной версии ОС.
Q 12 Можно ли восстановить удалённые BT-записи из SQLite WAL-файла?
A WAL (Write-Ahead Log) — дополнительный файл SQLite, содержащий незакоммиченные транзакции. WAL-файлы также должны быть обработаны форензическим инструментом. На практике: если устройство было изъято быстро после удаления записей — WAL может содержать удалённые данные. Инструменты вроде SQLite Deleted Records Parser (SDRP) или встроенные возможности UFED/AXIOM анализируют WAL и свободные страницы SQLite для восстановления.
15. Чек-лист: Bluetooth-форензика мобильного устройства за один сеанс
Шаг 0: Подготовка и документирование
- ☐ Поместить устройство в клетку Фарадея / включить режим «в самолёте»
- ☐ Зафиксировать состояние, время изъятия, версию ОС, модель
- ☐ Создать образ и верифицировать хэш (SHA-256) до начала анализа
- ☐ Зафиксировать временну́ю зону устройства — критично для интерпретации меток
Android: основные артефакты
- ☐ Извлечь `/data/misc/bluedroid/bt_config.conf`
- ☐ Извлечь `/data/misc/bluedroid/bt_config.bak` (удалённые сопряжения!)
- ☐ Извлечь `/data/data/com.android.bluetooth/databases/bluetooth.db`
- ☐ Проверить наличие `btsnoop_hci.log` (если была отладка)
- ☐ На Android ≤ 9: проверить `/data/com.android.connectivity.metrics/databases/events.db`
- ☐ Запустить `adb logcat -d | grep -i bluetooth` на включённом устройстве
Android: анализ
- ☐ Запустить bt_config_parser.py → список сопряжённых с временны́ми метками
- ☐ Проверить bt_config.bak на записи, отсутствующие в bt_config.conf
- ☐ SQL-запрос к bluetooth.db → список файловых передач (btopp-таблица)
- ☐ Декодировать DevClass для каждого устройства
- ☐ OUI-поиск для MAC-адресов без имён
iOS: основные артефакты
- ☐ Найти GUID SystemGroup
- ☐ Извлечь `ledevices.paired.db`
- ☐ Извлечь `ledevices.other.db`
- ☐ Извлечь `com.apple.MobileBluetooth.devices.plist`
- ☐ Проверить наличие Unified Logs с BT-подсистемой
iOS: анализ
- ☐ SQL к ledevices.paired.db → список BLE-устройств с временны́ми метками
- ☐ Запустить ios_bt_plist_parser.py → классические BT-устройства (авто!)
- ☐ SQL к ledevices.other.db → «виденные» устройства (близость, место)
- ☐ Конвертировать все Apple Cocoa timestamps в UTC
- ☐ Верифицировать 2–3 временны́е метки по известным событиям
Корреляция и отчёт
- ☐ Сопоставить BT MAC-адреса с геолокационными данными
- ☐ Сопоставить время BT-подключений с историей звонков/SMS
- ☐ Для файловых передач: связать MAC получателя с именем из bt_config.conf
- ☐ Задокументировать все находки с указанием источника, пути к файлу, временно́й метки
16. Заключение и теги
Bluetooth-форензика — слой доказательств, который нередко упускается при анализе мобильных устройств, хотя именно он способен ответить на вопросы о местоположении, связях между людьми и передаче данных. Ключевое отличие от других форм мобильной форензики: Bluetooth-логи хранятся автономно от пользовательских действий и труднее поддаются целенаправленному удалению, чем переписка или история браузера.
Два главных практических вывода для специалистов: bt_config.bak — первое место для поиска «удалённой» истории сопряжений на Android; ledevices.other.db на iOS — недооценённый источник данных о пространственной близости телефона к конкретным людям и местам даже без сопряжения.
Направления для дальнейшего изучения: анализ Android Unified Protocol Buffer (UPBX) логов коннективности для Android 10+, исследование BT-артефактов в умных часах (Apple Watch, Samsung Galaxy Watch) как дополнительного источника, кросс-девайсная корреляция через AirTag и Find My Network.
> 🔍 Bluetooth-история — это не просто «к чему был подключён телефон». Это хронология близости: к каким устройствам, в какое время, как долго.