GoodCheck - блокчек-скрипт для GoodbyeDPI, Zapret, ByeDPI

О том и речь - какой смысл гонять 300 проверок скриптом, если и так на текущий момент понятно, что имеет значений только этот код, а для него данный скрипт бесполезен…

объясните мне дураку, почему с версией Release 0.2.3rc3 · ValdikSS/GoodbyeDPI · GitHub
я вижу
test with “GoodbyeDPI” (last official build detected: no “–fake-with-sni” support)

потому что Если опять перестал грузиться YouTube или его видео. Читаем шапку.

А лучше читаем тут - Сборка YTDisBystro на основе Zapret: Тестирование и обсуждение

Работает отлично, но такая хотелка нарисовалась)). Вот это (1) вообще удалить бы, а вместо 2 оставить только Time. Тогда вся инфа понятна и компактно будет расположена, одним взглядом охватывается и не нужно окно раздвигать по горизонтали, чтобы увидеть время.
Да, и минуты с секундами тоже можно m и s

замена exeшника из 1 ссылки ни на что не влияет.
видимо надо разбираться со второй.

Да ладно?

Спойлер

Как видите, никаких предупреждений и доступны варианты стратегий с fake-with-sni

Очередная версия на go, уже 0.5.0.
GoodCheckGo_v0.5.0_bin.zip (4,6 МБ)
GoodCheckGo_v0.5.0_src.zip (13,4 КБ)

  • Добавлена возможность скипнуть проверки сертификатов.
  • Добавлен перебор резолверов из предустановленного списка, если кастомный фейлится. Если фейлятся все - идет fallback на системный.
  • Добавлено автозавершение программ и сервисов. Можно указать несколько названий, через запятую в конфиге (а то развелось сборок, и все по-разному службу называют!).
  • Добавил вывод версии винды и архитектуры проца в лог.
  • Если не найден пэйлоад для запрета, используется хекс в качестве параметра.

Не сделано:

  • http3/quic
  • doh
  • прокси для byedpi

В целом, на данный момент, прога может работать без конфига, чеклиста, папки логов, пэйлоадов. Единственное что точно нужно - папка со стратегиями.

Спасибо!!!

походу пора уже на гитхабчик :grinning:

                                 Провайдер МТС 

start “” goodbyedpi.exe -5 -e 1 --fake-from-hex 2e9a3c033324d437cd07138fd6c69cf59a9d5f1eae9169acee789e4b47a241e8cf8ab38cae4911f25e3ac222a85516f0f51eb4d59639913f25b9 -q --reverse-frag --set-ttl 7 --fake-gen 15 --blacklist …\russia-blacklist.txt --blacklist …\russia-youtube.txt
с этими параметрами открывает

https://www.youtube.com/watch?v=sStuI47cE_4&t=6s

https://www.youtube.com/watch?v=oWhalHZXLUw

https://www.youtube.com/watch?v=_M-DV8kKNMk

https://www.youtube.com/watch?v=9hDjp0C79-c

https://www.youtube.com/watch?v=IblDZpSyFSM&t=163s

https://www.youtube.com/watch?v=ONegYxmO1QI

https://www.youtube.com/watch?v=CErf41K1tTI

https://www.youtube.com/watch?v=b3-ZQu842B4

https://www.youtube.com/watch?v=c0riYZJoZJw

https://www.youtube.com/watch?v=MTwxi222RaQ&t=90s

https://www.youtube.com/watch?v=pc1RrpGbdMI

https://www.youtube.com/watch?v=L8rb47p1qfQ

https://www.youtube.com/watch?v=ilapZBGYaGE

https://www.youtube.com/watch?v=Sx5gLyrpZO8

Почему не все, а только некоторые?

Заметил в этой версии Гудчека такую ошибку, когда утилита долго работает (много сайтов для проверки):

Terminating program...

Critical error: TerminateProcess: Access is denied.

На Proceeding with: [from Blockcheck] - [IPv4] - [TCP].txt

На куике такого нет, потому что быстрее прогоняется.

Процесс запрета по каким-то причинам крашнулся → функция из официального пака os/exec попыталась его убить → процесса не оказалось и она вылетела с ошибкой. Проблема в том, что говноеды, которые писали оф. пак не могли сделать нормальную проверку на вид ошибки, или написать что они сами не знают почему у них что-то сломалось. В итоге вместо “процесса не существует” мы имеем “доступ запрещен”. И пойди догадайся, что это от отсутствия процесса.

Энивей, я добавил проверку на наличие процесса перед вызовом kill.

Также прикрутил прокси, чтобы byeDPI работал, но… По каким-то причинам работает не оч. При проверки одних и тех же стратегий, через батник с курлом, и через прогу с нативными запросами - результаты разные (в батнике через курл может быть 65/80, а в проге 2/80). Не приходит ответ за отведенное время и происходит фейл по таймауту. Подозреваю, что как-то неправильно реализовал параллельные запросы в прокси. Но хз. Что странно проявляется проблема только на некоторых стратегиях, на остальных всё окэй. Короче не знаю. Подумываю убрать из проги поддержку byedpi, чтобы не путать людей некорректными результатами.

GoodCheckGo_v0.5.5_bin.zip (4,6 МБ)
GoodCheckGo_v0.5.5_src.zip (14,8 КБ)

Если это повысит стабильность Гудчека, то я бы выкинул byeDPI. Все равно большинство здесь использует Гудбай или Запрет.

Пожалуйста не надо удалять поддержку byedpi! У меня такой провайдер, на котором обход через goodbyedpi вообще не работает, а zapret через пень-колоду. Каждый день ломают их, приходится параметры заново подбирать.

Но с byedpi проблем почти нет, его способы, видимо, специально не блочат из-за малой распространённости.

Мне кажется, на выходе, результат работы запрета и byedpi должен быть примерно одинаков при одинаковых параметрах…


Из батника, который в стартовом посте я в любом случае не планирую удалять поддержку bye, т.к. там оно работает нормально. Проблема есть только в варианте на golang.

Ну и плюс гудчек мало чем пользователям bye может помочь сейчас, т.к. нет нормального списка стратегий.

Может, стоит в таком случае сделать некий фаззинг? Взять более-менее разумный список значений для --split, --disorder, --disoob, —tlsrec, и прогнать в цикле сочетания со случайным разбросом ±3. У byedpi параметров не так много, чтобы цикл получался сильно длинным. Ну или ограничить до 50, например. Каждый раз брать случайный random seed.

Батником такое очень неприятно делать. Я сам думал на powershell наговнякать по образу и подобию, но там с ожиданием завершения процесса у меня ещё хуже получается.

Всем здрасьте! Есть пара вопросиков по гудчеку (версии 1.3.07 в основном):

  1. Что-то у меня через Wireshark такой здоровый по длине HEX получился Прям в разы длинней дефолтного. Так-то скормить его гудчеку удалось, но результаты при прогоне вышли так себе, даже хуже, чем с дефолтным. Его никак обрезать не нужно было?
  2. Я так понял, что стратегии e1 и e2 отличаются одним параметром. Насколько имеет смысл прогонять обе группы стратегий? Может ли так случиться, что e2 даст результат лучше?
  3. Есть ли вообще смысл увеличивать количество прогонов стратегий. Ставлю обычно (зачем-то) 3 прогона, в результате fake-from-hex, fake-gen гоняется 40+ минут. Может, я зря так много ставлю, или может наоборот, мало?
  4. Тут вроде писал автор, что серваки в “default - googlevideo and youtube.txt” условные, и надо туда записать свои. А откуда их взять?
  5. А в чем причина переписывания утилиты с нуля (той которая 0.5.5 на данный момент)?

Заранее спасибо за ответы

кароч попробовал так в одну сроку работает, но тут как я понемайю тока тисипи порктокол идёт имодифицирует все пакеты бизесключения с хотслистами не зрадаботало пока что и прочие навороченые параметы

Добавьте в конец --hostlist=youtube.txt
Можно так

start "zapret: https" /min "%~dp0winws.exe" ^
--wf-l3=ipv4 --wf-tcp=443 ^
--filter-tcp=443 --hostlist="%~dp0youtube.txt" --dpi-desync=fake,disorder2 --dpi-desync-ttl=1 --dpi-desync-autottl=4 --wssize 1:6 --new ^
--filter .... конфиг_для_других_сайтов

Из личного опыта использования:

Насколько знаю, да, надо — как где-то писали, нужны только 116 (или 114/144?) символов, так как cmd не умеет переваривать команды длиннее определённого числа символов. Остальное можно выкидывать или даже обрезать сильнее — например, оставить 100 или ещё меньше. У меня всё успешно завелось с 116.

Зависит от провайдера. К примеру, на МГТС -e2 вообще не функционирует и ломает большинство рабочих стратегий, с -e1 всё ОК. Как правило, работает либо одно, либо другое — можно понять ещё на начальном этапе после 20-30 проверок.

Если хотите избежать периодических ложнооотрицательных результатов и/или если ТСПУ замедляет соединение до конкретных серверов не сразу, а спустя несколько попыток соединения, то да, смысл может быть. Лично я использовал несколько прогонов только для тестов Google Video, для прочих сайтов особого смысла это не имеет.

Открыть YouTube (без VPN/прокси) и начать тыкать на рандомные видео с открытой консолью, F12 → Сеть. Выписываете все сервера Google Video вида rr1---sn-abcdefg-asdf.googlevideo.com, с которых тянутся видосы, и заносите в свой файл для проверки. Сервера, которые сразу на старте отдают 403, выписывать не надо — они не заработают ни при каких обстоятельствах.

Выглядит нужный запрос примерно так:

Желательно проверить таким способом как минимум 20+ видео (в т.ч. непопулярные), чтобы собрать относительно полную базу ваших кластеров GGC — поможет избежать случаев, когда часть видео внезапно откажется загружаться из-за того, что вы нашли рабочую стратегию не для всех использующихся кластеров. Дубликаты можно не выписывать, но несколько серверов из одного кластера (т.е. от rr1 до rr8) добавить на всякий случай можно.

Также может быть смысл проверять сайт YouTube отдельно от GGC — с недавнего времени на некоторых провайдерах (в частности, МГТС) стратегии обхода для них отличаются, а общей стратегии для GGC + YT фактически не существует. По моему субъективному опыту, для самого сайта YT работает то же самое, что и для остальных нельзясайтов, так что суммарно может потребоваться два прогона: только GGC и YT + нельзясайты.