Packet boundary

TLS and HTTP shaping happen inside STATIC’s Rust process. Packet shaping is a separate Linux traffic-control/eBPF program, ttl_editor.c, which can run alongside STATIC on a configured Linux path. The Windows distribution hosts this path inside WSL2. A standalone macOS or Windows STATIC process does not acquire Linux packet mutation by selecting a JSON profile.

The handoff

ebpf.rs derives a PacketProfile from the active materialized profile. It takes the presented platform from profile_identity (falling back to fingerprint.os), chooses a platform default, and applies any packet_profile overrides. Supported fields include TTL, ToS, TCP window, MSS, window scale, TCP option layout, and selected randomization flags. At startup and when a profile is selected via the control API, STATIC attempts to write that profile into a pinned eBPF map at /sys/fs/bpf/404/fingerprint_profiles on Linux.

Three conditions must line up

1. The eBPF program must be attached to the actual outgoing interface.
2. Its expected map must be pinned and accessible to the STATIC process with sufficient permissions.
3. The active profile must successfully sync into that map.

An attach command alone proves none of the later conditions. If a sync fails, the current code logs a warning; it does not make proxy startup fail. Inspect the map and outgoing packets if this layer is essential to a test. The Linux CLI guide treats packet handling as optional for this reason.

Where the boundary is

The proxy does not rewrite the host TCP handshake simply because its upstream TLS plan changes. Network routing, OS behavior, interfaces, and privileges can alter or bypass what the packet program sees. STATIC’s contract is to materialize and attempt to sync the selected target; the eBPF code applies supported packet changes when correctly deployed.

Source: STATIC’s packet bridge, eBPF program, and Linux runtime notes.