Хм… И как это поможет с обходом блокировок? Я так понял, рабочего рецепта для доступа к сайтам на OVH-хостинге нет и не предвидится даже.
Будет ли в таком случае реализована поддержка MTProto? Сейчас как я понимаю её нет.
Может где-то есть мануал по поиску стратегий для Запрета в ситуациях, когда блокчек говорит, что ничего не блокируется, но по факту сайт недоступен?
Или другая ситуация: сайт с помощью Запрета открывается, но видео потом не работает - похоже на замедление ютуба, но это не ютуб и стратегии ютуба на нём не работают.
Есть ли смысл прогонять блокчеком с запущенным Запретом именно в такой ситуации? Да, я знаю, что блокчек требует отключения запрета и т.п., но вдруг?
mtproto сигнатурно не детектируется.
Дуров его спецом таким сделал, чтобы не могли блокировать по протоколу.
За что ему уважуха.
Хоть и коммерческий месенджер, но создавали его люди с идеей в голове, а не баблом в заднице
я наверное совсем дурень, но я не могу подобрать стратегию для запрета, блокчеком оно мне несколько выдало, но делает только хуже походу, нужное не открывается, а что раньше и так работало - тоже xастично ломается
я както больше с паяльником дружу чем с сетевым стеком
Теоретически ведь можно деобфусцировать mtproto, наподобие квика, как здесь. Там ключ и IV в первых 56 байтах tcp соединения, после дешифровки AES-256-CTR смотреть на 4 байта с офсета 56 для сигнатуры
блокчек не поможет с 16кб блоком, теоретически его можно дописать до варианта запросов , как у dpi чекера. (там вроде проверяется объем трафика за время)
но я не погромист
Если бы это было так, то можно сказать вся коммуникация телеги нешифрована, тк шифрование чисто косметическое. Вряд ли это так.
That “authorization key”, used to encrypt messages between a client and a server, is negotiated once on each device
должен быть протокол начального согласования ключей - key agreement.
shared secret отсутствует. значит процедура должна основываться на ассиметричном крипто. diffie-hellman, например, или что-то подобное.
это может согласовываться при первом конекте клиента, дальше в протоколе есть только какой-то случайный идентификатор в начале, по которому не сказать, что это телега
Добрый вечер
После моих многомесячных исследований, я обнаружил новый вид блокировки
Первые 64 КБ Трафика идет успешно, после этого соединение зависает или уходит в таймаут
Очень точно и актуально
Интернет перестаёт быть доступным по принципу - ТЫК
Всё в точку.
@bolvan А сколько будет стоить обучение у вас? Как подбирать стратегии и т.д.
я не предоставляю платных услуг
без понимания основ сетевой инженерии учить будет тяжело
Но быть может, есть какая-то отправная точка? Читал когда-то “Компьютерные сети” от Олиферов. Помню очень мало уже что оттуда, но не уверен, что это вообще имеет отношение к обходу блокировок. Что еще почитать порекомендуете именно в контексте работы с Запретом?
Deepwiki в помощь, спрашиваешь о стратах, как та или иная функция работает и засчёт этого делаешь
Я говорю не о том, что не юзается шифрование, я про то, что после деобфускации видно 4 одинаковых байта, определяющих транспортный протокол и auth_key_id, который у меня в пределах одной сессии на девайсе и одного айпишника сервера тг был одним и тем же даже для разных соединений. То есть не только можно определить что это mtproto, но даже девайс можно идентифицировать. Вопрос - почему не банят? Ресурсов не хватает на деобфускацию?
Только что снял дамп шарком с двух разных андроидов, если деобфусцировать первый tcp сегмент с пейлоадом к серверам телеги, то байты 57-60 всегда были 0xefefefef, как и в примере из спецификации:
The protocol identifier, if present, must be inserted in the initialization payload at byte offset
56: if its length is less than 4, it must be padded using the protocol identifier itself, to make its length 4 (0xef=>0xefefefef): the standalone protocol identifier must be not be sent aftwerwards.
т.е используется транспортный протокол abridged. Дальше скипаем 4 байта и идет либо один байт = длина пейлоада/4, либо 0x7f и три байта длины/4 в little endian. Потом 8 байт auth_key_id и дальше шифрованный пейлоад. В одном tcp сегменте может быть несколько таких сообщений.
Сам процесс деобфускации простой: aes-256-ctr декриптится весь первый tcp сегмент, ключ - 9-40 байты сегмента, IV - 41-56 байты. Первые 56 байт результата рандомный мусор.
К своему удивлению совсем недавно обнаружил данный ресурс и был потрясен детальностью документации и схем. Неужели это действительно сделано с помощью AI, релевантно и бесплатно? Просто безумие. Мне для поверхностного разбора документации потребовались месяцы самостоятельного изучения основ с помощью платных генеративных моделей (задание полного контекста, ограничение галлюцинаций) и то, я не могу сказать, что до конца понимаю, как именно работает та или иная стратегия/параметр.
Приношу извинения за оффтоп.
Подскажите,
оч.мало упоминаний –hostpad=хх в темах.
Что если 16кб закинуть мусора в начале пакета, чтобы текущую проблему ip16-20 м.б. решить для лимитных роутеров у которых только tpws?
Или оно не для этого..
В twps мало опций.
(p.s. года-полтора хватало tpws –disorder --split-pos=2 . но пару дней назад все поменялось)
Можете пример привести своего дампа hex ?
и успешную расшифровку через openssl ?
Работает только для http. В https ничего всунуть невозможно
Launcher for Zapret теперь и не работает для обхода.