DragonTCP/android

DragonTCP Hybrid Transport

This branch keeps the lightweight DragonTCP Android architecture that was working well:

Android apps
   -> Android VpnService userspace TCP adapter
   -> local HTTP/HTTPS CONNECT proxy on 127.0.0.1:8080
   -> DragonTCP transport over TCP/53
   -> DragonTCP server
   -> destination website

The heavy raw-IP DragonTCP VPN server is not used. The Linux server is again only a relay/proxy server; it does not create a TUN interface and does not need NAT/iptables.

What changed on the wire

The old DragonTCP transport used a fixed text/frame pattern:

UP + request id + length + XOR(0xAD, ASCII CPUSH/CPULL/...)
OK + request id + length + XOR(0xAD, response)

The Hybrid transport replaces that network layer with compact binary records:

Request header (29 bytes)
  1 byte   mode
 16 bytes  random session ID
  8 bytes  sequence / stream offset
  4 bytes  payload length

Response header (5 bytes)
  1 byte   status
  4 bytes  body length

There are no constant UP, OK, CPUSH, CPULL, or DATA strings on the wire.

Payload bytes are masked with a sequence-dependent SHA-256 counter keystream. The operation is still XOR-based, but the XOR bytes change with session, mode, sequence, direction, and block number instead of using the same 0xAD byte for every position.

This is traffic shaping/obfuscation, not authenticated encryption.

Path probing

Before the first proxied connection, the client probes the phone-to-server path once and caches the result for 30 minutes.

Upload and download are tested independently against a ladder from small records through 1 MiB. A binary search is used, so it does not need to fail at every size between the maximum and minimum.

Example log:

path probe: upload=32768 download=1400 persistent=true

If the server is capped at 1400 bytes, the client can discover:

path probe: upload=1400 download=1400 persistent=true

instead of beginning at 1 MiB and repeatedly halving during real traffic.

Separate upload/download sizing

Upload and download maintain independent record sizes. Runtime adaptation is still present as a safety net if network conditions change after the initial probe.

Useful log events remain concise:

adaptive upload chunk: 32768 -> 16384 after transport failure
adaptive download pipeline: 64 -> 32 after transport failure
adaptive download chunk: 1400 -> 700 after transport failure

Batched downloads

One download request can receive many ordered DATA responses. The client uses one download worker but pipelines up to 256 response records per request, subject to an approximately 1 MiB useful-data cap per batch.

This is especially important on restricted paths. If the safe record size is 32 bytes, one TCP/53 request can still bring back many 32-byte records instead of requiring a new request for every 32 useful bytes.

Reconnect behavior

The transport supports persistent TCP connections and forced connection rotation.

Core/CLI semantics:

--chunk-reconnect-every 0   persistent
--chunk-reconnect-every 1   automatic compatibility mode
--chunk-reconnect-every N   rotate after N logical requests, N >= 2

Automatic mode probes persistent request reuse. If it works, DragonTCP keeps the connection. If it does not, DragonTCP falls back to one logical request per TCP connection.

The supplied APK is based on the current Logs Page UI, whose Reconnect field still requires a value of at least 1. In this APK, leave it at 1 for Auto. The full Android source in this package also contains the newer explicit 0 = persistent UI behavior for rebuilding with the Android SDK.

Optional token

The token remains optional.

Server without token:

sudo ./dragontcp-hybrid-server-linux-amd64 --chunk-max 1048576

Server with token:

sudo ./dragontcp-hybrid-server-linux-amd64 \
  --token 'YOUR_SECRET' \
  --chunk-max 1048576

Server

Default server port is TCP/53:

sudo ./dragontcp-hybrid-server-linux-amd64 \
  --port 53 \
  --chunk-max 1048576

Useful debug mode:

sudo ./dragontcp-hybrid-server-linux-amd64 \
  --port 53 \
  --chunk-max 1048576 \
  --debug \
  --debug-stats-interval 10s

The server is a lightweight TCP relay. It does not create Linux TUN devices.

Android

Install DragonTCP-Hybrid-Android-arm64.apk, configure the server IP/port, and connect as before.

Recommended initial settings:

Server:          YOUR_SERVER_IP
Port:            53
Token:           optional
Max chunk:       1048576
Min chunk:       32
Reconnect:       1 (Auto in supplied APK)
Timeout:         2

The Android TUN frontend continues to point applications at the local DragonTCP HTTP proxy. DNS continues to use the existing lightweight adapter's DNS-over-proxy path.

Source layout

core/
  cmd/dragontcp-client/
  cmd/dragontcp-server/
  internal/protocol/     # TCP tuning + legacy helpers
  internal/wire/         # new compact binary framing + changing mask

android/
  src/com/dragontcp/client/
  src/tech/xvanturing/freeproxy/
  lib/arm64-v8a/libdragontcp_client.so

Building the Go core

cd core

go test ./...

go build -trimpath -ldflags='-s -w' \
  -o ../bin/dragontcp-hybrid-server-linux-amd64 \
  ./cmd/dragontcp-server

GOOS=android GOARCH=arm64 CGO_ENABLED=0 \
  go build -trimpath -ldflags='-s -w' \
  -o ../android/lib/arm64-v8a/libdragontcp_client.so \
  ./cmd/dragontcp-client

android/build_apk.sh contains the source build procedure for the Android application when an Android SDK and Kotlin compiler are installed.

Validation performed

The new Go transport was tested with:

• Go unit tests for client/server/wire code.
• changing-mask round-trip test.
• 8 MiB HTTP download through the DragonTCP proxy with SHA-256 equality.
• HTTPS CONNECT download through DragonTCP with byte-for-byte equality.
• persistent connection mode.
• forced reconnect-every-1 mode.
• a server restricted to 1400-byte records, where path probing selected 1400 bytes automatically and the download still completed correctly.

The supplied APK embeds the exact Android ARM64 Go core built from this source.

SafeSpeed v3

This release is built directly from the confirmed-working Hybrid v1. The wire protocol is unchanged: same compact binary request/response headers, same 16-byte session IDs, same SHA-256-derived XOR keystream, same probe packets, same upload transaction behavior, and same server framing.

The only transport scheduling change is that the download pipeline starts at 256 records (the same maximum already supported by v1) instead of starting at 32 and slowly growing one record per successful request. This is especially important when the probed record size is small.

The broken Hybrid v2 changes are intentionally absent: no multi-request upload pipeline and no 65,535-record mega-batches.