Hello, I’ve been using GoodbyeDPI for years now, but a few weeks ago it suddenly stopped working in Saudi, i have some friends who encountered the same problem at the same time, any ideas on how to get around it or something?
using it as a program, windows 10
tried all available .bats in gbdpi 0.1.6 and 0.2.2
Здравствуйте, я использую GoodbyeDPI уже много лет, но несколько недель назад он внезапно перестал работать в Саудовской Аравии. У меня есть друзья, которые столкнулись с той же проблемой в то же время, есть идеи, как ее обойти или что-то в этом роде?
используя его как программу, Windows 10
перепробовал все доступные .bat в GoodbyeDPI 0.1.6 и 0.2.2
As we say in the Russian internet space, we do not practice fortune telling or anything of the sort.
Please provide network capture files showing the issue if you want to receive assistance. Without them, we can only guess.
Thank you for replying. yeah i figured, but how can i do that? i asked chatgpt he told me to use Wireshark but also told me that i should delete the sensitive information, which I’m not sure if its gonna make the results incomplete or not. is there a tutorial or something that i can follow? also i downloaded Wireshark and had no idea whats going on 
there’s another tool called zapret
if you run blockcheck and post here it’s log we can see what’s going on
also if you have just (auto) updated chrome to 124+ go to chrome://flags and disable kyber
zapret is compatible with kyber. gdpi - not
As @bolvan said, it’s probably due to Kyber.
i already have it disabled, not sure how long ago but I’ve tried to fix it myself, no luck tho, its not working everywhere not only the browsers
tried 3 websites(all of them are blocked in my country)
po.rnhub.com, didnt give any available commands
nordvpn.com, gave some
ntc.pary, gave some too
blockcheck3.log (409.3 KB)
blockcheck1.log (243.8 KB)
blockcheck2.log (16.6 KB)
And also check PM.
ipv4 ntc.party curl_test_http : working without bypass
ipv4 ntc.party curl_test_https_tls12 : winws not working
ipv4 ntc.party curl_test_http3 : winws not working
ipv6 ntc.party curl_test_http : working without bypass
ipv6 ntc.party curl_test_https_tls12 : winws --wf-l3=ipv6 --wf-tcp=443 --dpi-desync=destopt
ipv6 ntc.party curl_test_http3 : winws not working
this looks like partial ip block
blocked http/https or even tcp on specific ip
however dpi cannot properly analyze extra ipv6 headers. it may not follow destopt header and not treat it as tcp. that’s why bypass works
to confirm some curl tests help|
try connecting to ntc.party with substituted ip
and check if it gives rst
then try unblocked google with real ntc.parry ip
curl -v --connect-to ntc.party::1.1.1.1 https://ntc.party
curl -v --connect-to google.com::130.255.77.28 https://google.com
if first complains to certificate and second gives rst then it’s likely ip block
also can write 1.1.1.1 to hosts file and run blockcheck. dont expect available. look when certificate error appears. it indicates success .
if so then dpi also check sni but real ip is also ip blocked
I am also in Saudi Arabia and GoodbyeDPI stopped working. Actually, all other Deep Packet Inspection circumvention utilities stopped working at once.
This is my log when I run Blockcheck:
blockcheck.log (478.8 KB)
i plan to add ip block tests to blokcheck like described above
i guess its too hard for you to do it manually 
but not now. i’m gone
anyway , with tests like this you can forget about gdpi too
i expect you did it with all bypasses disabled and not in nated vm
It returns the following:
curl -v --connect-to ntc.party::1.1.1.1 https://ntc.party
* Connecting to hostname: 1.1.1.1
* Trying 1.1.1.1:443...
* Connected to 1.1.1.1 (1.1.1.1) port 443
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* Recv failure: Connection was reset
* schannel: failed to receive handshake, SSL/TLS connection failed
* Closing connection
* schannel: shutting down SSL/TLS connection with ntc.party port 443
* Send failure: Connection was reset
* schannel: failed to send close msg: Failed sending data to the peer (bytes written: -1)
curl: (35) Recv failure: Connection was reset
curl -v --connect-to google.com::130.255.77.28 https://google.com
* Connecting to hostname: 130.255.77.28
* Trying 130.255.77.28:443...
* Connected to 130.255.77.28 (130.255.77.28) port 443
* schannel: disabled automatic use of client certificate
* ALPN: curl offers http/1.1
* schannel: failed to receive handshake, SSL/TLS connection failed
* Closing connection
* schannel: shutting down SSL/TLS connection with google.com port 443
curl: (35) schannel: failed to receive handshake, SSL/TLS connection failed
pls redo second test with curl from cygwin prompt. windows schannel is not too informative
this doesn’t look like ip block. may be dpi detect anomalies in request and treat it as fooling attempt
to verify this idea run blockchexk on mail.ru with force option. do all tests despite of result. https only
$ curl -v --connect-to ntc.party::1.1.1.1 https://ntc.party
* Connecting to hostname: 1.1.1.1
* Trying 1.1.1.1:443...
* Connected to 1.1.1.1 (1.1.1.1) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* Recv failure: Connection reset by peer
* quictls SSL_connect: Connection reset by peer in connection to ntc.party:443
* Closing connection
* Recv failure: Connection reset by peer
* Recv failure: Connection reset by peer
curl: (35) Recv failure: Connection reset by peer
$ curl -v --connect-to google.com::130.255.77.28 https://google.com
* Connecting to hostname: 130.255.77.28
* Trying 130.255.77.28:443...
* Connected to 130.255.77.28 (130.255.77.28) port 443
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* quictls SSL_connect: SSL_ERROR_SYSCALL in connection to google.com:443
* Closing connection
curl: (35) quictls SSL_connect: SSL_ERROR_SYSCALL in connection to google.com:443
blockcheck.log (276.6 KB)
Try something like
goodbyedpi.exe -6 -e 130
It will work only for Firefox though.
Your ISP started to search for the ServerNameIndication pattern in the TCP packets, apparently due to Chrome’s usage of Kyber, which causes TLS packet to be larger than a single TCP packet. However, it looks for the pattern beginning only in the first 256 bytes of TCP packet payload (even when there’s no TCP session started by 3-way handshake), while Chrome with Kyber enabled could put it anywhere, so my assumption is that Chrome would sometimes connect to the blocked website without any circumvention methods.
The workaround for GoodbyeDPI is to split the packet exactly at the ServerNameIndication (domain name) boundary.
I’ll make a proper fix somewhere next month.
ksa_ntcparty.pcapng (33.5 KB)
I was muted and couldn’t reply because I apparently reached the daily reply and message limit. Anyway, the settings you provided worked only with Firefox, as you said. Well, it’s my preferred browser anyway. It made some websites’ responsiveness or loading very slow (Internet speed is still the same). Thankfully, it only happens when accessing them for the first time. Some sites also fail to load images, as seen in the picture. Thankfully, I was able to circumvent this by first loading the website using a VPN (I used Cloudflare WARP), turning off the VPN, then running GoodbyeDPI with the custom settings. Now the images always load properly. The settings might need some optimization. An updated package including custom script files for KSA would be nice for beginner users, but this solved my issues. Thank you ValdikSS and bolvan for your help!
That shouldn’t happen anymore.
That’s strange but not very surprising. Try to tinker with -e parameter, maybe 125 or 140 or something in that range would work better.
Could you please try this one?
goodbyedpi.exe -6 --frag-by-sni
You still need to disable Kyber, as there’s no segment reassembly.
chrome://flags → kyber → disable
