1. Введение: Почему VoIP-форензика становится критически важной в 2026
2. Основные источники цифровых следов VoIP-звонков
3. Правовые основы и допустимость VoIP-доказательств
4. Необходимое ПО и оборудование для анализа VoIP
5. Захват VoIP-трафика: от зеркалирования порта до PCAP-файлов
6. Извлечение метаданных звонка: SIP-заголовки и CDR-логи
7. Восстановление аудиопотоков из RTP-сессий
8. Работа с зашифрованными VoIP-звонками (SRTP, TLS)
9. Продвинутые техники: анализ пауз, шумов и встраиваемых меток
10. Альтернативные источники: резервные копии, логи прокси и история клиентов
11. Автоматизация анализа с помощью Python и TShark
12. Проблемы цепочки хранения и аутентификации записей
13. Часто задаваемые вопросы (FAQ) по VoIP-форензике
14. Заключение: итоговый алгоритм эксперта-криминалиста
Введение: Почему VoIP-форензика становится критически важной в 2026
Ежедневно по всему миру совершается более 50 миллиардов минут VoIP-звонков. Корпоративные IP-телефонии, мессенджеры с голосовыми вызовами (Telegram, WhatsApp, Signal), облачные контакт-центры — голосовой трафик всё реже идёт через традиционные TDM-каналы. Для цифрового криминалиста (форензика) это создаёт как новые возможности, так и серьёзные вызовы. В отличие от классической телефонной станции, где запись разговора — это либо отдельный сервер, либо отсутствующая функция, в VoIP-среде каждый пакет может стать уликой.
В 2026 году суды всё чаще принимают в качестве доказательств не только логи call-центров, но и восстановленные RTP-потоки, извлечённые из перехваченного трафика или дампов памяти. Однако практика показывает: 70% специалистов даже не знают, как правильно собрать и сохранить такую улику, не нарушив целостности. В результате голосовые доказательства отвергаются из-за ошибок в процедуре.
Данное руководство — пошаговый алгоритм для эксперта, следователя или системного администратора, которому необходимо восстановить факт, время, содержание или метаданные телефонного разговора, проходившего по IP. Вы узнаете:
- Где искать следы звонка — от SIP-регистрации до RTP-шумов;
- Какие инструменты (бесплатные и профессиональные) гарантируют юридически значимый результат;
- Как восстановить аудиодорожку из PCAP-файла, даже если использовалось переменное кодирование;
- Что делать при шифровании (SRTP, DTLS, ZRTP) и можно ли что-то извлечь;
- Как автоматизировать анализ десятков тысяч звонков с помощью скриптов.
Мы не будем давать выдуманных техник «взлома шифрования» — только законные методы работы с теми данными, которые VoIP-системы оставляют неизбежно: метаданные, время, размер пакетов, шаблоны трафика, фрагменты кодеков, если шифрование не применялось или ключи были получены легально. Каждая рекомендация основана на документации реальных инструментов, RFC и опыте криминалистических лабораторий.
Основные источники цифровых следов VoIP-звонков
Прежде чем восстанавливать разговор, нужно понять, где вообще хранится информация о нём. В отличие от TDM, VoIP рассредоточен по множеству устройств и протоколов. Перечислим основные потенциальные источники улик.
#### 1. Сетевой трафик (PCAP-файлы)
Это самый полный, но и самый сложный источник. В идеальном случае вы имеете захват всего трафика между IP-телефоном и сервером, либо между прокси и шлюзом. В таком PCAP-файле содержатся:
- SIP-пакеты (INVITE, BYE, OK) — с номерами, IP-адресами, User-Agent, временем;
- RTP-пакеты — собственно аудиоданные (если нет SRTP);
- RTCP-пакеты — отчёты о качестве, которые могут указать на факт прослушивания.
Однако получить полный захват в корпоративной сети сложно: нужна точка зеркалирования порта (SPAN), TAP или ARP-spoofing (только с санкции). Для криминалистически значимых доказательств используется изолированный коммутатор с записью на защищённый носитель.
#### 2. Логи SIP-прокси и серверов Asterisk/FreeSWITCH
Большинство корпоративных VoIP-систем (облачных или on‑premise) ведут детальные журналы. Например, Asterisk CDR (Call Detail Record) содержит: дату, длительность, направление, завершающий код. В расширенных настройках можно включить запись SIP-транзакций — они покажут каждый заголовок. Даже если аудио не записывалось, метаданные звонка часто остаются в логах месяцами.
#### 3. Клиентские приложения (Softphones, Telegram, WhatsApp)
На устройстве пользователя сохраняется история вызовов, а иногда и кэш аудио (например, в WhatsApp в папке `Cache` могут быть фрагменты .opus). Для мессенджеров с end‑to‑end шифрованием само аудио в незашифрованном виде извлечь невозможно, но метаданные (время, абонент, длительность) лежат в локальной базе SQLite.
#### 4. Файлы подкачки и дампы оперативной памяти
Если у вас есть физический доступ к компьютеру или смартфону во включённом состоянии, можно получить дамп RAM. В памяти могут остаться:
- неинициализированные буферы аудиокодеков;
- ключи шифрования SRTP (при отладке или уязвимостях);
- SIP-сессии в открытом виде.
Но этот метод сложен и требует специального ПО (например, LiME для Linux, FTK Imager для Windows).
#### 5. Резервные копии облачных PBX
Сервисы типа 3CX, Zadarma, Mango Office предоставляют экспорт звонков (аудиофайлы + JSON/CDR). Администратор с соответствующими правами может выгрузить всё в течение 5 минут. Это легальный и простой источник.
Таким образом, перед началом анализа составьте карту: какие из этих источников доступны в вашей ситуации. Самый часто встречающийся в судебной практике — логи SIP-прокси + восстановленный RTP из трафика, перехваченного на законных основаниях (например, при обыске изъят коммутатор и снят образ его памяти).
Правовые основы и допустимость VoIP-доказательств
Это техническое руководство, но каждый криминалист обязан помнить о рамках закона. В РФ и большинстве стран СНГ перехват телефонных переговоров без санкции суда или постановления следственных органов — уголовное преступление (ст. 138.1 УК РФ). Всё, о чём написано ниже, применимо только:
- При проведении экспертизы по поручению следователя;
- В рамках внутреннего расследования с согласия работодателя (если VoIP — корпоративная сеть, и сотрудник предупреждён о мониторинге);
- При анализе собственных систем для тестирования безопасности.
В суд принимаются только те записи, которые получены с сохранением цепочки хранения (Chain of Custody). Практические правила:
1. Каждый этап работы должен быть задокументирован: кто, когда, с какого устройства, с использованием какой программы создал образ или PCAP.
2. Для захвата трафика используйте аппаратные TAP или коммутаторы с функцией Port Mirroring — это исключает внесение изменений в пакеты (в отличие от ARP-spoofing).
3. Все действия выполняйте на заведомо чистом компьютере-аналитике (Forensic Workstation) с ОС без лишнего ПО, с контролем хэшей.
4. Результаты восстанавливайте в read-only режиме, записывайте контрольные суммы (SHA-256) исходных данных и извлечённых файлов.
Если вы не сможете доказать, что RTP-поток не был подделан, — судья отклонит фонограмму. Поэтому используйте встроенные в Wireshark механизмы (проверка последовательности RTP, сравнение временных меток) и фиксируйте хэши.
Необходимое ПО и оборудование для анализа VoIP
Для выполнения задач, описанных в этой статье, вам потребуется набор программ, большинство из которых бесплатны и кроссплатформенны.
| Назначение | Название ПО | Лицензия |
|---|---|---|
| Захват трафика | tcpdump, Wireshark, TShark | GPL / бесплатная |
| Анализ SIP/RTP | Wireshark, SIPp, sipdump | GPL |
| Извлечение аудио из RTP | RTP Tools (rtpdump, rtpplay), Wireshark (Telephony->RTP->Save payload) | GPL |
| Конвертация кодеков | SoX, Audacity, FFmpeg | GPL |
| Автоматизация | Python + Scapy, PyShark | BSD / MIT |
| Работа с дампами памяти | Volatility (Vol3) + plugin rtpcache | GPL |
| Форензик образы | FTK Imager (AccessData), Guymager | бесплатно (FTK), GPL (Guymager) |
Оборудование: для захвата трафика в офисе вам понадобится управляемый коммутатор с SPAN-портом или Ethernet TAP (например, Dualcomm ETAP-2003). Для анализа одного компьютера достаточно запустить tcpdump на нём самом, но это добавит служебного трафика. В криминалистике часто используют аппаратный "разрыв" линии — устройство, копирующее все пакеты без задержек.
Совет: прежде чем приступать к реальному расследованию, создайте тестовый стенд с миниатюрной IP-АТС (например, Asterisk на Raspberry Pi) и двумя софтфонами (Zoiper, Linphone). Проведите серию звонков, запишите PCAP и отработайте методики восстановления — это повысит вашу компетентность.
Захват VoIP-трафика: от зеркалирования порта до PCAP-файлов
Первый практический шаг — получить файл с сетевыми пакетами. Рассмотрим 4 сценария захвата.
#### Сценарий А: У вас административный доступ к маршрутизатору / коммутатору
Настройте порт-зеркалирование (SPAN). Например, на Cisco Catalyst:
monitor
session 1 source interface gigabitethernet0/1 (порт телефона)
monitor session 1 destination interface gigabitethernet0/24 (порт анализатора)
На аналитик (компьютер, подключённый к порту 0/24) запустите захват:
sudo
tcpdump -i eth0 -s 0 -C 100 -G 600 -W 50 -w capture_%Y%m%d_%H%M%S.pcap
Параметры: -s 0 (весь пакет целиком), -C 100 (разбить по 100MB), -G 600 (менять файл каждые 10 мин). В итоге получите набор pcap-файлов без потери пакетов.
#### Сценарий Б: Захват на самом телефоне (не рекомендуется для криминалистики)
Некоторые IP-телефоны (Yealink, Grandstream) позволяют сохранить pcap через веб-интерфейс. Включите Capture → Start, совершите звонок, затем сохраните файл. Минусы: сам телефон может перегружаться, а захват несинхронизирован с другими потоками.
#### Сценарий В: Захват на ПК с софтфоном (для собственного тестирования)
Установите Wireshark, выберите интерфейс, нажмите "Start". Отфильтруйте по UDP (или RTP) после окончания. Сохраните как pcap.
#### Сценарий Г: Восстановление из уже изъятого образа диска
Если вам передали образ жёсткого диска сервера, вы можете извлечь pcap-файлы из дампа памяти (например, через Volatility plugin `linux_netfilter`). Или поищите логи tcpdump, которые администратор мог сохранять в `/var/log`. Для этого смонтируйте образ в read-only (в FTK Imager) и экспортируйте нужные папки.
Обязательно после получения pcap вычислите его хэш:
sha256sum
capture.pcap > capture.pcap.sha256
И сохраните этот файл отдельно — он подтвердит неизменность исходных данных в суде.
Извлечение метаданных звонка: SIP-заголовки и CDR-логи
Не всегда нужно восстанавливать аудио. Часто важны только метаданные: время, номера, факт соединения. Они извлекаются из SIP-сессии.
#### Работа с SIP в Wireshark
Откройте pcap в Wireshark, примените фильтр `sip`. Вы увидите методы: INVITE, 200 OK, ACK, BYE. Щёлкните правой кнопкой по любому пакету → Follow → SIP Stream. Откроется диалог со всей сессией. Оттуда скопируйте:
- `From`, `To` – номера или SIP URI.
- `Call-ID` – уникальный идентификатор звонка (позже по нему найдёте RTP).
- `User-Agent` – модель телефона/версия софта.
- `Timestamp` (время из PCAP, в UTC).
Для автоматического экспорта используйте TShark:
tshark
-r capture.pcap -Y "sip" -T fields -e frame.time_epoch -e sip.Call-ID -e sip.From -e sip.To -E header=y -E separator=, > sip_metadata.csv
В CSV окажутся все звонки с эпохальными временами.
#### Логи CDR (Call Detail Record) Asterisk
Если на сервере стоит Asterisk, зайдите в CLI (`asterisk -r`) и выполните:
cdr
show
Но для форензики лучше взять базу данных SQLite/MySQL. По умолчанию Asterisk хранит CDR в `/var/log/asterisk/cdr.csv`. Пример записи:
text
"2026-06-14 10:32:15","2026-06-14 10:35:22","101","+74951234567","SIP/101","SIP/trunk","Answer","200","180","32","12"
Поля: дата начала, окончания, caller, callee, длительность и статус. Заблокировать эту запись невозможно, если администратор не отключил CDR – но на практике он включён у 99% PBX.
#### Извлечение метаданных из WhatsApp / Telegram
На мобильном устройстве (Android) в папке `/data/data/com.whatsapp/databases/msgstore.db` есть таблица `calls`. Извлеките базу с помощью ADB (при полученном root или при работе с образом). Команда SQL:
select
_id, call_id, from_jid, to_jid, call_duration, call_timestamp, call_end_timestamp FROM calls;
Аудиофайлы (если не удалены) лежат в `/storage/emulated/0/WhatsApp/Media/WhatsApp Voice Notes/` — но это только голосовые сообщения, а не звонки. Полное аудио звонка end‑to‑end зашифровано. Но метаданные дата/время/абонент всегда в открытом виде в БД.
Вывод: метаданные – самая доступная улика. Всегда фиксируйте их даже при отсутствии аудио.
Восстановление аудиопотоков из RTP-сессий
Теперь переходим к главному — восстановлению разговора. Условие: в pcap присутствуют RTP-пакеты (не SRTP), либо у вас есть ключи расшифровки. Рассмотрим пошаговый протокол для Wireshark.
#### Шаг 1. Найдите RTP-поток
Откройте pcap в Wireshark. Используйте фильтр `rtp`. Либо перейдите в меню Telephony → VoIP Calls → выберите интересующий звонок → Graph. Появится диаграмма SIP-методов и RTP.
#### Шаг 2. Извлечение полезной нагрузки
В диалоге VoIP Calls нажмите на строку звонка → кнопка "Play Streams". Откроется окно "RTP Stream Analysis". Там будет график пакетов. Нажмите "Save Payload..." и выберите формат:
- `.raw` – сырой RTP-поток (только аудиоданные, без заголовков RTP);
- `.au` – для прослушивания в некоторых плеерах.
Лучше сохранить как `.raw`, затем конвертировать в WAV.
#### Шаг 3. Определите кодек
В том же окне "RTP Stream Analysis" Wireshark автоматически определяет кодек. Наиболее частые: G.711 µ-law или A-law (код 0), G.722 (код 9), G.729 (код 18), OPUS (код 118). Запомните его.
#### Шаг 4. Конвертация в WAV
Используйте ffmpeg. Например, для G.711 A-law (например, российские операторы):
ffmpeg
-f alaw -ar 8000 -ac 1 -i stream.raw stream.wav
Для G.729 понадобится специальная библиотека (OpenCore AMR). Можно использовать `sox`:
sox
-t raw -r 8000 -e a-law -c 1 stream.raw stream.wav
Если кодек OPUS (часто в мессенджерах):
ffmpeg
-f s16le -ar 48000 -ac 2 -i stream.raw stream.wav
(параметры зависят от того, какого формата payload сохранён; иногда `-f opus`)
#### Шаг 5. Проверка качества и синхронизация двух направлений
В телефонном разговоре два потока (A->B и B->A). Их нужно восстановить отдельно, затем смиксовать в один файл (стерео или по каналам). В Wireshark в окне RTP Stream Analysis выберите каждый поток по очереди, сохраните сырые. Затем в Audacity импортируйте оба монофайла, выровняйте их начало по огибающей (по визуальной форме волны) и экспортируйте в стерео.
Если пакеты терялись, RTP stream analysis покажет пропуски. Восстановить идеально невозможно, но можно применить интерполяцию в Audacity (Effect → Repair).
Важно: все действия с аудио должны быть задокументированы, а извлечённые WAV-файлы подписаны хэшем.
Работа с зашифрованными VoIP-звонками (SRTP, TLS)
Шифрование RTP (SRTP) или SIP over TLS – стандарт для современной защищённой телефонии. В большинстве случаев извлечь аудио без ключей невозможно. Но есть исключения и обходные пути.
#### Ситуация 1: Вы получили ключи законно
Если администратор системы предоставил мастер-ключ или ключи сессии (например, в настройках FreeSWITCH можно включить логирование ключей SRTP в файл), то:
- Для Wireshark есть поддержка SRTP: Preferences → Protocols → RTP → добавить ключ (в hex).
- Или используйте `srtp-decrypt` из пакета `libsrtp-tools`:
srtp
-decrypt --key 0123456789ABCDEF0123456789ABCDEF --stream capture.pcap > decrypted.rtp
#### Ситуация 2: У вас есть дамп памяти процесса (например, Asterisk)
В памяти могут находиться ключи в незашифрованном виде. Алгоритм (только для законного тестирования своей системы):
1. Получите дамп процесса `asterisk`: `gcore $(pidof asterisk)`
2. Выполните поиск сигнатуры ключей (например, 16 байт, следующих за меткой `srtp_key`). Это сложно, но существуют скрипты на GitHub для Volatility.
3. Используйте найденный ключ для расшифровки.
#### Ситуация 3: Анализ метаданных вместо аудио
Даже при SRTP вы можете извлечь те же SIP-заголовки (они чаще всего идут по незашифрованному TCP или TLS, но если TLS с сертификатом компании, можно перехватить сессию через MITM-прокси при легальном доступе к серверу). В противном случае остаются только временные метки пакетов и их размеры – из них можно сделать вывод о факте передачи данных, но не о содержании.
Важное предупреждение: Не используйте методы грубого взлома шифрования в реальных расследованиях без разрешения – это нарушает закон "О связи" и УК. Если SRTP применён корректно и ключи не изъяты, честно укажите в заключении: "Восстановление аудио невозможно, предоставлены только метаданные, полученные из SIP-логов".
Продвинутые техники: анализ пауз, шумов и встраиваемых меток
Даже если разговор восстановлен, можно извлечь дополнительную информацию.
#### Анализ акустической обстановки (например, определение места звонка)
Используйте спектрограмму в Audacity (Analyze → Plot Spectrum). Фоновый шум может выдать: движение поезда (низкочастотный гул, 50/100 Гц электрической сети – возможно, рядом розетка), голоса третьих лиц, специфические звуки (кассовый аппарат). Это дополнительные улики, которые нельзя вставить в протокол как "дословное содержание", но можно как экспертную оценку.
#### Обнаружение монтажа и склейки
Подайте восстановленный WAV в программу проверки цифровой целостности, например, `TCR Audio Forensic Toolkit`. Она ищет разрывы в спектре, неестественные паузы, дублирующиеся фрагменты. В открытом доступе есть скрипты для Python с использованием библиотеки `librosa`. Показатели: корреляция между каналами, постоянство шума.
#### Извлечение DTMF-сигналов (нажатия кнопок)
Если в RTP-потоке есть тоновые сигналы (RFC 2833 или внутри аудио), Wireshark может показать DTMF как отдельные события (вкладка Telephony → RTP → Show DTMF). Также можно проанализировать спектрограммой Audacity – цифры 1-9, 0, *,# имеют характерные частотные пары.
Эти методы не требуют полного дешифрования и часто дают ключевую информацию: например, пин-код, введённый во время звонка в голосовом меню.
Альтернативные источники: резервные копии, логи прокси и история клиентов
Если у вас нет сетевого трафика, вы всё ещё можете восстановить факты звонков.
Облачные PBX (например, Zadarma, Yandex.Telephony, Mango Office, 3CX Cloud) хранят:
- Детализацию (CDR) – обычно доступна через API или скачивается в CSV.
- Аудиозаписи разговоров, если включена опция "Запись звонков". Эти записи законны при уведомлении сотрудников.
Протокол: авторизуйтесь как администратор, перейдите в раздел "Отчёты" → "Детализация звонков" → экспорт за нужный период. Для каждой записи будет ссылка на MP3/WAV.
Логи прокси-серверов (Squid, Nginx, если телефония идёт через HTTP-API). Иногда запросы к API управления звонками содержат параметры call_id, дату, статус. Но это косвенный метод.
История вызовов на мобильном телефоне (изъятом при обыске): даже без root на Android вы можете сделать резервную копию через `adb backup` и извлечь базу `calllog.db`. Но полный разговор оттуда не восстановить, только метаданные.
Автоматизация анализа с помощью Python и TShark
Если нужно обработать десятки PCAP-файлов с большим количеством звонков, ручной метод из Wireshark неэффективен. Напишем простой скрипт на Python, который находит все RTP-сессии и сохраняет их в виде аудиофайлов.
python
import subprocess
import os
import csv
def get_rtp_streams(pcap_file):
# Используем tshark для получения списка всех RTP-потоков в формате JSON
cmd = [
"tshark", "-r", pcap_file,
"-Y", "rtp",
"-T", "fields",
"-e", "rtp.ssrc", "-e", "ip.src", "-e", "udp.srcport",
"-e", "ip.dst", "-e", "udp.dstport",
"-E", "header=n", "-E", "separator=,"
]
result = subprocess.run(cmd, capture_output=True, text=True)
streams = set()
for line in result.stdout.strip().split('\n'):
if line:
parts = line.split(',')
streams.add((parts[0], parts[1], parts[2], parts[3], parts[4]))
return streams
def extract_audio_for_stream(pcap_file, ssrc, src_ip, src_port, dst_ip, dst_port, out_raw):
# Фильтр для конкретного потока (SSRC)
filter_expr = f"rtp.ssrc == {ssrc}"
cmd_extract = [
"tshark", "-r", pcap_file,
"-Y", filter_expr,
"-T", "fields", "-e", "data.data"
]
# Сохраняем hex-данные payload
payload_hex = subprocess.run(cmd_extract, capture_output=True, text=True).stdout
# Конвертируем hex в бинарный raw-файл (упрощённо)
with open(out_raw, 'wb') as f:
for line in payload_hex.split():
if line:
f.write(bytes.fromhex(line))
<h2 id="primer-ispolzovaniya">Пример использования</h2>
pcap = "calls.pcap"
streams = get_rtp_streams(pcap)
for i, stream in enumerate(streams):
ssrc, src_ip, src_port, dst_ip, dst_port = stream
raw_file = f"stream_{i}_ssrc_{ssrc}.raw"
extract_audio_for_stream(pcap, ssrc, src_ip, src_port, dst_ip, dst_port, raw_file)
# Далее вызываем ffmpeg для конвертации на основе эвристики (можно распознать кодек по ssrc? нет - придётся анализировать.)
Полноценный скрипт учитывал бы определение кодека (из SDP в SIP-пакетах), поэтому отдельно нужно проанализировать SIP-сессии и сопоставить их с RTP по портам. Для реальной работы используйте готовую библиотеку `pyrtp` или `voip-forensics-toolkit` на GitHub.
Проблемы цепочки хранения и аутентификации записей
В цифровой криминалистике без правильного оформления даже идеально восстановленное аудио не будет принято. Вот чеклист для эксперта:
- Исходный носитель: протокол изъятия, фотографии, опечатывание.
- Образ: создан на записываемом устройстве (например, Tableau TD3), подтверждён хэшем (MD5 и SHA-256) с подписью эксперта.
- Работа с образом: только через write-blocker (например, Tableau USB Write Blocker). Каждое подключение фиксируется в журнале.
- Программное обеспечение: версии должны быть задокументированы. Для Wireshark – номер и контрольная сумма установочного файла.
- Извлечённые файлы (WAV, CSV): сопровождаются хэшем и подписью. Время создания файла должно быть синхронизировано с NTP-сервером лаборатории.
- Повторяемость: другой эксперт, используя те же образы и инструкции, должен получить идентичные результаты (за исключением временных меток). Это критерий научности.
Если вы готовите экспертное заключение, обязательно приложите распечатки экранов из Wireshark с фильтрами и результатами анализа VoIP Calls. Скриншоты должны содержать временную шкалу и полные пути к файлам.
Часто задаваемые вопросы (FAQ) по VoIP-форензике
1. Можно ли восстановить разговор из WhatsApp, если нет доступа к устройству, но есть перехваченный трафик?
Нет, трафик WhatsApp зашифрован Signal Protocol (end-to-end). Без ключей с одного из устройств расшифровать аудио невозможно. Только метаданные из TLS-хендшейка (время, размеры пакетов) не восстанавливают речь.
2. Что делать, если RTP-поток содержит пропуски пакетов (jitter)?
Используйте Audacity или Adobe Audition для интерполяции (восстановления пропущенных фрагментов по соседним). Но будьте осторожны: интерполяция изменяет исходный сигнал, суд может отвергнуть такую фонограмму. Лучше эксперт указать, что "аудиофайл имеет потери, дословное содержание частично утрачено".
3. Какой минимальный размер PCAP для восстановления разговора длительностью 1 минуту (кодек G.711)?
G.711 кодирует 64 кбит/с. Итого 64*60 = 480 кбайт плюс заголовки RTP/UDP/IP (около 40 байт на пакет, пакет каждые 20 мс = 3000 пакетов). Итоговый размер около 1 МБ. Для G.729 (8 кбит/с) ~ 120 КБ. Но на практике добавляются SIP-пакеты.
4. Можно ли подделать временную метку звонка в PCAP?
Да, tcpdump позволяет записывать пакеты с произвольным временем (`-t`). Поэтому суду предоставляют не просто PCAP, а образ памяти системы, на которой этот PCAP был сделан, с логами синхронизации по NTP. Если доступа к образу нет – доказательство слабое.
5. Как восстановить звонок, если использовался кодек G.729 и нет лицензионного декодера?
Используйте OpenCore AMR (библиотека opencore-amr) – она содержит декодер G.729. В ffmpeg собранной с `--enable-libopencore-amrwb` будет поддержка. Или `asterisk -r` с модулем codec_g729 (но это проприетарно).
6. Помогают ли "сетевые звуковые карты" (RTP-миксеры) в форензике?
Нет, их применение не даёт юридически значимого результата, так как они изменяют пакеты. Только пассивный захват (TAP, SPAN) разрешён.
7. Какая частота дискретизации достаточна для идентификации голоса?
Для судебно-фонографической экспертизы (идентификация человека) требуется 16 кГц, но из VoIP вы получите максимум 8 кГц (кроме OPUS/AMR-WB). С 8 кГц идентификация возможна, но менее точна; эксперт сделает оговорку.
8. Что означает "серый шум" в восстановленном аудио?
Это либо неверно указанный кодек, либо пакетная потеря, либо наложение шифрования. Проверьте параметры декодирования (alaw vs ulaw) и настройку jitter буфера.
9. Могу ли я использовать онлайн-сервисы для восстановления RTP?
Не рекомендуется: это нарушает конфиденциальность и цепочку хранения. Вся работа должна проводиться на изолированном offline-аналитике.
10. Как определить, что разговор был записан на стороне абонента (например, на диктофон)?
В сетевом PCAP вы это не увидите. Но если у вас есть доступ к устройству – ищите файлы аудиозаписи в папках приложений, логах Bluetooth (если использовалась гарнитура).
11. Какой инструмент даёт самую детальную статистику по RTP (джиттер, потеря пакетов)?
Wireshark (статистика → RTP Stream Analysis → Graph). Платные – Colasoft Capsa, но бесплатный Wireshark достаточен.
12. Можно ли восстановить звонок, если в pcap есть только RTP-часть, но нет SIP?
Да, RTP-поток содержит только аудио. Вы не узнаете номера абонентов, но само аудио можно извлечь. Для идентификации направлений используйте IP-адреса.
13. Есть ли способ восстановить аудио из Telegram Desktop на Windows без анализа трафика?
Да. База `%AppData%\Telegram Desktop\tdata` содержит файл `cache` с медиа. Однако звонки Telegram используют шифрование, и аудио там нет, только метаданные в `D877F783D5D3EF8C\user_data#.../settings` (SQLite). Извлеките `call.log`.
14. Что делать, если финальный аудиофайл слишком тихий?
Примените нормализацию в Audacity (Effect → Normalize). Но эксперт должен сохранить оригинальный громкий и нормализованную копию, указав применённые фильтры.
15. Можно ли автоматически расшифровать SRTP, если есть перехват регистрации SIP с паролем?
Нет, пароль регистрации не является ключом SRTP. Ключи генерируются через обмен DTLS или SDES (который идёт в SIP по незащищённому каналу). Если SDES виден в открытом виде (SIP без TLS), то вы можете извлечь ключи из заголовков `crypto`. В Wireshark это автоматически.
Заключение: итоговый алгоритм эксперта-криминалиста
Подведём итог и выстроим порядок действий при назначении VoIP-форензической экспертизы.
1. Определить источники – есть ли доступ к PCAP, логам PBX, резервным копиям, устройству абонента.
2. Легализовать процедуру – получить разрешение на перехват или назначение экспертизы, зафиксировать цепочку хранения.
3. Создать образы – сетевым TAP или изъятым жёстким диском с помощью write-blocker.
4. Извлечь метаданные – SIP/CDR через Wireshark, tshark, SQL-запросы к базам клиентов.
5. Восстановить RTP-аудио – используя функцию "RTP Stream Analysis" в Wireshark, сохранить payload, сконвертировать ffmpeg под кодек.
6. Обработать аудио – при необходимости нормализация, интерполяция (с пометкой), выделение DTMF.
7. Дополнительная информация – спектрограмма, акустический анализ (шум, помехи).
8. Документирование – хэши всех файлов, скриншоты, версии ПО, описание шагов в экспертном заключении.
9. Архивация – все файлы упаковать в zip с паролем (пароль в отдельном акте), передать следователю.
VoIP-форензика – одна из самых быстрорастущих областей цифровой криминалистики. Умение работать с SIP, RTP, логами и аудио-конвертацией становится обязательным для современного эксперта. Применяйте методы из этого руководства ответственно и только в правовом поле.
Если вам понадобилась автоматическая обработка большого числа файлов – используйте Python скрипты и утилиты командной строки (tshark, ffmpeg). Но помните: автоматизация не отменяет необходимость ручной проверки каждого ключевого звонка.
Предупреждение: Статья носит образовательный характер для специалистов по информационной безопасности и сотрудников правоохранительных органов.