penguinehis/SocksRevive-PC
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 1 Wiki Activity
Files
main
SocksRevive-PC/README.md
penguinehis 92941e68a2 Launch
2026-05-16 00:18:06 -03:00

9.6 KiB
Raw Permalink Blame History

SocksRevive VOID PC

SocksRevive VOID PC is a native desktop tunnel client for Windows and Linux. It provides offline profile management, SSH-based tunnel modes, embedded TUN routing, optional IPv6, UDPGW support, DNSTT, and Xray integration.

The application uses a native desktop interface. Profiles are created, imported, and exported from the app as .srpc files.

Features

Feature Description
Direct SSH Creates a local SOCKS5 server and forwards traffic through SSH.
Payload SSH Connects through an HTTP proxy/payload before the SSH handshake.
SSL/TLS SSH Wraps the SSH tunnel in TLS/SNI.
Payload + SSL Uses TLS/SNI, payload injection, and SSH together.
DNSTT + SSH Uses the embedded DNSTT client and then connects SSH through the local DNSTT endpoint.
Xray Core Starts an external Xray executable and routes traffic through its local SOCKS inbound.
TUN mode Routes system traffic through the tunnel using embedded tun2socks.
UDPGW Enables UDP traffic for SSH-based modes when a server-side UDPGW service is available.
IPv6 Optional IPv6 routing and IPv6 leak protection.
Reconnect Automatically reconnects after tunnel loss when enabled in the profile.
Proxy rotation Tries multiple proxy hosts until one completes the full tunnel handshake.

Project folders

profiles/          Local offline .srpc profiles
configs/           Xray configuration files
tools/xray/        Xray executable location
tools/wintun/      Wintun DLL source location before embedding
dist/              Build output
logs/              Runtime and crash logs

Profile format

Profiles use the .srpc extension. They are managed by the app UI and stored locally in the profiles/ folder.

Xray is the only mode that uses a JSON file directly, because Xray Core requires JSON configuration. The default Xray configuration path is:

configs/xray.json

Windows build requirements

Install:

  • Go 1.22 or newer
  • MSYS2 UCRT64 GCC
  • MSYS2 binutils, for windres.exe

Automatic setup:

cd SocksRevivePC
powershell -ExecutionPolicy Bypass -File .\scripts\install_windows_compiler_msys2.ps1

After setup finishes, open a new PowerShell window and build:

cd SocksRevivePC
powershell -ExecutionPolicy Bypass -File .\scripts\build_windows.ps1

Run:

.\dist\SocksRevivePC.exe

The Windows executable includes a UAC manifest, so Windows should ask for Administrator permission when the app starts. Administrator permission is required for Wintun, DNS changes, TUN addresses, and system routes.

The normal Windows build is GUI-only. Helper processes such as route configuration, DNS configuration, Xray, and legacy helper binaries are started without visible console windows.

Optional debug build:

powershell -ExecutionPolicy Bypass -File .\scripts\build_windows.ps1 -Debug

Debug builds may show a console and should only be used for troubleshooting.

Linux build requirements

Install Go, GCC, and the desktop dependencies required by Fyne. On Debian or Ubuntu:

sudo apt update
sudo apt install -y golang gcc libgl1-mesa-dev xorg-dev

Build and run:

cd SocksRevivePC
chmod +x scripts/build_linux.sh
./scripts/build_linux.sh
./dist/socksrevivepc

For TUN mode on Linux, run the app with root privileges:

sudo ./dist/socksrevivepc

Wintun setup for Windows TUN mode

Windows TUN mode requires the official signed wintun.dll.

For 64-bit Windows, place the DLL here before building:

tools/wintun/amd64/wintun.dll

Embed it into the final executable:

powershell -ExecutionPolicy Bypass -File .\scripts\embed_wintun_from_tools.ps1
powershell -ExecutionPolicy Bypass -File .\scripts\build_windows.ps1

After embedding, the app extracts the DLL automatically at runtime. Users do not need to manually place wintun.dll beside the executable.

Fallback lookup locations are also supported:

Same folder as SocksRevivePC.exe
tools/wintun/amd64/wintun.dll
PATH

Use only the official signed Wintun DLL from the WireGuard/Wintun distribution.

TUN settings

Recommended Windows values:

Device: wintun
Interface name: wintun
MTU: 1500
CIDR: 198.18.0.1/15
Gateway: 198.18.0.1
Route all traffic: enabled

When TUN mode starts, the app:

  1. Starts the selected tunnel.
  2. Waits for the local SOCKS port.
  3. Starts the embedded tun2socks engine.
  4. Configures the TUN adapter.
  5. Adds system routes.
  6. Adds bypass routes for the active server or active proxy.

For route-all mode on Windows, the app installs split default routes through Wintun:

0.0.0.0/1
128.0.0.0/1

Only the active proxy from a rotation list is bypassed. The full proxy list is not added to the route table.

IPv6 settings

IPv6 is optional per profile.

Recommended when the server supports IPv6:

Enable IPv6 through tunnel: enabled
IPv6 CIDR: fd00:534f:434b::1/64
IPv6 DNS: 2606:4700:4700::1111, 2001:4860:4860::8888
Block IPv6 leaks when IPv6 tunnel is off: enabled

Recommended when the server does not support IPv6:

Enable IPv6 through tunnel: disabled
Block IPv6 leaks when IPv6 tunnel is off: enabled

When IPv6 routing or IPv6 leak protection is enabled, the app uses these IPv6 split routes:

::/1
8000::/1

UDPGW settings

UDPGW allows real UDP traffic through SSH-based modes.

Supported modes:

Direct SSH
Payload SSH
SSL/TLS SSH
Payload + SSL
DNSTT + SSH

Recommended server-side listener:

127.0.0.1:7400

Recommended client values in the UDPGW tab:

Enabled: on
Protocol: badvpn
Remote UDPGW host: 127.0.0.1
Remote UDPGW port: 7400

127.0.0.1 is resolved from the server side because the UDPGW connection is made through SSH.

Protocol options:

badvpn    Android-compatible BadVPN UDPGW framing with IPv4 and IPv6 target support
legacy    Older IPv4-only frame format

When UDPGW is disabled, SSH modes keep a DNS-only fallback: UDP port 53 is converted to DNS-over-TCP through SSH, while other UDP traffic is dropped.

DNSTT setup

DNSTT mode uses the embedded DNSTT client. Normal DNSTT profiles do not require an external dnstt-client.exe.

Create or edit a profile, choose DNSTT + SSH, and set:

Embedded engine: enabled
Resolver type: doh, dot, or udp
Resolver: https://cloudflare-dns.com/dns-query, 1.1.1.1:853, or 1.1.1.1:53
Tunnel domain: DNSTT tunnel domain
Server public key: DNSTT server public key in hex
Local SSH host: 127.0.0.1
Local SSH port: 2222

Then fill the SSH tab with the SSH account behind DNSTT.

External DNSTT executable fields are kept only for compatibility with older deployments.

Xray setup

Place Xray here:

tools/xray/xray.exe   # Windows
tools/xray/xray       # Linux/macOS

Edit the Xray configuration file:

configs/xray.json

The app expects Xray to expose a local SOCKS inbound. Default:

127.0.0.1:10808

The SOCKS host and port in the UI must match the inbound configured in configs/xray.json.

Payload syntax

Supported placeholders:

[host]
[port]
[crlf]
[lf]
[cr]
[split]
[instant_split]
[delay=250]
[rotate=a.com;b.com;c.com]

Example:

CONNECT [host]:[port] HTTP/1.1[crlf]Host: [host][crlf]User-Agent: SocksRevivePC[crlf][crlf]

Payload modes read and log multiple immediate HTTP responses. This supports proxy chains that return more than one status before the tunnel is ready, such as:

HTTP/1.1 403 Forbidden
HTTP/1.1 101 Switching Protocols
SSH-2.0-...

HTTP status lines are shown in the Logs tab as Proxy Status entries.

Proxy rotation

In Payload SSH mode, the Proxy host field supports multiple entries. Separate entries with #, comma, semicolon, or new lines.

Example with a shared port:

52.85.78.104#52.85.78.91#52.85.78.22#52.85.78.28

Set the Proxy port field to the shared port, such as:

80

Entries may also include individual ports:

52.85.78.104:80#52.85.78.91:8080#proxy.example.com:443

The app tries each proxy until the full sequence succeeds:

TCP connect
Payload response
SSH handshake

The [rotate=...] payload placeholder supports the same separators:

[rotate=host1#host2#host3]

Auto reconnect

Reconnect options are in the Main tab:

Reconnect: on/off
Reconnect delay seconds: default 3
Reconnect max retries: 0 means unlimited
Reconnect check seconds: default 10

When reconnect is enabled, the app checks the tunnel periodically. If the tunnel is lost, it:

  1. Stops the active tunnel.
  2. Removes routes.
  3. Stops tun2socks and releases the TUN adapter.
  4. Waits for the configured delay.
  5. Starts the profile again.

Disconnect and Cancel stop the reconnect loop for the current session.

Logs and diagnostics

Runtime logs are written to:

logs/runtime.log
logs/crash.log

Windows TUN diagnostics:

powershell -ExecutionPolicy Bypass -File .\scripts\diagnose_windows_tun.ps1

Use this when the UI says connected but system traffic is not using the tunnel. The expected Windows route-all entries are:

0.0.0.0/1 through Wintun
128.0.0.0/1 through Wintun

When IPv6 routing or IPv6 leak protection is enabled, expected IPv6 routes are:

::/1 through Wintun
8000::/1 through Wintun

Distribution notes

For normal Windows users, distribute:

dist/SocksRevivePC.exe

Do not distribute debug builds unless support logs are needed.

If Xray mode is required, include the Xray executable and configuration:

tools/xray/xray.exe
configs/xray.json

If Wintun is not embedded, include the official signed DLL beside the EXE or in the supported tools folder.