На byedpi для ютуба и остальных жёстко заблоченных сайтов хорошо работает (по крайней мере у меня) конфиг вида -d1 -s4 -d8 -s1+s -d5+s -s10+s -d20+s -s25+s -d30+s и так далее, без всяких фейков и out of order байтов, чисто сплиты и дизордеры. То есть, насколько я понимаю, из пакета client hello вырезаются (на них ставится ttl=1 и они не доходят даже до DPI) куски в начале пакета и на месте SNI, которые ядро потом по одному досылает на сервер. Вот собственно интересует, есть ли такая возможность как бы множественного сплита с дизордером на nfqws, чтобы можно было бы нарезать client hello на части и отправить в произвольном порядке? Судя по ману вроде нет… Просто на винде вышенаписанная стратегия для byedpi не работает, т.к происходит полная ретрансмиссия и вместо того чтобы заполнять дыры по одной ядро сразу кидает весь пакет целиком и видимо триггерит DPI, тут нужен обработчик пакетов типа nfqws.
Нет такой возможности. Так же не функции автоматической обратной связи.
если не работает 1, попробовать 2
Каким же огромным стал в v68 mipselsf tpws - 294888:
# ls -l /tmp/tpws-v68
-rwxr-xr-x 1 root root 294888 Nov 8 13:41 /tmp/tpws-v68
В v67 mips32r1-lsb tpws был всего 114984, в 2,5 раза меньше:
ls -l /tmp/tpws-v67
-rwxr-xr-x 1 root root 114984 Oct 31 21:59 /tmp/tpws-v67
Это он так от нового кода распух и про
Установка на openwrt в режиме острой нехватки места на диске
Требуется около 120-200 кб на диске.
можно начинать забывать или что еще можно с этим сделать?
Неплохо было бы реализовать дополнительную стратегию второй фазы shuffle. Что-то типа --dpi-desync=shuffle --dpi-desync-shuffle-pos=1:5:1+sni --dpi-desync-shuffle-order=3:1:2 кидает первым кусок пакета от 1 до 5 байта, вторым кусок от 5 до начала sni+1, третьим первый байт в начале пакета и наконец уже все остальное. Просто как альтернативу фейкам с repeats.
Вы сравниваете распакованный с упакованным в upx? Так как вижу в v68:
du -h mips32r1-lsb/tpws
120K mips32r1-lsb/tpws
Если у вас openwrt то скорее подойдет бинарник собранный в SDK нужной версии. В репо запрета собраны статические бинари.
Судя по размеру это версия без upx.
Но я ее в упор не вижу в релизе. Где ? Если самосбор, то это нормально. Без upx и будет. Если надо можно упаковать самостоятельно.
Достоверно известно, что когда не работает обычный disorder2, этот вариант работает ?
То есть DPI может разобрать 2 фрагмента в обратном порядке, а 3 не может ?
Зачем самосбор. Обычный артефакт из Actions - Release v68
https://github.com/bol-van/zapret/actions/runs/11738829404/artifacts/2162023778
Это промежуточный результат сборки. Его можно использовать, но он без upx.
Можно ли эту идею каким-то образом потестировать?
Бай DPI умеет такое.
Но прежде, чем мутить это в zapret, хотелось бы убедиться в эффективности.
Пока не сталкивался с таким.
Кстати, даже если реализовать это в nfqws, то будет не полный аналог byedpi.
byedpi играет с сокет апи, он не может абы что послать. Отдельные части.
Должно быть он может резать на любое количество частей и применять disorder или fake к отдельно взятым частям. Но произвольно шуффлить он не может
Ага, понятно теперь.
Просто из описания релиза сложилось впечатление что бинарники переехали оттуда полностью в Actions.
Сборка переехала, а бинарики в релиз переехали.
а можно убрать из названия архива и директории внутри версионирование? это сильно усложняет написание скрипта для обновления запрета на freebsd
Это сделано, чтобы при распаковке разных версий они не мешались.
В скрипте shell этот вопрос решить элементарно через glob
Ну у меня на билайне работает googlevideo с -d1 -s4 -d8 -s1+s -d5+s -s10+s -d20+s -s25+s -d30+s на андроиде и линуксе. Также чекал на ростелекоме, работает. Вот еще человек пишет, что у него дискорд и ютуб заработали с подобным конфигом на андроиде. Конечно нужно чтобы кто-то еще проверил на byedpi у себя и отписал. Там не 3 фрагмента, а больше(через DPI пакет проходит в порядке 2 - 4; 9 - sni+1; sni+6 - sni+10; sni+21 - sni+25; sni+31 - конец пакета; 1 - 1; 5 - 8; sni+2 - sni+5; sni+11 - sni+20; sni+26 - sni+30), обязательно чтобы были вырезаны куски из начала пакета там где 16 03… и в SNI иначе отказывается работать. Мб можно и меньшее количество фрагментов сделать. На винде этот конфиг работать НЕ будет из-за полной рентрансмиссии. Да, конечно это не полноценный shuffle, поэтому и хочется чего-то такого на nfqws потому что у него больше возможностей чем у byedpi которая работает со стрим сокетами. Короче интересно, работает ли у кого такой конфиг и есть ли смысл это реализовать в запрете?
апд: да, обычный запретовский дизордер с sequence overlap не работает для ютуба и дискорда, все остальное пробивает.
Было бы полезно, если вы попробовали сократить максимально это выражение.
Чтобы понять поточнее на что реагирует DPI.
Достаточно ли вырезать только 16 03 и SNI. Одно что-то - недостаточно ?
split-pos=1 не работает на split2 или disorder ?
действительно ли важно порезать именно по SNI ?
Если так, то это может быть сочетание разных DPI, 1 из которых stateless как в Эмиратах и Саудии.
Если делать произвольное перемешивание, то использовать позицию SNI несколько сложновато и неоднозначно. Ведь она может попасть куда угодно. В любой интервал, и он может стать невалидным.
SNI на позиции 100, допустим
написано 101-SNI. Что делать ?
А если это не TLS, то что делать ? Или SNI отсутствует в extensions.
Потестил, минимально рабочий конфиг byedpi для ютуба: -d1 -s25+s -d30+s. То есть сначала кидает 2 - SNI+25 потом SNI+31 - конец пакета, затем заполняет дыры 1-1 и SNI+26 - SNI+30. Насколько я понял, обязательно чтобы отсекались первые байты в пакете И одновременно с этим чтобы строчка …googlevideo.com… в SNI не попала целиком в один из фрагментов, именно отсюда -s25+s -d30+s. По отдельности не работает, и если порезать SNI где-то в другом месте тоже не будет работать. Ни голый split с pos=1 ни disorder на запрете не работают для ютуба, работает только фейк со SNI гугла с repeats 3, потом split, для фейка дурение badseq.
Да, я понимаю что это будет сложно реализовать, да и не особо нужно в принципе пока все работает.
юзаю byeDPI на андроиде с настройками:
-n “www.google.com” -d +s -O 1 -s 25+s -t 5
На вайфае, и мобильном операторе (мегафон) ютуб и инста летают.
Забавно. Должно быть они сделали дополнительное правило на поиска строки “googlevideo.com” в первых нескольких пакетах, не анализируя структуры TLS. В дополнение к обычной проверке.
Может супер-шредер сделать ? Резать каждые N байт и отправлять в случайном порядке ?
Или даже задать случайный диапазон длин. От 5 до 10, допустим. Пусть потом копаются в этом месеве из 50 пакетов в разном порядке с разной длиной. Или задом наперед отправлять. Чтобы случайность не привела к случайным сбоям.
Или еще SNI-потрошитель. Начало -SNI норм, потом покрошить SNI на мелочь, потом опять норм.
Вообщем пространство для игрищ большое. Надо подумать что будет лучше.
Слишком уж увлекаться мелочью чревато реакцией ДДОС защит