Innovative Tunneling Techniques Leverage File Storage, IMAP, Meek, and NTP for Covert Connectivity
A fresh set of unconventional tunneling approaches has surfaced in the world of proxies and VPNs, expanding options for establishing covert network links through everyday services.
File Tunnel
The core idea is straightforward yet effective: when two hosts share access to the same file storage, ordinary files can serve as the medium for TCP connectivity. File-Tunnel listens on a local TCP port; incoming connections cause data to be appended to a file. The remote instance reads the same file, reconstructs the TCP stream, and forwards it to the intended destination. Return traffic flows through a second file. Files are periodically rotated to prevent unbounded growth.
Supported storage includes SMB or NFS shares, FTP servers, RDP or Citrix mounted disks, VirtualBox shared folders, WSL, Docker volumes, and Dropbox. Recent additions provide native S3 and WebDAV support. Because many providers offer inexpensive or free-tier S3-compatible buckets, the resulting tunnel traffic appears as routine object-storage requests. Example invocation on side A forwards RDP while side B acts as the remote endpoint:
- ft.exe --s3 --bucket mybucket --region ru-moscow-1 --access-key XXXXXXXX --secret-key XXXXXXXX -L 5000:192.168.1.20:3389
Environment variables FT_S3_ACCESS_KEY and FT_S3_SECRET_KEY keep credentials off the command line. WebDAV works with services such as Mail.ru Cloud using a simple URL and credentials.
True IMAP Tunnel (Secure)
Building on earlier serverless experiments, True IMAP Tunnel (Secure) uses an IMAP mailbox as the transport. Both tunnel endpoints authenticate to the same account and designate dedicated folders for each direction. Data frames are wrapped as draft messages via the APPEND command; they never traverse SMTP. The receiving side monitors via IDLE or polling, extracts frames, marks messages deleted, and issues EXPUNGE in batches. Optional AES-256-GCM encryption protects frames, and message appearance (subject, attachment filename) can be customized to reduce suspicion. Tested providers include Gmail, Outlook, Seznam, Mail.ru, Yandex, Timeweb, and Rambler. The single Go binary supports SOCKS5, VLESS, SSH, and can run as a Shadowsocks SIP003 plugin.
Meek
Meek, a legacy Tor pluggable transport, offers an alternative when XHTTP fails against certain CDNs. Clients issue HTTP POST requests (up to 64 KB) carrying an X-Session-Id header; the server maps sessions to TCP connections and returns responses in HTTP bodies. Empty POSTs maintain polling intervals that grow from 100 ms to 5 s. Because of its simplicity, Meek functions through shared hosting with small PHP or Python reflectors. Standalone operation is achieved by manually setting TOR_PT_* environment variables, bypassing Tor entirely. A Python wrapper converts the ephemeral SOCKS listener into a fixed TCP port for direct use with tools such as SSH.
ntptun
Extending the ICMP and DNS tunneling lineage, ntptun carries IP or UDP payloads inside NTP mode-3/4 packets using extension fields. The Linux TUN mode provides full IP-over-NTP connectivity; the Windows UDP mode maps multiple clients via port offsets. Recommended deployment places GOST with KCP between the application and ntptun, yielding an HTTP/SOCKS5 proxy whose traffic hides inside NTP. Downstream modes include honest poll (client-driven) and push (server-initiated) with keep-alives; active-probing resistance drops unexpected packets that do not match expected session behavior.
Related articles
Developer Builds Password Manager with Plausible Deniability Using Argon2id and XChaCha20-Poly1305
A Java backend developer rewrote a personal password manager originally built with Electron and React, migrating it to Tauri and Rust while redesigning its storage to support plausible deniability. The new implementation derives keys with Argon2id using a single per-install salt and encrypts files with XChaCha20-Poly1305, storing only random 32-character hex filenames without any headers or magic bytes. Multiple decoy vaults of identical size are created automatically for every user, and all files in the folder receive synchronized timestamps to eliminate metadata-based identification of the active vault. History and sync data are stored as additional encrypted files of the same format, making it impossible to distinguish real from decoy vaults from the filesystem alone. The approach mirrors VeraCrypt hidden volumes but operates on ordinary files and folders, with the explicit goal of providing deniability when a user is compelled to reveal a password.
LxBox Evolves from VPN Client to Comprehensive Network Traffic Management Ecosystem
LxBox has grown from a personal Android client for sing-box into a full ecosystem spanning mobile, desktop, and router platforms. The project now supports a wide range of VPN and proxy protocols within a single routing framework, allowing users to manage corporate SSL VPNs, home WireGuard connections, and proxy servers together. Key security features include default ingress blocking to prevent unauthorized reverse connections through VPN tunnels and protections against traffic leaks via excluded applications. The developer introduced progressive configuration levels, from one-click WARP setup to advanced JSON editing and AI-friendly documentation. The core sing-box-lx fork ranks among the top sing-box derivatives and powers third-party tools such as the upcoming NekoBox 6. LxBox is available on Google Play, F-Droid, and GitHub, with desktop launcher support for Windows 7 and later, macOS, and Linux.
Understanding Russia's TSPU: How DPI Filtering, DNS Manipulation and Traffic Throttling Work
Russia's TSPU system combines hardware filters from RDP.ru with EcoFilter and EcoDPI software to perform both simple IP/port/transport blocking and advanced protocol recognition. The platform inspects DNS queries, SNI fields in TLS handshakes, QUIC packets and HTTP headers to enforce domain blacklists or apply throttling. When simple blocking fails, operators fall back to traffic shaping that drops packets or limits bandwidth after an initial window. Multiple bypass techniques including encrypted DNS tunnels, ECH, and specialized proxies such as Hysteria 2, NaiveProxy and Shadowsocks are examined in detail. The article also outlines future developments including expanded residential whitelists and neural-network-based traffic classification.
ONYX 2.0 Removes Central Servers for Fully Decentralized Tor-Based Messaging and Calls
ONYX 2.0-beta marks a major shift from its previously centralized design to a serverless architecture that relies entirely on Tor for all communications. Each user account is now represented solely by a cryptographic key pair generated on first launch, with recovery handled through a 12-word seed phrase. Devices connect directly via onion services, and the application bundles its own Tor daemon on desktop platforms while using tor-android on mobile devices. Voice calls are supported through an embedded local TURN server, delivering acceptable quality with 1-3 second latency despite the anonymity overhead. Message delivery now depends on recipient availability, with undelivered messages stored locally on the sender and retried automatically. The update deliberately removes features such as HTTP or SOCKS5 proxies and link previews to prevent IP leaks or external traffic. Developers released the beta to gather feedback on stability across network changes and multi-device scenarios.