bol-van/zapret2

1. Core purpose and shape

This repository is an autonomous anti-DPI toolkit called zapret2. Its center is a packet-processing engine that intercepts traffic from the OS, inspects packet dissections, and applies obfuscation/desynchronization strategies before forwarding, dropping, or splitting traffic.

2. Two main runtime engines

There are two primary executables/engines: nfq2/nfqws for Linux/BSD-style packet interception through kernel queues/firewall hooks, and a Windows variant built around WinDivert (nfq2/win.c, nfq2/windows/windivert/*). Both share the same strategy model, but the interception boundary differs by OS.

3. Packet interception boundary

Traffic enters the system from OS-level plumbing, not from a proxy layer. On Linux/OpenWrt the repo uses nftables/iptables-style NFQUEUE redirection and conntrack-aware filters; on Windows it uses WinDivert filters such as --wf-tcp-out, --wf-udp-in, and raw filter expressions. This interception layer is meant to keep most packets in the kernel and only hand relevant flows to user space.

4. Engine pipeline in nfq2

The C engine receives packets, classifies them by L7 protocol and payload type, maintains flow state, and builds a structured “dissect” representation. That representation is then passed through one or more Lua desync instances. The engine decides whether to pass, modify, send fragmented variants, or drop the original packet.

5. Lua strategy layer as the main behavior boundary

The major architectural split is between the C packet engine and the Lua strategy library. lua/zapret-lib.lua, lua/zapret-antidpi.lua, lua/zapret-obfs.lua, and related scripts contain the higher-level anti-DPI tactics, payload generation, and helper functions. The C side provides packet parsing, state tracking, blobs, and sending primitives; Lua expresses strategy logic.

6. Strategy composition model

Instead of hard-coded “modes”, zapret2 uses chained --lua-desync instances inside profiles. Each instance can modify the current dissect, cut itself off after it is no longer useful, and contribute a verdict. Profiles are filtered by protocol, payload type, hostlist membership, and in/out range. This makes the strategy system the core architectural unit rather than a single monolithic firewall rule.

7. Data inputs for obfuscation

The repo ships many binary payload templates in files/fake/* for TLS, HTTP, QUIC, WireGuard, STUN, Discord media discovery, and other protocol signatures. These are loaded as Lua blobs or referenced directly by strategy code. This asset layer is essential because the engine relies on realistic fake packets rather than abstract transforms only.

8. Hostlist and ipset integration

The ipset/ directory contains scripts for downloading, building, and maintaining domain/IP lists used for selective targeting or exclusion. These lists feed the engine’s filtering stage so strategies can be applied only to chosen destinations or classes of traffic. This is one of the main policy/data boundaries in the system.

9. OS/service integration and startup

The init.d/ tree contains service definitions for OpenWrt, OpenRC, systemd, sysvinit, runit, s6, pfSense, and Windows bundle examples. These are not just installers; they define how the packet engine is brought up, how filters are installed, and how list-update timers/services run. The repo is therefore both an engine and a deployment bundle.

10. Build and packaging architecture

Makefile, install_*.sh, docs/compile/*, and the OpenWrt packaging subtree show that the project is built for multiple targets: Linux, embedded OpenWrt, and Windows. There is also some platform-specific support code in nfq2/andr/ and nfq2/windows/, indicating cross-compilation and adapter layers rather than a single native target.

11. Protocol handling and support libraries

Inside nfq2/ the code is split into protocol parsing, conntrack, packet queues, filtering, timers, helpers, hostlists, ipset handling, gzip, crypto, and randomization. The crypto subdirectory suggests TLS/QUIC-related manipulation support, while protocol.c, desync.c, and filter.c likely form the core packet decision path.

12. External integration points

The repo does not depend on external DPI services. Its only important external dependencies are OS packet filtering frameworks, WinDivert on Windows, and standard toolchains/libraries for building. That makes the architecture self-contained and primarily edge-deployed.

13. Operational flow to diagram

A useful diagram would show: OS traffic → firewall/divert filter → engine queue → protocol/payload classification → Lua strategy chain → modified packets sent back to network stack. Side inputs feeding that flow are hostlists/ipsets, blobs/fake payload files, and init/service configuration.

14. What is intentionally not centralized

There is no single “configuration server” or “policy backend.” Strategy behavior is distributed across Lua scripts, lists, service wrappers, and OS-specific filter definitions. That decentralization is central to the repo’s architecture and is what makes it portable across Linux, embedded routers, BSD, and Windows.