ZaStoGram

Экспериментальный форк официального Telegram для Android. Цель форка — сделать подключение к MTProxy FakeTLS (ee-секрет) менее похожим на стандартный Telegram MTProxy-трафик и ближе к обычному браузерному HTTPS.

Это не новый мессенджер и не отдельный протокол. База остаётся официальным Telegram Android, а изменения сосредоточены вокруг MTProxy/FakeTLS-пути.

Простыми словами MTProxy — прокси для Telegram. FakeTLS — режим MTProxy, где начало соединения выглядит как TLS/HTTPS. DPI / ТСПУ — оборудование провайдера, которое классифицирует и режет трафик по признакам на проводе. JA4 — отпечаток TLS ClientHello. По нему можно отличить настоящий браузер от синтетического FakeTLS, если ClientHello сделан плохо. Проблема MTProxy не только в одном хеше. DPI может смотреть на TLS-рукопожатие, временные интервалы, размеры записей, количество одновременных соединений и поведение после рукопожатия. Поэтому здесь важна аккуратная маскировка без поломки MTProto.

Что сейчас реализовано Путь MTProxy FakeTLS от tsrman-коммита В активном пути транспорта сохранено поведение, близкое к рабочему tsrman/tg-варианту:

ClientHello отправляется целиком одним send(); фаза данных использует стабильное фиксированное ограничение 2878 байт; рискованные эксперименты с динамическим размером TLS-записей сейчас убраны из активного пути. Это важно для надёжности: сначала соединение должно стабильно работать, и только потом можно снова усиливать маскировку фазы данных.

Стабильный выбор TLS-профиля Для MTProxy FakeTLS выбранный TLS-профиль теперь не меняется хаотично на каждое соединение. Профиль выбирается стабильно по адресу прокси, секрету и локальной соли.

Сейчас в пуле:

Firefox; Android Chrome; Firefox Android; Android OkHttp; Yandex. Так разные установки и разные прокси могут получать разные сетевые отпечатки, но один конкретный адрес прокси не прыгает между профилями каждую секунду.

Защитные проверки ClientHello Перед отправкой ClientHello проверяется на базовую совместимость с MTProxy:

корректная TLS-запись и длины; ожидаемое смещение списка наборов шифров; первый шифр не из GREASE относится к TLS 1.3 TLS_AES_*; наличие SNI-домена из ee-секрета; размер в пределах серверного лимита. Это защищает от красивого, но несовместимого ClientHello.

Рандомизация внутри ClientHello Оставлены низкорисковые элементы маскировки:

случайные поля ClientHello; случайные ECH-данные там, где профиль их использует; случайная цель расширения заполнения вместо старого фиксированного размера; безопасная генерация GREASE-значений без выхода за границы массива. Планировщик MTProxy-подключений Для ee FakeTLS добавлен контроллер допуска подключений к одному адресу прокси. Он ограничивает не скорость уже установленного MTProto-трафика, а только залп одинаковых попыток connect -> ClientHello -> server_hello_hmac_ok к одному адресу прокси.

Ключ планировщика: адрес прокси:порт:SNI.

В текущей диагностической сборке активная очередь рукопожатий временно выключена флагом MT_PROXY_HANDSHAKE_ADMISSION_ENABLED = false: настоящий connect() снова запускается сразу, как в базовом транспортном пути. Это нужно, чтобы отделить баги нашего admission-controller от внешнего freeze/блокировки прокси.

Код планировщика оставлен для следующего этапа. Когда он включён, его задача:

держать максимум одно активное FakeTLS-рукопожатие на адрес прокси; после недавних успешных server_hello_hmac_ok поднимать лимит до двух; ставить новые рукопожатия в очередь по приоритету: Generic/Temp -> GenericMedia -> Push -> Download -> Upload; не пропускать служебную проверку прокси через жёсткую очередь, чтобы не получать ложный результат "прокси не работает" из-за ожидания слота; освобождать слот сразу после server_hello_hmac_ok, чтобы загрузка и отправка файлов после подключения шли параллельно как раньше. Зависания в фазе client_hello_sent сейчас только логируются; штрафной cooldown тоже временно выключен, чтобы клиент сам не переводил живые прокси в долгое состояние "недоступен" во время диагностики блокировок.

Это сделано против узнаваемого залпового шаблона, когда клиент почти одновременно открывает много одинаковых FakeTLS-соединений к одному прокси. Жёсткий режим типа "один SYN в секунду" не используется: он слишком грубо замедляет Telegram и сам может стать странной сигнатурой.

Диагностика запуска подключения Добавлены диагностические точки для MTProxy-подключения:

connect_start; socket_connected; client_hello_sent; server_hello_hmac_ok; on_connected; mtproxy_disconnect с причиной и состоянием; admission_grant, admission_queue, admission_release, admission_disabled, admission_freeze_detected, admission_freeze_observed. Это нужно, чтобы отличать DPI-обрыв от багов в нашем транспортном пути.

Корректная досылка неполной TLS-записи Для обёрнутых TLS-записей добавлена очередь ожидающей отправки записи: если send() отправил только часть TLS-записи, остаток досылается как продолжение той же записи, а полезная нагрузка MTProto не выбрасывается раньше полной отправки.

Как пользоваться Подними MTProxy с FakeTLS вне зоны блокировки. Используй ee-секрет с доменом. В приложении добавь MTProto-прокси обычным способом: Настройки -> Данные и память -> Прокси -> Добавить прокси -> MTProto. Маскировка из этого форка применяется именно к FakeTLS/ee-секрету. Для обычных dd-секретов и других вариантов без FakeTLS эти изменения не дают того же эффекта.

Честные ограничения SNI не ротируется сам по себе. Он берётся из ee-секрета. Фаза данных пока не имитирует настоящий HTTP/2 или HTTP/1.1. Динамический размер TLS-записей сейчас не включён в активный путь. Планировщик ограничивает только фазу открытия FakeTLS-соединения. Он не пытается полностью замаскировать статистику уже установленного MTProto-трафика. Это не гарантия вечного обхода блокировок: DPI-правила меняются. Это неофициальный форк, использовать его нужно с пониманием рисков.