Сбор данных при изъятии устройств на российских границах в контексте СОРМ

2026-09-23 BARGHEST ~29 min

Как контакты и история вызовов покидают изъятый телефон через Bluetooth PBAP: изъятие на российской границе, исследованное с помощью MESH, рядом со сбором идентификаторов, относящимся к контексту СОРМ.

Атрибуция изображения: телефонные линии из Pix_telephone-lines-886146, автор zhrefch, передано в общественное достояние по Public Domain Dedication (CC0). Цифровая графика — SHOCKHAM.

Введение

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

В недавнем случае аналитик-форензик, проводивший удалённое исследование с помощью MESH, изучил телефон сразу после того, как правозащитник пересёк российскую границу, а его телефон был изъят и возвращён сотрудниками пограничного контроля и правоохранительных органов. Телефон находился в руках сотрудников несколько минут. MESH объединяет удалённый криминалистический сбор данных, анализ трафика и ручное исследование, и в этом случае расследование выявило в этом окне две различные модели поведения атакующих, соответствующие двум разным разведывательным целям:

Сбор идентификаторов. Активность, соответствующая чтению IMEI (*#06#), а затем настроек SIM-карты и мобильной сети. Так собираются идентификатор устройства (IMEI) и сведения о SIM-карте и сети.
Извлечение контактов и истории вызовов через злоупотребление PBAP. Включение Bluetooth, сопряжение с устройством и чтение журнала вызовов процессом Bluetooth по PBAP.

Второй модели посвящена большая часть этой статьи, потому что PBAP как скрытый канал извлечения редко ищут при расследовании криминалистической активности без согласия владельца, хотя соответствующая возможность существует в коммерческих инструментах (часть 6). Метод не нов. PBAP около двух десятилетий вытягивает телефонные книги по Bluetooth, и злоупотребление им годами обсуждалось в абстрактной форме, но мы не нашли ни одного задокументированного случая его использования как скрытого канала извлечения при реальном изъятии устройства, ни криминалистического описания следов, которые он после себя оставляет. Именно этот пробел, а не сам механизм, и закрывает эта статья. Но две модели лучше читать вместе: в контексте российского пограничного контроля извлечение контактов и истории вызовов владельца атакованного устройства, предположительно, представляет собой проверку на контакты с украинскими номерами (+380) и известными лицами, представляющими интерес, карту того, с кем общается правозащитник, тогда как сбор идентификаторов даёт селекторы, пригодные для перехвата на стороне сети (СОРМ).

Эта статья — об одном конкретном способе, с помощью которого история вызовов и контакты могут быть получены в такой ситуации: о профиле доступа к телефонной книге (Phone Book Access Profile, PBAP), стандартном профиле Bluetooth. PBAP был спроектирован для того, чтобы автомобиль мог показывать ваши контакты. Та же архитектура делает его почти идеальным каналом логического извлечения без использования специализированной криминалистической платформы вроде Мобильный криминалист: ему не нужны ни приложение на телефоне, ни ADB, ни root, ни доступ к файловой системе, ни постоянное USB-подключение. Привилегированное чтение журнала вызовов происходит внутри телефона и выполняется службой Bluetooth в Android от имени удалённого устройства. Модель доверия Bluetooth в Android — неидельная и действует на уровне устройства: сопряжённое периферийное устройство получает доверие для всех чувствительных профилей, зачастую без уведомления пользователя. Это годами критиковали как исследователи безопасности (Naveed et al. о некорректной привязке внешних устройств [2] и Xu et al. в работе BadBluetooth [1], показавшие, что сопряжённому устройству доверяют целиком, а не по профилям, и оно может добраться до чувствительных профилей без нового запроса), так и более широкие публикации о поверхности атаки Bluetooth (например, раскрытие BlueBorne [3]). Что добавляет эта статья — криминалистическую сторону: конкретные коррелируемые следы, которые PBAP-выгрузка оставляет на изъятом устройстве, и живое воспроизведение на актуальном стеке Android.

Изъятое устройство — Android-телефон с вендорскими доработками; его точная модель и сборка не раскрываются для защиты владельца. Устройство для воспроизведения — стоковый Pixel 8 (Android 17). Мы держим их раздельно и помечаем каждое утверждение, специфичное для вендора, потому что часть важного поведения в этом кейсе отрабатывает в собственном вендорском коде изъятого устройства. Однако основной путь PBAP теперь поставляется как модуль Google, так что один и тот же код работает на всех современных устройствах независимо от производителя.

Благодарности

Мы благодарим криминалистов, работающих над этими делами, и правозащитников, чьё согласие сделало публикацию этой работы возможной. Мы также благодарим команду MVT за возможность использовать MVT для сбора данных по ADB через MESH в ходе криминалистического расследования.

Это исследование проведено нашими партнёрами-криминалистами и BARGHEST.

Часть 1: Что такое PBAP и какой код читает ваш журнал вызовов

Наша команда часто критикует Bluetooth. Мы стараемся помнить об этой предвзятости, поскольку регулярно находим уязвимости в реализациях Bluetooth, но чтобы понять, чем опасен PBAP, сначала нужно увидеть его легитимный сценарий использования.

Головное устройство автомобиля хочет показать вам ваши контакты и последние вызовы на своём экране. Оно не может смонтировать файловую систему вашего телефона. Оно не может запустить Android, оно понятия не имеет, как конкретный телефон хранит свой журнал вызовов, и оно должно работать с любым когда-либо выпущенным телефоном. Ему нужен не зависящий от производителя контракт только на чтение небольшого, чётко определённого набора данных: дай мне телефонную книгу, дай мне последние вызовы, в формате, который он уже понимает (vCard).

PBAP — ровно такой контракт. И каждое свойство, делающее его хорошим профилем для интеграции с автомобилем, одновременно делает его хорошим каналом извлечения:

Никакого приложения на телефоне. Возможность встроена в стек Bluetooth. Оператор ничего не устанавливает на цель.
Ни root, ни доступа к файловой системе. Удалённая сторона никогда не касается хранилища Android. Она отправляет абстрактный запрос («дай мне историю входящих вызовов»), а чтение выполняет собственный привилегированный процесс Bluetooth телефона.
Узкий стандартизированный набор данных. Телефонная книга и история вызовов в виде переносимых vCard. Никакого эксплойта, никакого разбора проприетарной базы данных — просто данные, отданные в документированном формате.
Он всегда доступен. Стоковый телефон анонсирует PBAP-сервер через SDP как постоянно работающую службу.

PBAP спроектирован как путь чтения ваших контактов и вызовов без приложения, без root и без файловой системы. В этом предложении — весь тезис статьи. Он предназначался для вашего автомобиля. Ничто в архитектуре не говорит, что на другом конце обязательно должен быть автомобиль.

Как это работает: PBAP — прикладной профиль, построенный на OBEX, протоколе обмена объектами, лежащем в основе передачи файлов по Bluetooth, который работает поверх RFCOMM и L2CAP:

HCI  >  ACL  >  L2CAP  >  RFCOMM  >  OBEX  >  PBAP

Это клиент-серверная модель. Телефон — сервер (Phone Book Access Server, PSE). Удалённое устройство, будь то автомобиль или инструмент извлечения, — клиент (PCE). Клиент открывает OBEX-сессию и отправляет запросы GET для именованных объектов, а телефон отвечает vCard. Модель данных шире, чем список контактов. Сервер предоставляет отдельные объекты в репозитории telecom:

Объект	Путь	Содержимое
`pb`	`/telecom/pb`	телефонная книга (контакты)
`fav`	`/telecom/fav`	избранное
`ich`	`/telecom/ich`	история входящих вызовов
`och`	`/telecom/och`	история исходящих вызовов
`mch`	`/telecom/mch`	история пропущенных вызовов
`cch`	`/telecom/cch`	объединённая история вызовов

(Для данных, хранящихся на SIM-карте, есть эквиваленты /SIM1/telecom/....)

Клиент никогда не видит базу данных журнала вызовов Android. Он запрашивает /telecom/cch, а служба Bluetooth в Android сама обращается к локальному провайдеру CallLog, составляет vCard и отдаёт их потоком. Привилегированное чтение выполняет сам телефон, у самого себя, от имени удалённой стороны. Именно поэтому оставляемый след приписывается com.android.bluetooth, а не какому-либо приложению, принесённому оператором.

Мы извлекли модуль Bluetooth с актуального устройства и декомпилировали его для анализа. Хотя взят он с устройства Pixel, здесь мы используем его как ориентир для схожих реализаций других OEM. На Pixel 8 (Android 17) стек — это не вендорский APK. Это модуль Google:

/apex/com.android.bt/app/BluetoothGoogle@370549400/BluetoothGoogle.apk
package: com.google.android.bluetooth

Поскольку PBAP-сервер теперь поставляется в APEX, на современных устройствах это всё чаще один и тот же код, а не форк каждого вендора. Удалённый GET попадает в BluetoothPbapObexServer.onGet(), который диспетчеризует по типу объекта:

BluetoothPbapObexServer.onGet()                 // [L236]
   ├── pullVcardListing()                       // [L343]
   ├── pullVcardEntry()                         // [L346]
   └── pullPhonebook()                          // [L349]

Допустимые пути объектов жёстко заданы в коде, и это набор telecom, приведённый выше:

// BluetoothPbapObexServer, L66
public static final String[] LEGAL_PATH = {
    TELECOM_PATH, PB_PATH, FAV_PATH, ICH_PATH, OCH_PATH, MCH_PATH, CCH_PATH };

Для истории вызовов путь ведёт в BluetoothPbapVcardManager, где процесс Bluetooth напрямую запрашивает контент-провайдер журнала вызовов:

// BluetoothPbapVcardManager (Android 17 mainline), getCallHistorySize()  [L132]
cursor = BluetoothMethodProxy.getInstance().contentResolverQuery(
    this.mResolver,
    CallLog.Calls.CONTENT_URI,          // привилегированное чтение
    null,
    BluetoothPbapObexServer.createSelectionPara(i),
    null,
    "date DESC");

loadCallHistoryList() выполняет тот же запрос к CallLog.Calls.CONTENT_URI, чтобы построить возвращаемые vCard. Эта строка — источник AppOp READ_CALL_LOG, который форензик впоследствии находит приписанным процессу Bluetooth. Контакты идут через тот же менеджер к ContactsContract, порождая READ_CONTACTS. Ни один из этих путей не выполняется просто оттого, что Bluetooth включён. Оба требуют операции на уровне профиля — реального запроса объекта удалённым клиентом, — и именно это позволяет привязать AppOp к конкретной сессии, а не к фоновому шуму.

Есть и второй способ, которым процесс Bluetooth может прочитать журнал вызовов: код телефонной книги Hands-Free (hfp.AtPhonebook, использующий AT+CPBS и AT+CPBR), применяемый гарнитурами и автомобильными комплектами через профиль гарнитуры. Методология обнаружения ниже разделяет эти два случая.

Часть 2: Модель согласия и есть уязвимость

Разрешена ли PBAP-сессия, сводится к единственному сохранённому значению для каждого удалённого устройства — разрешению на доступ к телефонной книге. При старте сессии сервер его проверяет:

// BluetoothPbapService.checkOrGetPhonebookPermission()  [L592]
int perm = getAdapterService().getPhonebookAccessPermission(remoteDevice);
if (perm == 1) {                       // ACCESS_ALLOWED
    setConnectionPolicy(remoteDevice, 100);
    pbapStateMachine.sendMessage(1);   // PBAP продолжает работу, запроса нет
    return;
}
if (perm == 2) {                       // ACCESS_REJECTED
    pbapStateMachine.sendMessage(2);   // отказ
    return;
}
// иначе UNKNOWN: рассылается CONNECTION_ACCESS_REQUEST, ожидание ответа пользователя 30 с

Если разрешение уже ALLOWED, массовое чтение вашей телефонной книги и истории вызовов проходит молча. В момент, когда данные забирают, никакого запроса нет. Запрос появляется только в случае UNKNOWN. Разрешение задаётся при сопряжении: поток вызывает setPhonebookAccessPermission(device, ACCESS_ALLOWED) (значение 1), если общий доступ к контактам включён, или ACCESS_REJECTED (значение 2), если нет:

// BluetoothPbapService, L224 / L230
getAdapterService().setPhonebookAccessPermission(bluetoothDevice, 1); // ACCESS_ALLOWED
...
getAdapterService().setPhonebookAccessPermission(bluetoothDevice, 2); // ACCESS_REJECTED

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

Это та самая слабость, которую Xu et al. задокументировали в BadBluetooth [1]. Android аутентифицирует устройство при сопряжении, а не каждый профиль при использовании, поэтому привязанному устройству доверяют в чувствительных профилях без нового запроса, и устройство, сопряжённое под безобидным профилем, может затем переключиться на другой профиль, чтобы добраться до данных, которые оно никогда открыто не запрашивало. Они показали это на Android с 5.1 по 8.1 на Pixel 2. Код выше — та же архитектура, всё ещё поставляемая семь лет спустя в модуле Android 17.

На вендорской сборке изъятого устройства сам диалог сопряжения устанавливает разрешение, и его флажок общего доступа к контактам предустановлен, когда удалённая сторона представляется автомобильным комплектом hands-free (класс устройства Bluetooth 0x0408). Этот предустановленный флажок находится в вендорской доработке BluetoothPairingController. Мы не проверяли это на Pixel и не утверждаем, что это общее поведение Android. Общим же — поскольку это находится в модуле выше — является базовое правило: ALLOWED означает «молча», а ALLOWED устанавливается именно сопряжением.

Часть 3: Что предсказывает механизм

Ещё до каких-либо улик код говорит нам, как PBAP-извлечение должно выглядеть постфактум и как не должно:

AppOp READ_CALL_LOG (и обычно READ_CONTACTS), приписанный процессу Bluetooth, попадающий по времени внутрь Bluetooth-соединения и не обновляющийся при следующем перезапуске стека Bluetooth, потому что он вызван удалённым запросом, а не запуском стека.
Никакого AppOp от простого соединения. Включение Bluetooth, поднятие ACL-канала или образование привязки сами по себе не должны читать журнал вызовов.
Никакого аудиопрофиля у удалённой стороны, поскольку PBAP — это не HFP и не A2DP, и никакого приложения, установленного оператором.
Событие сопряжения непосредственно перед этим, возможно, вообще без отдельного запроса разрешения.

В части 4 эти предсказания проверяются на реальном изъятии, а затем подтверждаются на устройстве под нашим контролем.

Часть 4: Результаты — изъятие и воспроизведение

Изъятие

Изъятый телефон, Android-сборка с вендорскими доработками, находился в руках сотрудников несколько минут во время изъятия на российском пограничном контроле. Вскоре после этого форензик с помощью MESH удалённо и без root провёл расследование, включавшее сбор данных с помощью MVT, поэтому короткоживущее состояние системы и логи сохранились. Пригодного HCI-захвата не было: постоянное Bluetooth-снупирование было выключено, а сохранившийся btsnooz_hci.log содержал только заголовок. Сырые PBAP-пакеты исчезли. Далее — корреляция, которая тем не менее выявила обе модели поведения.

Модель 1: сбор идентификаторов. До Bluetooth-активности, во время изъятия, телефон показал короткую последовательность работы с идентификаторами. В приложении «Телефон» (Dialer) прозвучали пять тональных сигналов клавиатуры, вызов не совершался, и после этого Dialer оставался открытым ещё около 44 секунд. Эта картина соответствует *#06#, коду отображения IMEI (интерпретация, средне-высокая уверенность; сами цифры не записываются). Затем UI перешёл в настройки мобильной сети примерно на 11,6 секунды; здесь UsageStats всё же идентифицирует страницу — MobileNetworkSettings из com.android.phone, — которая показывает оператора связи и, если оператор её прописал, телефонный номер SIM-карты, но не IMSI. Вместе это описывает сбор идентификатора устройства (IMEI, по выводу) и просмотр конфигурации SIM-карты и сети.

Всё это читается прямо из bugreport; каждый пункт — секция службы dumpsys внутри него (абсолютное время не раскрывается):

media.metrics: генератор DTMF-тонов Dialer запускался пять раз подряд с короткими интервалами, и лог вендорской службы управления питанием независимо зафиксировал пять активаций UID Dialer в те же моменты.
telecom (аналитика вызовов): в этом окне вызовов не было; первый вызов — часами позже.
usagestats: Dialer на переднем плане, затем MobileNetworkSettings из com.android.phone (от ACTIVITY_RESUMED до ACTIVITY_PAUSED, около 11,6 с).

Почему это важно — в части 5.

Модель 2: Bluetooth и PBAP-извлечение. По собранным данным, в одном коротком окне (смещения указаны относительно момента включения Bluetooth в окне изъятия устройства; абсолютные даты и время не раскрываются):

T+00.0 с  Bluetooth включён  "by com.android.settings"  (до этого выключен несколько часов)
T+08.0 с  ACL_CONNECTED      внешнее устройство, сессия 1
T+08.5 с  показан BluetoothPairingDialog, принят в течение ~4 с
T+22.5 с  com.android.bluetooth -> READ_CALL_LOG        (внутри сессии)
T+26.9 с  ACL_DISCONNECTED   сессия 1
T+27.1 с  последняя запись в базу Bluetooth-привязок (позже записей не было)
T+27.3 с  ACL_CONNECTED снова (сессия 2), 1 UUID службы
T+35.1 с  ACL_DISCONNECTED   сессия 2

Каждая строка выше — отдельный артефакт в bugreport (смещения относительные; абсолютное время не раскрывается):

Наблюдение	Источник в собранных данных
Bluetooth включён `com.android.settings`	`dumpsys bluetooth_manager`, лог включения (Enable log)
ACL-подключение/отключение, один UUID службы	лог приёмника Android Auto (`GearheadCarStartupService`)
Диалог сопряжения показан и принят	`dumpsys usagestats` (`BluetoothPairingDialog`)
`READ_CALL_LOG` процессом Bluetooth	`dumpsys appops` (а также `timeline.csv` из MVT)
Последняя запись в базу привязок	`dumpsys dbinfo` (mtime `bluetooth_db-wal`)
Отсутствие аудиоустройства	`dumpsys audio` (AudioService) и лог службы профилей Bluetooth
Состояние профиля PBAP vs HFP	`dumpsys wifi` (`ClientModeImpl`)

Все предсказания из части 3 присутствуют. READ_CALL_LOG приписан процессу Bluetooth, находится внутри ACL-сессии и не был обновлён при следующем перезапуске стека Bluetooth часами позже, то есть был вызван удалённым запросом. У удалённой стороны не было аудиоустройства (AudioService не показывает ни одного), не было установленных приложений, чужих ADB-ключей, передачи файлов по OPP, чтения MAP или SMS, Wi-Fi Direct. Диалог сопряжения был принят за четыре секунды — барьер согласия из части 2.

Из-за перезаписи данных, мы не можем подтвердить, что контакты были забраны, но мы с высокой уверенностью полагаем, что были, и стоит ясно объяснить почему. PBAP-клиент обычно сначала вытягивает телефонную книгу, а на этой сборке PBAP-сессия читает базу данных контактов при подключении независимо от того, что клиент запросит дальше: BluetoothPbapService.onConnect() выдаёт LOAD_CONTACTS, который вызывает BluetoothPbapUtils.loadAllContacts() и запрашивает ContactsContract. До изъятия Bluetooth был выключен несколько часов и включён за секунды до соединения, так что контакты ещё не были загружены, и сама сессия заставила бы com.android.bluetooth прочитать базу данных контактов. Вот почему мы уверены, что контакты были прочитаны. Причина, по которой мы не можем указать на отметку напрямую, в том, что AppOp READ_CONTACTS процесса Bluetooth был перезаписан часом позже обычной реакцией службы на последующее изменение контактов, так что этот слот ничего не говорит ни в ту, ни в другую сторону. Это важно для криминалистической целостности: если вы считаете, что PBAP использовался для получения ваших контактов, не изменяйте и не трогайте их до криминалистического сбора данных, потому что обычное использование перезаписывает ту самую запись, которая показала бы доступ. Отсутствие отметки — не свидетельство отсутствия, а перезаписанная запись.

Что устанавливает изъятие. Без HCI-пакетов точный OBEX-запрос напрямую показать нельзя. Что подтверждают улики, с указанной степенью уверенности: доступ к истории вызовов имел место (AppOps, прямое свидетельство); он был опосредован Bluetooth (временная корреляция, сильное); механизмом был PBAP (путь в коде есть плюс отсутствие аудиопрофиля, сильное); точные объекты невосстановимы (нет HCI). Удалённое устройство, его производителя и инструментарий оператора невозможно установить по тому, что сохранилось.

Воспроизведение на устройстве под нашим контролем

Изъятие даёт положительный след — READ_CALL_LOG внутри Bluetooth-сессии во время изъятия устройства, — но то, что это было сделано через PBAP не доказано. Чтобы закрыть этот пробел, мы воспроизвели извлечение от начала до конца через PBAP и наблюдали появление тех же следов. Целью был стоковый Pixel 8 на Android 17 (сборка CP2A.260805.005), с заполненными журналом вызовов и контактами, без root. Клиентом был обычный ноутбук с Linux и BlueZ, выполнявший PBAP-выгрузку через стандартный API PhonebookAccess в obexd, в роли, которую играл бы криминалистический инструмент или автомобиль. Все Bluetooth-адреса скрыты.

Сервер — постоянно работающая служба. SDP-запись стокового Pixel анонсирует сервер телефонной книги наряду с серверами доступа к SIM и доступа к сообщениям, без установленных приложений и без чего-либо включённого нами:

UUID: Phonebook Access Server   (0000112f-...)
UUID: SIM Access                (0000112d-...)
UUID: Message Access Server     (00001132-...)

(Мы прочитали это из SDP-записи устройства. Чтобы установить, что она анонсируется до любого сопряжения, потребовался бы отдельный SDP-обзор, который текущий userland BlueZ больше не поставляет, поэтому мы этого не измеряли.)

Одно лишь соединение не читает журнал вызовов на Pixel. Это отрицательный контроль для предсказания 2 из изъятия. Мы выполнили привязку и подключились, затем прочитали AppOps процесса Bluetooth до какого-либо PBAP-запроса:

com.google.android.bluetooth
  FINE_LOCATION   Access: T-2h30m   (соединение)
  WAKE_LOCK       Access: T-2h30m   (соединение)
  READ_CALL_LOG   Access: T-2h30m   (не изменился, устаревший с более ранней сессии)
  READ_CONTACTS   Access: T-2h30m   (не изменился)

Привязка и подключение вызвали операции геолокации и wake-lock, но не тронули READ_CALL_LOG и READ_CONTACTS. Подключение — не доступ. Отметим, что у других OEM это может быть иначе.

Первая PBAP-сессия, без выданного разрешения на телефонную книгу, завершилась неудачей почти мгновенно:

CreateSession(pbap) -> org.bluez.obex.Error.Failed: Transport got disconnected   (~430 мс)

PBAP-сервер принял RFCOMM-сокет и сразу закрыл его. Отклонённая сессия выглядит как мгновенный разрыв транспорта, а не как отказ на экране, так что форензику нечего найти, что говорило бы «доступ запрещён». Затем мы включили на Pixel один переключатель — «Contacts and call history sharing» (доступ к контактам и истории вызовов) для сопряжённого хоста, то есть setPhonebookAccessPermission(ACCESS_ALLOWED) из части 2, — и повторили ту же самую выгрузку. Она прошла успешно, без какого-либо запроса в момент доступа к данным.

С разрешением ALLOWED мы вытянули pb, ich, och, mch, cch. AppOps процесса Bluetooth сместились на момент выгрузки:

AppOp	До	После (в момент выгрузки)
`READ_CONTACTS`	устаревший (более ранняя сессия)	время выгрузки
`READ_CALL_LOG`	устаревший (более ранняя сессия)	время выгрузки + 1 с

Контакты были прочитаны на секунду раньше журнала вызовов. Телефонная книга вытягивается первой, и именно поэтому перезаписанный слот READ_CONTACTS в изъятии согласуется с тем, что контакты там тоже были прочитаны. Вернувшиеся объекты были настоящими:

pb.vcf   184 vCard   (контакты)
ich.vcf   50 vCard   (входящие вызовы)
och.vcf   50 vCard   (исходящие вызовы)
mch.vcf   50 vCard   (пропущенные вызовы)
cch.vcf   50 vCard   (объединённые)

Каждая запись о вызове несла свои метаданные, например X-IRMC-CALL-DATETIME;RECEIVED:20xxxxxxTxxxxxx. PBAP отдаёт 184 контакта и 200 записей о вызовах со стокового, обновлённого Pixel без root, без приложения на телефоне и без доступа к файловой системе. Воспроизведение удерживает оба конца, из которых изъятие могло удержать лишь один: мы вызвали PBAP-выгрузку и увидели следы READ_CALL_LOG и READ_CONTACTS, на которые опиралось дело, рядом с отрицательным контролем, показывающим, что одно лишь соединение не даёт ни того, ни другого.

Как это соотносится с изъятием. Ценность воспроизведения не в Pixel, а в совпадении. Каждый результат на стенде соответствует чему-то, что собранные данные сохранили или не сохранили, и стоит точно указать, какие из них — прямые совпадения, а какие — лишь согласованность:

Изъятие: что сохранилось	Воспроизведение: что мы вызвали	Что устанавливает совпадение
`READ_CALL_LOG` у процесса Bluetooth, внутри сессии, не обновлён при следующем перезапуске стека	Выгрузка выдаёт `READ_CALL_LOG` у процесса Bluetooth в момент выгрузки	Центральный след изъятия — ровно то, что производит PBAP-выгрузка. Прямое совпадение.
Слот `READ_CONTACTS` перезаписан часами позже, ничего не говорит	Выгрузка выдаёт `READ_CONTACTS` на секунду раньше журнала вызовов	Отметка, утраченная изъятием, — та, которую та же выгрузка и записала бы. Согласованность, не доказательство.
Нет аудиоустройства, нет приложения, нет передачи по OPP или MAP	Та же отрицательная картина вокруг чистой выгрузки телефонной книги	Отделяет PBAP-извлечение от автомобильного комплекта или гарнитуры, делающих свою работу.
Окно соединения есть, причина чтения из него одного не изолируется	Отрицательный контроль: только подключение, оба AppOp остаются устаревшими	Исключает простое соединение как источник чтения.

Итак, воспроизведение не доказывает, что произошло с этим конкретным телефоном; перезапись и отсутствующие пакеты ставят это вне досягаемости. Оно доказывает причинно-следственную связь, которой раньше не хватало: PBAP-выгрузка воспроизводит картину, показанную изъятием, тогда как одно лишь соединение не оставляет ничего. Изъятие оставляет следы на реальной цели, а воспроизведение показывает, как это работает на идентичном ПО.

Для чего было извлечение

Улики с телефона нейтральны в отношении того, зачем были взяты данные. Контекст для нас не нейтрален. При изъятии на российском пограничном контроле вытягивание контактов и истории вызовов цели, наиболее правдоподобно, представляет собой проверку социального графа цели, в частности на предмет контактов с украинскими номерами (+380) и известных лиц, представляющих интерес. Это интерпретация из контекста и от наших партнёров, а не из байтов на телефоне. PBAP возвращает всю телефонную книгу и историю вызовов в виде vCard, как показало воспроизведение, и ничто в сохранившемся следе не говорит, какие записи имели значение для оператора.

Что не произошло в том же окне, столь же показательно, как и то, что произошло. Помимо чтения идентификаторов и вытягивания истории вызовов мы не нашли никакого другого сбора данных: ни извлечения SMS или MAP, ни передачи файлов по Bluetooth, ни Wi-Fi Direct, ни установленного приложения или агента, ни скриншотов, записи экрана, использования камеры или микрофона. Оператор действительно перемещался по телефону вручную, но больше ничего с него прочитано не было. Эта узость имеет значение: сбор был ограничен идентификаторами устройства и абонента плюс телефонной книгой и историей вызовов, то есть это целевая проверка, а не полный криминалистический образ, и это совместимо со сбором, направленным на поддержку корреляции на стороне сети. Эти идентификаторы входят в число селекторов, которые могут использовать системы вроде СОРМ, а граф вызовов образует набор связей, в которых эти селекторы находятся, о чём часть 5.

Часть 5: СОРМ: почему сбор идентификаторов важен на границе

Модель 1 выглядит незначительной рядом с массовой выгрузкой контактов. В российском контексте это не так, и причина в СОРМ. Сразу оговоримся, что СОРМ здесь служит аналитическим контекстом того, почему важен сбор идентификаторов, а не тем, что может показать сам телефон; устройство не может показать какое-либо взаимодействие с системой перехвата на стороне сети.

СОРМ (система оперативно-розыскных мероприятий) — российская система законного перехвата на стороне сети: инфраструктура, подключённая к операторам связи и обеспечивающая перехват для уполномоченных ведомств. СОРМ-3 добавляет возможности массового сбора и глубокой инспекции пакетов (DPI) и поддерживает нацеливание по селектору, включая телефонный номер, IMSI, IMEI и MAC-адрес, наряду с сетевым трафиком. Insikt Group компании Recorded Future задокументировала архитектуру СОРМ и её экспорт в государства Центральной Азии и Латинской Америки, включая вероятность того, что Москва сохраняет доступ к системам на базе СОРМ, развёрнутым за рубежом [7]. Это делает модель сбора идентификаторов логически цельной:

                 СТОРОНА ОПЕРАТОРА / СЕТИ
              +-----------------------------+
              |           СОРМ-3            |
              |   селекторы:                |
              |     - телефонный номер      |
              |     - IMSI                  |
              |     - IMEI      < телефон   |
              |     - MAC-адрес             |
              |   + сетевой трафик / DPI    |
              +-------------+---------------+
                            |  корреляция
                            v
              +-----------------------------+
              |     ИЗЪЯТОЕ УСТРОЙСТВО      |
              |   - просмотр IMEI (*#06#)   |  < идентификатор
              |   - настройки SIM / сети    |  < идентификатор
              |   - сопряжение Bluetooth    |
              |   - PBAP: вызовы/контакты   |  < доказано
              +-----------------------------+

  доказано на телефоне ===   контекст / сторона сети ...

СОРМ — возможность на стороне сети. Если бы она была задействована, свидетельства были бы у оператора связи, а не в чём-либо, установленном на телефоне. То, что показывает телефон: IMEI (выведенный из последовательности *#06#) и Bluetooth-MAC телефона (неизбежно раскрытый удалённой стороне при сопряжении), оба — селекторы СОРМ-3, плюс данные из настроек мобильной сети. Мы не нашли свидетельств того, что были прочитаны IMSI или телефонный номер; это идентификаторы, которые СОРМ коррелирует, а не те, которые телефон доказанно отдал. Тем не менее IMEI и MAC-адрес, прочитанные при изъятии, — это значения, которые позволяют позже вытянуть и обогатить записи на стороне СОРМ для этого устройства.

Часть 6: Криминалистический инструментарий: PBAP, Oxygen и MKO Systems

Получение телефонной книги по PBAP — не новость для коммерческой криминалистики. Oxygen Forensic Detective документирует сбор данных по Bluetooth, включая телефонную книгу и контакты, наряду с USB и агентными методами, а вытягивание телефонной книги и истории вызовов по Bluetooth на практике и есть PBAP (с OBEX и AT/HFP как родственными путями для старых телефонов).

Эту возможность можно показать конкретно. Мы сделали реверс-инжининг Bluetooth-библиотеки (drvman.dll) MOBILedit, ещё одного массового коммерческого криминалистического продукта (COMPELSON Laboratories), из чистой официальной сборки. Это хрестоматийный PBAP-клиент: он разрешает RFCOMM-канал телефона через SDP, открывает сокет AF_BTH, при подключении отправляет целевой UUID PBAP OBEX (796135f0-f0c5-11d8-0966-0800200c9a66) и выполняет GET telecom/{pb,ich,och,mch}.vcf с MIME-типом x-bt/phonebook, разбирая возвращённые vCard локально. Примечательно, что объекты истории вызовов (ich/och/mch) были добавлены между сборкой 2015 года и сборкой 2024 года и по-прежнему поставляются в текущей 64-битной сборке (10.10.0.35095, август 2026), так что вытягивание истории вызовов по PBAP — актуальная коммерческая возможность, а не устаревший рудимент. MOBILedit — продукт, отличный от Oxygen или Мобильного криминалиста, и мы приводим его лишь как независимо проверяемый пример того, что клиентская возможность реальна и поставляется; подробности — в сопутствующем разборе.

Oxygen Forensics начиналась как Oxygen Software в Москве в начале 2000-х, прежде чем зарегистрироваться как Oxygen Forensics Inc. в США. По данным репортажей Ольги Лаутман и Андрия Лучкова, а также более ранних материалов Forbes, её основатели Олег Фёдоров и Олег Давыдов также участвовали в создании MKO Systems — российской компании, стоящей за «Мобильным Криминалистом» [4][5]. «Мобильный Криминалист» стал ведущей российской платформой извлечения данных из телефонов и, согласно российским закупочным и судебным документам, цитируемым в этих репортажах, поставлялся государственным органам, включая ФСБ и МВД, и использовался в политически чувствительных уголовных делах. Те же репортажи связывают подсанкционного инвестора, бывшего сотрудника ФСБ Эдуарда Бендерского с холдинговой компанией Oxygen и отмечают, что в 2021 году Oxygen получила лицензию ФСБ на криптографию.

Независимое подтверждение того, что эти инструменты действительно применяются на практике, а не просто продаются, приходит из российской профессиональной литературы. Статья 2024 года в «Вестнике Восточно-Сибирского института МВД России» сообщает, что, по результатам изучения практики органов внутренних дел, наиболее популярными программными средствами среди оперативных подразделений территориальных органов МВД являются MOBILedit и «Мобильный Криминалист», тогда как UFED от Cellebrite и XRY от MSAB считаются более функциональными, но применяются реже [8]. Это источник из системы МВД, помещающий два продукта, находящихся в центре этого раздела, непосредственно в руки российских оперативных подразделений — в тот самый контекст негласных оперативно-розыскных мероприятий, к которому относится изъятие на границе.

Мы не утверждаем, что это извлечение выполнил конкретный продукт Oxygen, MKO или MOBILedit; собранные данные не могут назвать инструмент. Более узкий и лучше обоснованный тезис таков: зрелая российская экосистема мобильной криминалистики существует, используется российскими правоохранительными органами и спецслужбами и имеет общее происхождение с массовым западным продуктом. Извлечение телефонной книги и истории вызовов по PBAP полностью укладывается в задокументированные возможности этой экосистемы. Изъятие на границе, при котором по PBAP тихо вытягиваются контакты и история вызовов, согласуется с инструментарием именно из этой среды, будь то специальная сборка или функция существующей платформы.

Часть 7: Методология обнаружения

Полезный сигнал — это не единичный индикатор компрометации (IOC). Это схождение нескольких обычных артефактов Android. Практический порядок действий:

Собирайте данные как можно скорее после изъятия. Волатильное состояние быстро теряется.
Сохраняйте состояние Bluetooth. По возможности не перезагружайте устройство, не переключайте Bluetooth и не включайте/выключайте авиарежим. Цикл авиарежима сбрасывает хранящиеся в памяти стека записи о привязках и соединениях, которые содержат адрес удалённой стороны, а перезагрузка теряет ещё больше.
Нормализуйте часы перед корреляцией. Один bugreport может выводить несколько часовых поясов или форматов (в данном случае: домашний пояс устройства, второй пояс после поездки, UTC и epoch-миллисекунды).
Стройте окно событий по UsageStats в epoch-миллисекундах, а не по спискам с точностью до секунды. Именно субсекундный порядок связывает диалог сопряжения с событием канала.
Идентифицируйте события включения Bluetooth, ACL и сопряжения.
Изучите AppOps на предмет READ_CALL_LOG, READ_CONTACTS и READ_SMS у процесса Bluetooth и сравните с последним запуском стека.
Определите, какие профили фактически были активны (AudioService, состояние адаптера), чтобы отделить PBAP от HFP.
Для продвинутых: изучите модуль Bluetooth на соответствующей прошивке. Декомпилируйте его; пути кода PBAP и HFP и логика разрешений закрывают вопросы, которые иначе остались бы на уровне мнений.
Скоррелируйте mtime базы данных привязок и состояние привязок.
Отдельно исключите ADB, USB, установку пакетов и другие механизмы закрепления.
Восстановите данные HCI snoop там, где они есть.
Различайте наблюдаемые факты, подтверждённое кодом поведение и умозаключения, и записывайте отрицательные результаты вместе с их покрытием.

Решающее правило. READ_CALL_LOG у процесса Bluetooth, не обновлённый при следующем запуске стека, был вызван удалённым устройством. При наличии аудиоустройства это автомобильный комплект или гарнитура, делающие свою работу. Без аудиоустройства и без оставшейся привязки — это извлечение.

Часть 8: Меры защиты

Ни одна из них не защищает от принудительной разблокировки, но каждая повышает цену.

Удалите историю вызовов и контакты перед ожидаемым досмотром и восстановите их после. PBAP может отдать только то, что есть на телефоне.
Держите Bluetooth выключенным всегда, когда это возможно. На текущих прошивках диалог сопряжения — единственный шаг согласия для доступа к телефонной книге; при чтении данных запроса нет.
Очищайте корзину Галереи вручную, а не полагайтесь на автоочистку через 30 дней. (Побочный вывод из дела: открытие Галереи запустило автоматическую очистку просроченной корзины — 661 файл. Не каждое массовое изменение во время изъятия — действие оператора.)
Выключенный телефон извлечь труднее, чем заблокированный работающий, хотя это не помогает, если владельца заставляют его разблокировать.
Если последующее доказательство важнее приватности лога, включите HCI snoop-логирование Bluetooth перед поездкой. С ним bugreport по делу содержал бы адрес удалённой стороны, её класс и полный PBAP-обмен. Но он также записывает весь собственный Bluetooth-трафик владельца.

Ограничения

Удалённое устройство в деле не может быть идентифицировано. Не сохранилось ни адреса, ни имени, ни класса, ни префикса производителя.
Точные PBAP-объекты, запрошенные в деле, невосстановимы, поскольку HCI-захвата не было. Воспроизведение на Pixel показывает, как выглядят эти объекты и их следы, но это отдельное устройство, и оно не может заполнить пробел в деле.
Контакты: чтение контактов процессом Bluetooth во время сессии подтверждено кодом, поскольку PBAP-сессия загружает контакты при подключении, но сохранившийся слот AppOps READ_CONTACTS был перезаписан часами позже. Была ли телефонная книга передана удалённой стороне, недоказуемо без HCI-захвата.
Дискриминатор PBAP-против-HFP по ClientModeImpl подтверждён кодом только на вендорской сборке изъятого устройства. Живой отрицательный контроль по HFP не проводился.
Вендорское поведение сопряжения изъятого устройства — диалог, сам устанавливающий разрешение, и предустановленный флажок для автомобильного комплекта 0x0408 (часть 2), — это вендорский код, и мы не заявляем его как общее поведение Android.
Инструментарий оператора не может быть отнесён к какому-либо продукту. Наше мнение, что он принадлежит российской криминалистической экосистеме, описанной в части 6, — это оценка, а не вывод с устройства; собранные данные не могут назвать инструмент.
Модель 1 отчасти интерпретация. Чтение *#06#/IMEI опирается на пять тонов Dialer и отсутствие вызова. Страница мобильной сети идентифицирована по UsageStats (MobileNetworkSettings), но что именно с неё было прочитано — оператор связи и какой-либо прописанный телефонный номер — невосстановимо, и IMSI она не отображает. Получение IMSI и телефонного номера не подтверждено; Bluetooth-MAC телефона был раскрыт удалённой стороне при сопряжении.
Цель в виде украинских номеров и обсуждение СОРМ — контекст, а не выводы с устройства. Телефон не может показать, зачем данные были взяты, и не может показать какое-либо взаимодействие с системой перехвата на стороне сети.

Эти ограничения — часть результата, а не пробелы, которые следует заполнять умозаключениями.

Заключение

PBAP — легитимный Bluetooth-интерфейс Android для предоставления данных телефонной книги и истории вызовов таким устройствам, как автомобили. Его архитектура — без приложения, без root, без доступа к файловой системе, узкий стандартизированный набор данных, постоянный анонс — и делает его каналом логического извлечения при изъятии. Согласие — единственное значение, устанавливаемое при сопряжении, и как только оно ALLOWED, массовое чтение происходит молча.

Мы показали путь в коде поставляемого модуля Bluetooth, реконструировали реальное изъятие на российском пограничном контроле, где пакеты давно исчезли, и воспроизвели полное извлечение на стоковом, обновлённом Pixel 8: 184 контакта и 200 записей о вызовах, вытянутые без root и без приложения на телефоне, с ровно теми следами READ_CALL_LOG и READ_CONTACTS, на которые опиралось исследование, рядом с отрицательным контролем, доказывающим, что одно лишь соединение не оставляет никаких.

В том изъятии выгрузка не была сама по себе. Она стояла рядом со сбором идентификаторов, IMEI и SIM, и эти две части совместимы с более широким процессом сбора: контакты и история вызовов картируют социальный граф цели, наиболее правдоподобно как проверка на украинские контакты и известных фигурантов, а идентификаторы устройства и абонента могут поддержать последующую корреляцию на стороне сети. В российском контексте это делает СОРМ уместной аналитической рамкой, но улики с телефона не устанавливают, что СОРМ применялась. Получение телефонной книги по PBAP — задокументированная коммерческая возможность, и она принадлежит российской криминалистической экосистеме — «Мобильному Криминалисту» MKO Systems, имеющему общее происхождение с Oxygen Forensics и используемому российскими правоохранительными органами, — в которую это изъятие вписывается. Мы доказываем сторону телефона и прямо говорим, что остальное — контекст.

Bluetooth — не только артефакт связи. PBAP — путь доступа к данным, реализующие его службы Android оставляют свидетельства по всей системе, и эти свидетельства могут выявить злоупотребление спустя долгое время после того, как захват пакетов исчез.

Источники

[1] F. Xu, W. Diao, Z. Li, J. Chen, K. Zhang. BadBluetooth: Breaking Android Security Mechanisms via Malicious Bluetooth Peripherals. Network and Distributed Systems Security (NDSS) Symposium 2019. https://www.ndss-symposium.org/wp-content/uploads/2019/02/ndss2019_06B-4_Xu_paper.pdf

[2] M. Naveed, X. Zhou, S. Demetriou, X. Wang, C. A. Gunter. Inside Job: Understanding and Mitigating the Threat of External Device Mis-Bonding on Android. Network and Distributed System Security (NDSS) Symposium 2014.

[3] Armis. BlueBorne: The Attack Vector Exposing Almost Every Connected Device. 2017. https://www.armis.com/research/blueborne/

[4] T. Brewster. Russian Hackers’ Lawsuit Reveals Weaknesses In Apple’s iOS 16. Forbes, 4 декабря 2023. https://www.forbes.com/sites/thomasbrewster/2023/12/04/russian-hacker-lawsuit-exposes-flaws-in-apples-ios-16/

[5] O. Lautman, A. Luchkov. ICE Is Using Phone Extraction Software Linked to Russia’s FSB-Connected Network. Malign Influence Operations (Substack), 18 февраля 2026. https://maligninfluenceoperations.substack.com/p/ice-is-using-phone-extraction-software

[6] Meduza. What a top Russian cyber-forensics conference reveals about the country’s ability to hack iPhones and Androids. https://meduza.io/en/slides/what-a-top-russian-cyber-forensics-conference-reveals-about-the-country-s-ability-to-hack-iphones-and-androids

[7] Insikt Group (Recorded Future). Tracking Deployment of Russian Surveillance Technologies in Central Asia and Latin America. 7 января 2025. https://assets.recordedfuture.com/insikt-report-pdfs/2025/ta-ru-2025-0107.pdf

[8] Куликов А. Г., Кодзов Т. Н. К вопросу использования средств извлечения информации из мобильных устройств при проведении оперативно-розыскных мероприятий. Вестник Восточно-Сибирского института МВД России, 2024, № 2, с. 163–176. https://vestnikesiirk.ru/ru/nauka/publications/article/6a9c154632807fdbab867fad/