Security, precisely

Gearoenix VPN - Ultra Proxy · Last updated: 2026-10-24 · Describes the shipped protocol, version 1

This page says exactly what the app does to your traffic, in the terms an engineer would use, and it is equally precise about what it does not do. Everything here describes the code that ships; where a protection is absent, the page says so rather than implying it.

The shape of every packet

The app runs as an Android VPN service. Every IPv4 packet your device sends is wrapped into one UDP datagram to our server and unwrapped on the other side:

UDP payload = Obfuscate( ChaCha20-Poly1305( frame ) )
frame       = [version][kind][length][your IP packet]

• One packet, one datagram. The data path is connectionless, in the style of WireGuard: nothing is buffered, re-sent or re-ordered at the tunnel layer. The TCP or QUIC connection inside the tunnel handles loss end to end, which avoids head-of-line blocking and the "TCP over TCP" meltdown that tunnels built on reliable transports suffer.
• Sized for mobile networks. The tunnel's inner packet size is 1163 bytes, chosen so the outer datagram never exceeds the 1280-byte minimum that IPv6 links are guaranteed to carry. Cellular paths that cannot fragment therefore never silently drop full-size packets.

Handshake: Noise NK

Sessions are established with the Noise protocol pattern Noise_NK_25519_ChaChaPoly_BLAKE2s: X25519 key agreement, ChaCha20-Poly1305 for the handshake payloads, BLAKE2s as the hash.

• Your device has no long-term key. "N" in NK means the client is anonymous at the protocol level. There is nothing on your phone that identifies it cryptographically, and nothing to steal from it.
• The server's static key is pinned in the app. "K" means the client already knows the server's public key; it is compiled into the app. A server that cannot prove possession of the matching private key fails the handshake, so a man-in-the-middle cannot impersonate us even with a forged certificate, because no certificate is involved.
• Forward secrecy. Both sides contribute fresh ephemeral keys to every session. The session keys are derived from those, so capturing traffic today and obtaining our server key tomorrow does not decrypt the capture.
• Two messages. The client's Hello carries its session token, already encrypted to the server; the server's HelloAck returns the tunnel address and packet size, encrypted to the client. Then both sides switch to the data keys.

Encryption of your traffic

Data packets are sealed with ChaCha20-Poly1305, an authenticated cipher: every datagram is both encrypted and integrity-protected, and a datagram that has been altered in transit is rejected rather than decrypted.

• Explicit nonces. Each datagram carries its own 64-bit counter, which is the unique part of its nonce. The counter is transmitted rather than inferred because UDP can reorder and drop datagrams, so the receiver cannot assume they arrive in sequence.
• Counters never repeat. The counter only ever increases within a session and is never reset. Every new session has a new key, so a counter value is never reused under the same key, which is the one thing a ChaCha20-Poly1305 deployment must guarantee.

Obfuscation: what it is, and what it is not

Before a data packet leaves your device, its first 64 bytes pass through a per-session keyed byte substitution, and a random amount of padding (up to 32 bytes) is added. Only the front of a packet carries structure a deep-packet-inspection box could fingerprint; everything after it is already ciphertext, indistinguishable from random bytes. The result is data traffic with no fixed protocol signature. (The two handshake datagrams are the exception; see below.)

This layer hides the shape of the protocol. It is not encryption, and we do not count it as such. Confidentiality comes entirely from ChaCha20-Poly1305 underneath. Obfuscation exists so that networks which block known VPN protocols by their signature see nothing to match; it does not hide the fact that your device is exchanging UDP traffic with our server, its volume, or its timing.

Session tokens and connect time

Your connect time lives on our control server as a single number: the moment your credit runs out. When the app connects, the control server issues a short token containing your device's random identifier and that expiry, signed with HMAC-SHA256. The VPN server verifies the signature locally with a shared key, so the handshake never waits on a network call, and closes the session the moment the expiry passes. Time earned from an ad while connected is pushed into the live session, so it takes effect immediately.

Inside the device

• IPv4 only; IPv6 is blocked, not leaked. The tunnel carries IPv4. While connected, Android's VPN framework blocks IPv6 traffic entirely because the tunnel declares no IPv6 address or route, so nothing bypasses the tunnel over IPv6.
• DNS goes through the tunnel. The app advertises 1.1.1.1 as the resolver inside the tunnel. We do not inspect, rewrite or log DNS; it is simply carried like any other traffic and exits from the United States.
• Two apps bypass the tunnel on purpose. Gearoenix VPN itself and Google Play are excluded from the tunnel. The app's own traffic (ads, the control server) must not appear to come from a shared datacenter address, which advertising networks treat as invalid traffic, and Google Play's purchase flow fails through a VPN. Everything else on the device is tunneled.

What it does not do

• No anti-replay window at the tunnel layer. Because the data path keeps no per-session state, a captured datagram re-sent by an attacker would be accepted and forwarded as a duplicate inner packet until the session's key changes. It cannot be read or altered, and the TCP or QUIC connection inside discards duplicates, so the practical effect is limited to duplicated packets; it is still a gap we state rather than hide, and a replay window is on the hardening backlog.
• Handshake datagrams are not obfuscated. The two handshake messages are sent as-is: a short plain frame header followed by the Noise message, which is already high-entropy. A network that fingerprints that handshake specifically could recognise the connection attempt, even though it cannot read it. Obfuscating the handshake is on the same hardening backlog.
• No kill switch yet. If the tunnel drops and the app cannot re-establish it, the VPN is torn down and your device's normal connection resumes. Until a kill switch ships, do not rely on the app to block traffic when it is not connected.
• One exit, no multi-hop. Traffic leaves from our servers in the United States and nowhere else. There is no chaining of servers.
• Peer-to-peer traffic is throttled, without inspection. The server blocks the classic BitTorrent ports, caps how many new connections each device may open and how fast it may open them, and closes ports used for spam and network abuse (outbound SMTP, SMB, the usual amplification ports). These rules act on packet headers in real time and keep nothing; they do not look inside your traffic.
• We are not a browser. A VPN hides your traffic from the network you are on and gives you a US address. It does not stop websites from identifying you through cookies, logins or fingerprinting, and it does not make a malicious app on your phone safe.

What we keep

Exactly what the Privacy Policy commits to and nothing more: no browsing history, visited domains, DNS queries or traffic contents, ever. The server keeps session start and stop times and approximate data volume briefly, for capacity and abuse prevention, and the control server keeps your device's random identifier with its time balance, subscription status, referral code and, if you allow notifications, a push token. Advertising, purchases and push notifications go through Google AdMob, RevenueCat and Firebase respectively, each under its own policy.

Reporting a vulnerability

Please report security issues privately to usa-vpn-privacy@gearoenix.com. The same contact is published at /.well-known/security.txt (RFC 9116).