Maskowanie lokalnego proxy SOCKS w klientach VPN na Androida do omijania detekcji
Popularne klienty VLESS na Androida pozostawiają otwarty lokalny proxy SOCKS na stałym porcie, co pozwala aplikacjom wykrywać VPN i pobierać zewnętrzny adres IP serwera. Potwierdzają to testy z narzędziami typu RKNHardering: nawet w trybie split-tunelowania widoczny jest interfejs TUN, systemowe trasy, lista pakietów i dostępny proxy. Rozwiązanie to dynamiczne generowanie losowego portu oraz uwierzytelniania dla SOCKS5, niedostępnych dla innych aplikacji.
Zasady detekcji i środki przeciwdziałania
Aplikacje skanują localhost w poszukiwaniu otwartych portów SOCKS. Standardowe klienty (v2RayTun, v2rayNG, Hiddify) nie maskują ich, co prowadzi do przecieku. Proponowane podejście:
- Generowanie losowego portu (np. 45478) przy każdym uruchomieniu.
- Automatyczne tworzenie unikalnego loginu/hasła (np. upu6CHvvV:ZJC3GMDXKOLFdPKAfxBxrHiU).
- Uruchamianie proxy tylko do użytku wewnętrznego poprzez tun2socks.
To blokuje skanowanie: zewnętrzne aplikacje nie mogą się połączyć bez danych uwierzytelniających i nie widzą rzeczywistego IP.
Realizacja techniczna na bazie Xray i tun2socks
Xray-core dostarcza binarne pliki wieloplatformowe dla VLESS/VMess. Do pełnego TUN zamiast natywnego tunelowania Xray używa się tun2socks (statyczna kompilacja linux-arm64). Architektura:
- Uruchomienie Xray z SOCKS5 na losowym porcie.
- tun2socks przekierowuje ruch z deskryptora pliku TUN do proxy.
- Otoczka w Flutter + Kotlin + C++ zarządza procesami.
Omijanie ograniczeń Androida 10+ (naruszenie W^X): pakowanie binarnych w lib/*.so.
Log typowego uruchomienia:
[2026-04-12T09:44:46.641632] [INFO] Starting VPN
[2026-04-12T09:44:46.641818] [INFO] Underlying network set: 176
[2026-04-12T09:44:46.641946] [INFO] nativeSetMaxFds result (parent): 0
[2026-04-12T09:44:46.643867] [INFO] TUN established, dup fd=142
[2026-04-12T09:44:46.644004] [INFO] xray started
[2026-04-12T09:44:46.644130] [INFO] Starting tun2socks (native): /data/app/~~_xfukaXUtA4X7kd1BmB4UA==/com.teapodstream.teapodstream-zTL0GGuDWxPk8XDn0VkAiw==/lib/arm64/libtun2socks.so -device fd://142 -proxy socks5://upu6CHvvV:[email protected]:45478 -mtu 1500 -loglevel error -tcp-sndbuf 524288 -tcp-rcvbuf 524288 -tcp-auto-tuning
[2026-04-12T09:44:46.644247] [INFO] tun2socks started (pid=28880)
[2026-04-12T09:44:46.644399] [INFO] VPN connectedParametry tun2socks: MTU 1500, bufory TCP 524288 bajtów, autotuning. PID tun2socks jest monitorowany dla łagodnego wyłączenia.
Funkcjonalność klienta
Realizacja o nazwie TeapodStream obejmuje podstawowe scenariusze:
- Protokoły: VLESS, VMess, Trojan, Shadowsocks.
- Split-tunelowanie: wykluczanie aplikacji z VPN.
- Subskrypcje po URL z automatycznym odświeżaniem konfiguracji.
- Dynamiczne uwierzytelnianie proxy.
Testy na detektorach (z oryginalnego artykułu o luce VLESS i RKNHardering) potwierdzają brak wykrycia SOCKS i IP.
Co ważne
- Lokalny SOCKS jest maskowany losowym portem i danymi uwierzytelniającymi — klucz do omijania skanowania localhost.
- tun2socks + Xray zapewniają stabilny TUN bez kaprysów natywnego tunelowania.
- Pakowanie binarnych w .so omija SELinux Androida.
- Obsługa split-tunelowania nie niweluje detekcji innych cech (TUN, trasy).
- Otwarty kod źródłowy pozwala zweryfikować realizację.
— Editorial Team
Brak komentarzy.