Залей скомпилированную версию под винду с obb
Большое спасибо
техники OOB и tlsrec работают в России в основном только на TLS1.3
На 1.2 rdp-шный DPI сечет ответ сервера и сбрасывает
Новая версия!
Добавлена поддержка oob.
Методы запутывания были перенесены в отдельные опции.
Теперь их можно комбинировать, указывая свой метод для определенной позиции.
Позиций указывать можно сколько угодно, при этом можно добавить флаг смещения, например:
./ciadpi --disorder 3 --oob 1+sni --split -1+host --tlsrec 1 --tlsrec +sni
Теперь можно подкорректировать поведение disorder в Windows:
./ciadpi -s 3+s -d 20+s
Первый пакет будет содержать часть с первыми 3-мя байтами SNI
Второй - часть после SNI
Третий - SNI без первых 3-х байт и всю вторую часть
А чем отличается данная прога от TPWS? На первый взгляд функционал обеих программ одинаковый
byedpi может быть менее стабильным, чем tpws, не содержит некоторых опций, таких, как hostlist, bind-wait и пр. Но он позволяет совершать более запутанные аттаки, такие как fake, отсылка нескольких oob байт подряд, разбиение по нескольким позициям.
В следующей версии планируется добавить параметры --auto и, возможно, --redirect. Работать это будет так:
./ciadpi --auto --disorder 3 --auto --tlsrec 1+s --auto --redirect 127.0.0.01:1090
Сначала будет произведена попытка соединиться без запутывания, если она не удалась, то будет применен --disorder, после неудачи --tlsrec, и если и она не сработала, то подключение перенаправится на другой socks прокси, например, на локальный shadowsocks.
Если одна из попыток удалась, то IP сайта будет сохранен, чтобы впредь вновь не перебирать параметры, но только на определенное время, по умолчанию на 6 часов.
Это поможет минимизировать поломки, т.к. одни параметры могут быть действенны для одних сайтов, но при этом ломать другие.
Кто нибудь пользуется cli версией? Нужен ли вам --redirect? Если в нем нет особой нужды, то я бы предпочел не добавлять его.
Каким образом делается вывод, что ‘не удалось’ ?
В tpws для этого сечется несколько вариантов :
- RST, пришедший в ответ на первый запрос с хостом.
- HTTP редирект, пришедший в ответ на первый запрос с хостом, на глобальный адрес
с доменом 2 уровня, не совпадающим с доменом 2 уровня оригинального запроса. - закрытие соединения клиентом после отправки первого запроса с хостом, если не было на него
ответа со стороны сервера. Это обычно случается по таймауту, когда нет ответа (случай “зависание”).
Окей, первые 2 варианта можно обыграть как-то. Придется держать входящий конект и переподключаться несколько раз, чтобы попробовать новый вариант. Сложновато, но реализуемо.
Но как быть с вариантом 3 ? Это очень распространенный вариант.
Броузеры долго висят в ожидании ответа. Придется вводить какой-то более короткий таймаут, чтобы самому попробовать несколько вариантов, оставляя броузер висеть в это время.
Но сколько ждать ?
IP сайта кэшировать не есть гуд. Они могут скакать и быть множественными. Может лучше домен ?
И что в случае перезапуска ? Нигде не сохраняется результат ?
Пока обрабатывается только RST на первый запрос.
Да, так я и реализовал.
В первую очередь я хотел решить проблему поломки сайтов из-за tlsrec/oob/disorder, когда сервер сразу сбрасывает соединение. Пока не уверен, нужно ли добавлять обработку заморозки соединения, т.к. высока вероятность ложного срабатывания - высокий пинг, подвисание всей сети, медленный wifi на расстоянии, сайт временно не доступен.
IP сохранять есть смысл при использовании --redirect, чтобы обходить блокировки по IP, когда под ним могут быть и другие невинные сайты. Могут быть случаи невозможности определения домена (запутываются и другие протоколы, ESNI). Но да, IP может быть много, возможно добавлю кеширование доменов, с возможностью добавление IP, если нет домена.
Не сохраняется, и сами значения в кеше тоже валидны лишь несколько часов. Это сделано для того, чтобы кеш был актуальным, например, при чередовании провайдеров или при масштабных сбоях/временных блокировках, которые в последнее время часто случаются. При обработке только RST, новый перебор каждые несколько часов/суток некритичен, т.к. не занимает много времени.
Без этого на многих провайдерах затея полностью теряет смысл
curl --max-time 5 https://rutracker.org
curl: (28) Connection timed out after 5000 milliseconds
curl --max-time 20 http://bbc.com
curl: (28) Operation timed out after 20001 milliseconds with 0 bytes received
sknt и rostelecom SPB ведут себя так.
Он даже не удосуживается огрызнуться RST. Он отмораживается молча. Вот еще. Буду я на тебя ресурсы тратить. Не дождешься, виси там себе, тупи сколько влезет
На http самая типичная реакция - не RST, а именно редирект
Чредование провайдеров это смена wifi или wifi/cell ?
Так оно может случаться куда быстрее нескольких часов. Это скорее надо как-то детектить, если очень уж хочется.
Таблица маршрутизации доступна и без рута. Можно смотреть default gateway. ip4 и ip6
Можно даже не заморачиваться с netlink. Есть /proc/net/route и /proc/net/ipv6_route
Если поменялся gateway, то сбрасывать кэш. Возможно, стоит смотреть не полностью эту запись, а только название интерфейса default gateway, чтобы различать cell и wifi. Ведь сотовик может дать разные подсети при каждом подключении. Тут хорошо бы потестить на разных операторах, подергать подключение.
Еще лучше - держать разные кэши для разных подключений. Потому что скакать оно может иногда довольно часто.
Аппарат перемещается, то входит в зону wifi, то выходит, плохой прием wifi или cell
На таких можно делать наоборот - запутывать все подключения, а исключать лишь поломанные сайты (которые, в основном, сразу присылают RST):
./ciadpi --tlsrec 3+s --auto
Это так, сходу привел в пример, как одна из причин устаревания кеша, особо данный случай не расматривал, но спасибо за идею. Кажется, подобное лучше реализовывать не внутри прокси, а снаружи (на android за это может отвечать приложение). Наверняка на разных провайдерах будут работать разные методы, тут скорее нужны профили и переключение между ними. Например, на мобильном хорошим вариантом будет обнаруживать блокировки, а на wifi, где соединение замораживается, обнаруживать только поломки. тогда нужно будет перезапускать прокси с разными параметрами для разных сетей.
Все же добавлю таймаут, но включаться он будет на усмотрение пользователя (не везде это нужно). Думаю оптимально будет 2-3 секунды, но если увеличивать его, то желательно и время жизни кеша увеличить.
Новая версия!
Добавлена возможность автоматической смены/отмены/включения запутывания. Необходимо указать параметр --auto и за ним параметры десинхронизации. Примеры:
./ciadpi --auto --disorder 3 # включать disorder только при необходимости.
./ciadpi --disorder 3 --auto --split 1 # использовать disorder по умолчанию, при поломке использовать split.
По умолчанию --auto реагирует только на RST со стороны сервера после первого запроса. Но сайты могут просто перестать отвечать, для этого есть опция --timeout. Бывает, что провайдер/сервер перед сбросом соединения может отправить некие данные. Для таких случаев есть опция --tr. В ней можно указать какие данные, с какой и по какую позицию искать для включения auto. Например, если фейковый TLS пакет дойдет до сервера, то он пришлет ServerHello со значением session id равным соот. значению в фейк пакете. Обработать это можно так:
./ciadpi --fake -1 --auto --tr '32:64::\xf9\xdf\x0c\x2e\x8a\x55\x89\x82'
Указанная строка является кусочком session id из дефолтного фейкового пакета .
Точно также можно реагировать на TLS Alert или на HTTP Redirect:
./ciadpi --fake -1 --auto --tr '0:7::\x15\x03\x01\x00\x02\x02'
./ciadpi --auto --disoder 3+h --tr '0:500::\nLocation: http://blocked.com'
Теперь там, где в качестве аргумента принимался файл, можно указать строку, добавив перед ней символ :. Например:
./ciadpi --oob 3 --oob-data ':\x00'
В винде --fake невозможен? Похоже, это единственное, что может пробить моего провайдера.
goodbyedpi умеет
В byedpi он не поддерживается, но, возможно, в теории, его можно как-то реализовать из пользовательского пространства, хотя я сильно сомневаюсь.
Что насчёт tlsrec или oob?
ciadpi --oob 10+s --tlsrec 1+s
Да, это возможно, используя TransmitFile. Возможно, скоро добавлю поддержку --fake и на Windows
О, работает! Я пробовал эти параметры, но с другими числами. Гран мерси!
Вообще, у меня GDPI давно стоит, но прокси мне удобнее. Особенно с новым параметром --auto.
Кстати, у меня категорически отказывается работать ciadpi на портах из первых тысяч, хотя порты свободны. Поставил 10800, работает, но странно это.