NetVeil

Protocol-level traffic obfuscation engine for network evasion research

Why NetVeil • How It Works • Quick Start • Transports • Benchmarks • Roadmap

---

Why NetVeil

Deep Packet Inspection has evolved far beyond simple port-based filtering. Modern DPI appliances classify traffic using payload entropy analysis, protocol fingerprinting (JA3/JA4 hashes), statistical timing models, and machine-learning classifiers trained on flow metadata. A simple VPN tunnel or SSH port-forward no longer hides what you're doing — it just moves the goalposts.

NetVeil was built to close that gap. Rather than wrapping traffic in a single layer of encryption and hoping for the best, NetVeil reshapes every observable property of your traffic — payload structure, packet sizes, timing patterns, and protocol fingerprints — so that what hits the wire is statistically indistinguishable from whatever traffic profile you choose.

We built NetVeil because we needed it ourselves. BypassCore's research into anti-cheat and anti-tamper systems repeatedly ran into network-layer inspection that off-the-shelf tools couldn't defeat. The techniques we developed for that work turned out to be broadly useful for anyone studying network censorship, traffic analysis resistance, or protocol privacy.

This is an open-source research release. It includes the core obfuscation engine, two fully functional transports, and the pluggable architecture. The commercial NetVeil Pro builds on top of this with additional transports, managed relay infrastructure, and enterprise support.

How It Works

NetVeil sits between your application and the network as a local proxy. Every packet passes through a three-stage pipeline before it leaves your machine:

                    ┌─────────────────────────────────────────┐
  Application       │              NetVeil Engine              │         Wire
  ───────────►      │                                         │      ───────────►
                    │  ┌───────────┐  ┌──────────┐  ┌──────┐ │
   raw traffic      │  │ Encrypt & │  │ Pad &    │  │Shape │ │     obfuscated
   (plaintext)      │  │ Integrity │─▶│ Fragment │─▶│ &    │ │      traffic
                    │  └───────────┘  └──────────┘  │Emit  │ │
                    │                               └──────┘ │
                    └─────────────────────────────────────────┘

Stage 1 — Encrypt & Integrity. Payload is encrypted with ChaCha20-Poly1305 or AES-256-GCM (your choice). Session keys are established via X25519 ephemeral key exchange with HKDF-SHA256 derivation. Every packet is authenticated — tampered data is rejected before it reaches the transport layer.

Stage 2 — Pad & Fragment. Raw ciphertext leaks payload length. NetVeil pads packets using one of three strategies — uniform random, bucket-quantized, or profile-matched — to normalize the size distribution. Large payloads are fragmented into variable-length chunks so that flow-level size analysis can't reconstruct the original message boundaries.

Stage 3 — Shape & Emit. The traffic scheduler controls when packets are actually sent. Constant-rate mode emits at fixed intervals with configurable jitter. Exponential mode draws inter-packet delays from a Poisson process that mimics real user browsing. The scheduler can also inject cover traffic (fake keepalives) during idle periods to prevent "silence detection" by DPI systems.

After shaping, the packet is handed to the active transport, which applies protocol-specific wrapping — making the traffic look like random noise, HTTP requests, or a Noise Protocol session.

Quick Start

Install from source

git clone https://github.com/bypasscore/netveil.git
cd netveil
cargo build --release

Run the proxy

# Copy and edit the example config
cp netveil.toml my-config.toml
# Edit listen_addr, remote_addr, and transport as needed

# Start the obfuscation proxy
./target/release/netveil-proxy --config my-config.toml

Use as a library

Add to your Cargo.toml:

[dependencies]
netveil = "0.4"

use netveil::core::config::NetVeilConfig;
use netveil::engine::ObfuscationEngine;

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let config = NetVeilConfig::from_file("netveil.toml")?;
    let engine = ObfuscationEngine::new(config)?;
    engine.run().await?;
    Ok(())
}

Transports

NetVeil's pluggable transport architecture lets you swap obfuscation strategies without changing your application code. Each transport implements the same Transport trait and handles the protocol-specific transformation.

Transport	Status	DPI Resistance	Description
Randomizer	Stable	Entropy-based DPI	Encrypted payloads padded to random lengths. Looks like pure noise. Effective against signature-based and entropy-analysis DPI.
HTTP Mimicry	Stable	Protocol-fingerprint DPI	Wraps traffic in realistic HTTP request/response pairs with rotating User-Agents, plausible headers, and valid content types. Pair with real TLS for JA3 mimicry.
Noise XK	Preview	Advanced DPI	Uses the Noise Protocol Framework for mutual authentication with identity hiding. Post-handshake traffic is indistinguishable from random. Full implementation in NetVeil Pro.
DoH Tunnel	Planned	DNS-based filtering	Tunnels data over DNS-over-HTTPS queries to resolver endpoints. Designed for environments where only DNS traffic is permitted.
WebSocket Shaped	Planned	WebSocket inspection	Obfuscated traffic over shaped WebSocket frames with realistic connection lifecycle patterns.

Choosing a transport

• Randomizer is the fastest and simplest. Use it when DPI is signature-based or when you control both endpoints. It won't survive a whitelist-only network (where only known protocols are allowed), but it defeats any system looking for protocol fingerprints or payload patterns.

• HTTP Mimicry survives shallow-to-moderate DPI inspection. If the DPI system is checking that port 443 traffic actually looks like HTTPS, this transport passes. For advanced inspection that checks JA3/JA4 hashes, combine with the built-in TLS fingerprint mimicry module.

• Noise XK provides the strongest cryptographic guarantees including forward secrecy and mutual authentication. It's the right choice when the adversary can actively tamper with traffic (MITM), not just observe it.

Configuration

Full configuration reference is at docs.bypasscore.com/netveil/config. Here are the key knobs:

# Transport selection
transport = "randomizer"     # or "http_mimicry", "noise_xk"

# Timing evasion
timing_jitter = true
jitter_range_ms = [10, 75]   # Uniform random delay per packet

# Padding strategy
[padding]
strategy = "uniform"          # "uniform", "bucketed", "profile_matched"
min_bytes = 32
max_bytes = 512

# Fragmentation
fragmentation = true
fragment_range = [64, 512]    # Random fragment sizes in this range

Benchmarks

Measured on AMD Ryzen 9 7950X, 64 GB DDR5-5600, Linux 6.8, Rust 1.82.

Operation	Payload	Throughput	Overhead
ChaCha20-Poly1305 encrypt	1400 B	4.2 GB/s	+28 B (nonce + tag)
AES-256-GCM encrypt	1400 B	6.8 GB/s	+28 B (nonce + tag)
Randomizer wrap	1400 B	1.9 GB/s	+32–512 B (padding)
Randomizer unwrap	1400 B	3.1 GB/s	—
HTTP Mimicry wrap	1400 B	890 MB/s	+200–400 B (headers)

Latency overhead per packet is under 5 microseconds for Randomizer and under 12 microseconds for HTTP Mimicry (excluding network RTT and configured jitter).

Run the benchmarks yourself:

cargo bench

Architecture

netveil/
├── src/
│   ├── core/
│   │   ├── config.rs       # Configuration types and validation
│   │   ├── error.rs        # Error types
│   │   ├── packet.rs       # Wire packet format and codec
│   │   └── session.rs      # Session management and key lifecycle
│   ├── crypto/
│   │   ├── handshake.rs    # X25519 + HKDF key exchange
│   │   └── symmetric.rs    # AEAD encryption (ChaCha20/AES-256)
│   ├── engine/
│   │   ├── mod.rs          # Main proxy engine and connection handler
│   │   └── scheduler.rs    # Traffic timing and emission control
│   ├── protocols/
│   │   └── fingerprint.rs  # TLS fingerprint (JA3/JA4) database and mimicry
│   ├── transports/
│   │   ├── mod.rs          # Transport trait and registry
│   │   ├── randomizer.rs   # Random-noise transport
│   │   ├── http_mimicry.rs # HTTP-mimicking transport
│   │   └── noise.rs        # Noise Protocol transport (preview)
│   ├── bin/
│   │   └── proxy.rs        # CLI proxy binary
│   └── lib.rs              # Library root
├── examples/
│   ├── basic_proxy.rs      # Minimal proxy setup
│   └── http_mimicry.rs     # HTTP Mimicry transport demo
├── benches/
│   ├── throughput.rs        # Encryption throughput benchmarks
│   └── obfuscation_overhead.rs  # Transport overhead benchmarks
└── netveil.toml             # Example configuration

Writing a Custom Transport

The Transport trait is designed to be straightforward to implement:

use async_trait::async_trait;
use bytes::Bytes;
use netveil::transports::{Transport, TransportType};
use netveil::core::error::Result;

pub struct MyTransport;

#[async_trait]
impl Transport for MyTransport {
    async fn wrap(&self, payload: Bytes, session_key: &[u8]) -> Result<Bytes> {
        // Transform plaintext into your protocol's wire format
        todo!()
    }

    async fn unwrap(&self, wire_data: Bytes, session_key: &[u8]) -> Result<Bytes> {
        // Extract plaintext from wire format
        todo!()
    }

    async fn generate_cover_traffic(&self) -> Result<Bytes> {
        // Return fake traffic for idle periods
        todo!()
    }

    fn transport_type(&self) -> TransportType { TransportType::Randomizer }
    fn name(&self) -> &'static str { "my-transport" }
}

Register your transport with the engine and it inherits all of NetVeil's encryption, padding, fragmentation, and scheduling for free.

Roadmap

• Core obfuscation engine with pluggable transport architecture
• X25519 + HKDF-SHA256 key exchange
• ChaCha20-Poly1305 and AES-256-GCM encryption
• Randomizer transport (stable)
• HTTP Mimicry transport (stable)
• Traffic scheduler with constant-rate and exponential modes
• TLS fingerprint (JA3/JA4) database for mimicry
• Configurable padding strategies (uniform, bucketed, profile-matched)
• Noise XK transport (full implementation)
• DNS-over-HTTPS tunnel transport
• WebSocket shaped transport
• QUIC-based transport with connection migration
• Adaptive traffic profiling from pcap captures
• Multi-hop relay chaining
• Built-in traffic analysis test suite

Research Background

NetVeil builds on published research in traffic obfuscation and censorship resistance:

• Pluggable Transports — The PT specification by the Tor Project established the architecture for modular traffic transformation. NetVeil adopts the same separation of concerns between encryption and protocol shaping.

• Protocol Obfuscation Taxonomy — Liang Wang et al.'s "Seeing through Network-Protocol Obfuscation" (CCS 2015) categorizes obfuscation approaches into randomization, mimicry, and tunneling. NetVeil provides implementations across all three categories.

• Traffic Analysis Resistance — The padding and scheduling subsystems draw from research on traffic analysis of encrypted connections, applying packet-level countermeasures that address both content and metadata leakage.

• Great Firewall Evasion — Recent work on advancing obfuscation strategies against China's GFW (2025) informs our approach to surviving active probing and protocol whitelisting.

Responsible Use

NetVeil is a security research tool. It is published to advance the understanding of network traffic analysis and to help defenders evaluate the resilience of their monitoring systems. We believe that the same techniques used to bypass inspection systems are essential for building better ones.

This software is intended for:

• Security researchers studying DPI and traffic analysis
• Red teams evaluating network monitoring coverage
• Privacy engineers building censorship-resistant tools
• Developers testing the robustness of network security appliances

Please use this tool responsibly and in compliance with applicable laws.

License

MIT — see LICENSE for details.

Contact

Have questions, need a custom transport, or interested in NetVeil Pro?

• Email: contact@bypasscore.com
• Telegram: @bypasscore
• Web: bypasscore.com

Support

Help keep BypassCore open-source and independent.

Network	Address
Polygon	0xd0f38b51496bee61ea5e9e56e2c414b607ab011a
Ethereum	0xd0f38b51496bee61ea5e9e56e2c414b607ab011a
BSC	0xd0f38b51496bee61ea5e9e56e2c414b607ab011a
Arbitrum	0xd0f38b51496bee61ea5e9e56e2c414b607ab011a
Optimism	0xd0f38b51496bee61ea5e9e56e2c414b607ab011a
Avalanche	0xd0f38b51496bee61ea5e9e56e2c414b607ab011a

USDT / USDC / ETH / BNB accepted on all networks.