Анализ MITM-атаки в клиенте Telega для ВКР: модель угроз и верификация сборок
В марте 2026 года вышло исследование, посвящённое неофициальному Android-клиенту Telega. Авторы утверждают: в код внесены правки, которые отключают часть криптографических проверок Telegram и открывают дорогу для атаки «человек посередине» (MITM). Формально клиент собран из исходников официального приложения под GPLv2, но изменений никто не раскрыл — а лицензия этого требует. Для выпускника ИТ-направления это не просто новость, а готовый кейс: он бьёт сразу по трём темам, которые ценят в комиссиях — криптография в мобильных приложениях, анализ целостности сторонних сборок и юридическая сторона открытых лицензий. Ниже — как превратить этот случай в осмысленную ВКР, а не в пересказ статьи.
Три темы ВКР, которые вырастают из этой новости
Тема 1. Модель угроз и оценка защищённости мобильных мессенджеров (кейс Telega)
- Актуальность: инцидент показывает, что доверие к форку строится на предположениях, а не на проверке. В официальном Telegram защита от MITM опирается на связку MTProto и проверку ключей, а в Telega, по данным исследования, эти механизмы ослаблены.
- Цель: построить формализованную модель угроз для альтернативного клиента и оценить остаточный риск.
- Задачи: классифицировать угрозы по STRIDE; сопоставить их с перечнем MITRE ATT&CK Mobile; рассчитать риски по CVSS; предложить контрмеры и оценить их стоимость.
- Структура: Глава 1 — обзор протоколов и типовых атак на транспорт; Глава 2 — построение модели угроз и дерева атак; Глава 3 — расчёт остаточного риска и рекомендации по внедрению.
Тема 2. Методика верификации сторонних сборок Android-приложений
- Актуальность: Telega распространяется как APK, и пользователь не может убедиться, что бинарник соответствует открытым исходникам. Задача проверки «сборка = исходник» сегодня решается не системно.
- Цель: разработать методику и прототип инструмента, подтверждающего соответствие APK опубликованному коду.
- Задачи: описать процесс воспроизводимой сборки; применить статический анализ (SAST) к декомпилированному коду; сравнить хеши артефактов; оформить отчёт о расхождениях.
- Структура: Глава 1 — лицензия GPLv2, требования к раскрытию изменений, реверс-инжиниринг; Глава 2 — архитектура инструмента и пайплайн CI/CD; Глава 3 — испытания на наборе из N клиентов, метрики точности.
Тема 3. Подсистема контроля целостности и certificate pinning для корпоративного мессенджера
- Актуальность: организации всё чаще разворачивают закрытые мессенджеры. Кейс Telega — прямой аргумент в пользу встроенной проверки целостности клиента и закрепления сертификатов.
- Цель: спроектировать и реализовать модуль, который делает подмену трафика и модификацию APK обнаруживаемой.
- Задачи: реализовать pinning на уровне сетевого стека; добавить проверку подписи и хеша критичных классов; описать поведение при срабатывании; провести нагрузочное тестирование.
- Структура: Глава 1 — анализ решений (Signal, Element, официальный Telegram); Глава 2 — проектирование модуля, UML-диаграммы; Глава 3 — тестирование, замеры задержек и экономика внедрения.
Аналитическая глава: как обосновать выбор и не утонуть в обзоре
Сравнительный раздел пишут почти все, но защищаемым он становится, когда сравнение привязано к критериям. Возьмите набор из ISO/IEC 25010 (функциональная полнота, защищённость, сопровождаемость) и дополните его отраслевыми требованиями: наличие reproducible build, публикация изменений, независимый аудит. Кейс Telega в этой логике — опорная точка: у него провалены сразу два критерия — прозрачность сборки и защищённость канала.
| Клиент | Лицензия и раскрытие правок | Защита от MITM | Воспроизводимая сборка | Пригодность для корпоративного контура |
|---|---|---|---|---|
| Официальный Telegram | GPLv2, исходники публикуются | MTProto, проверка ключей | Частично | Средняя |
| Telega | Форк без раскрытия изменений | Ослаблена по данным исследования | Нет | Низкая |
| Signal | GPLv3, полные исходники | Double Ratchet, pinning | Да | Высокая |
| Element (Matrix) | Apache 2.0 | Olm/Megolm, pinning | Да | Высокая |
Обязательно добавьте абзац о том, почему выбранный стек подходит именно вашей задаче. Фраза «взяли Python, потому что он популярный» — минус балл. Фраза «Kotlin выбран из-за нативной интеграции с Android SDK и наличия библиотек для работы с X.509, что сокращает объём кода проверки сертификата на 30 %» — плюс балл.
Проектная часть: от модели угроз к архитектуре
Здесь кейс Telega превращается в конкретные схемы. Минимальный набор, который стоит нарисовать:
- диаграмму потоков данных (DFD) с границами доверия — отдельно для легитимного клиента и для скомпрометированного;
- дерево атак: корень — «компрометация канала», ветви — подмена сертификата, отключение pinning, модификация кода проверки;
- компонентную схему модуля защиты: перехват сетевых вызовов, хранилище отпечатков, обработчик инцидента.
Если пишете инструмент верификации сборок, покажите конвейер целиком. Ниже — скелет шага сборки, который можно вставить в приложение к диплому.
stages:
- build
- analyze
- compare
build:
script:
- ./gradlew clean assembleRelease
- sha256sum app/build/outputs/apk/release/app.apk > build.sha256
analyze:
script:
- apktool d app/build/outputs/apk/release/app.apk -o decompiled
- semgrep --config=security-audit decompiled/ > sast-report.json
compare:
script:
- diff -r decompiled_upstream/ decompiled/ > diff-report.txt
- python scripts/verify_hash.py build.sha256 published.sha256
Хорошо работает приём «контрмеры против угроз»: каждая ветвь дерева атак получает строку в таблице с описанием технического решения и оценкой трудоёмкости. Именно эта таблица потом становится основой выводов по второй главе.
Тестирование и метрики: чем измерять защищённость
Самая частая претензия комиссии — «где цифры?». Для темы безопасности цифры есть, просто о них забывают. Опирайтесь на четыре группы:
| Группа | Метрика | Как получить |
|---|---|---|
| Уязвимости | CVSS-оценка, число находок по уровням | SAST (Semgrep, MobSF), ручной аудит |
| Производительность | Прирост задержки рукопожатия, мс | Нагрузочный прогон с pinning и без него |
| Надёжность | MTTR, доля обнаруженных подмен | Стенд с подставным прокси |
| Восстановление | RTO/RPO для серверной части | Сценарии отказа, ГОСТ 34.602-89 в ТЗ |
Для стенда подойдёт mitmproxy с собственным корневым сертификатом: он наглядно показывает, что происходит, когда клиент проверяет цепочку, и что — когда проверку отключили. Сценарий «до/после» с числами выигрышно смотрится в презентации к защите.
Чему вы научитесь на такой работе
- Строить модель угроз и связывать её с архитектурными решениями, а не с перечислением книжных атак.
- Работать с инструментами статического и динамического анализа мобильных приложений.
- Обосновывать стек через измеримые критерии, а не через личные предпочтения.
- Оформлять техническую документацию по ГОСТ 34.602-89 и оценивать качество по ISO/IEC 25010.
- Разбираться в лицензионных требованиях GPLv2 и в том, чем грозит их нарушение.
- Подмена понятий «форк», «сборка» и «клиент». Форк — это репозиторий с изменениями, сборка — артефакт, клиент — приложение у пользователя. Смешение терминов ломает всю логику главы. Решение: заведите глоссарий в начале работы и держитесь его.
- Отсутствие измеримых метрик. Утверждение «стало безопаснее» без CVSS, задержек и доли обнаружений не защищается. Решение: привяжите каждую контрмеру к конкретному числу.
- Игнорирование ГОСТ 34.602-89 при оформлении ТЗ. Разделы «Требования к системе» и «Стадии разработки» пропускают, и комиссия это замечает. Решение: скачайте актуальную редакцию и оформите ТЗ по её структуре.
Частые вопросы
Обязательно ли писать рабочий код для ВКР по этой теме?
Не всегда. Для тем уровня «модель угроз» и «методика оценки» достаточно аналитической части и расчётов. Если тема заявлена как проектная, прототип нужен: даже модуль на 500 строк с прогоном тестов выглядит убедительнее, чем одна теория.
Где брать данные для тестирования?
Публичные репозитории клиентов, официальные APK с сайтов проектов, учебные стенды на mitmproxy и эмуляторах Android. Все действия — только на своём оборудовании и только с открытыми сборками, иначе вопросы будут уже не к комиссии.
Как оформить UML и схемы, чтобы их приняли?
Используйте diagram-as-code: PlantUML или Mermaid в репозитории. Схема живёт рядом с кодом, легко обновляется и не превращается в набор несогласованных картинок из разных редакторов. Экспорт — в SVG для печати.
Насколько сложно защищать такую тему?
Сложность средняя. Плюс в том, что тема свежая и комиссия о ней наслышана. Минус — придётся разобраться в криптографическом протоколе и в лицензиях. Зато на защите не будет вопроса «а зачем это нужно?».
Что проверить перед сдачей
- Ссылки на источники оформлены с датой публикации и работают.
- Каждая задача из введения отражена в выводах по главам.
- Есть минимум три схемы: DFD, дерево атак, архитектура решения.
- Метрики приведены с единицами измерения и условиями замера.
- ТЗ и ПМИ соответствуют ГОСТ 34.602-89 и ГОСТ 34.603-92.
- Все заимствования из открытого кода снабжены указанием лицензии.
Как писать текст, чтобы комиссия поверила
Есть простой приём: любой абзац аналитической главы заканчивайте фразой с указанием следствия. Не «рассмотрены существующие клиенты», а «из четырёх рассмотренных клиентов только два обеспечивают воспроизводимую сборку, что и обосновывает разработку собственного модуля проверки». Тогда описанный в новости случай Telega становится не иллюстрацией, а доказательной базой вашей работы. И помните: помощь с дипломом имеет смысл тогда, когда вы понимаете свою тему хотя бы в общих чертах — на защите говорить придётся вам, а не консультанту.
Источник: В Telega, альтернативном клиенте Telegram, выявили возможность совершения MITM-атаки (опубликовано 2026-03-24)