• Added protection against port scanning by malicious apps. Sensitive local service ports can now be excluded from unwanted analysis and probing, improving the overall safety of the routing stack. • Reworked the sing-box implementation. sing-box has been moved to a profile-based architecture, allowing much more flexible configuration for different groups of apps. Each profile now has: its own app list its own t2s instance its own ports and settings its own set of sing-box servers • Added multi-server support inside sing-box profiles. A single profile can now run multiple sing-box servers at the same time, generate a backend port list for t2s, and route selected apps through that profile independently. • Removed the old transparent-mode implementation from sing-box. The new design is focused on the socks5 pipeline and profile-based tunneling for a cleaner and more maintainable setup. • Added protection against overlapping app assignments. The app can now prevent the same package from being assigned to conflicting programs/profiles, helping avoid routing mistakes and iptables confusion. • Improved smart port handling for sing-box. Port generation and config editing now use smarter conflict-aware selection, including checks across profiles, servers, and internal service ports. • Improved hotspot integration for sing-box. Hotspot mode can now work with a selected sing-box profile instead of applying globally. This gives better control over which profile is exposed for hotspot routing. • Improved hotspot safety logic in the app. Hotspot settings are no longer committed until the user finishes a valid selection, preventing broken states such as enabled hotspot mode without a selected target. • Updated the sing-box UI in the app. The new interface is now profile-oriented and better matches the backend design, with cleaner profile/server management and easier configuration flow. • General stability and structure improvements. Internal logic was cleaned up across the daemon and app to better support profile-based routing, safer configuration, and future expansion.

ZDT-D is a root module for Android designed for advanced network compatibility, DPI circumvention, DNS handling, and local proxy orchestration. Unlike a classic Android VPN app, ZDT-D does not rely on VpnService as its primary traffic engine. Instead, it uses a root daemon, iptables/ip6tables, UID-based routing, NFQUEUE, and local transparent redirection to selectively pass traffic into different processing pipelines. The project includes: - a local Rust daemon (zdtd) - an Android application for configuration and status control - bundled networking tools for different routing and DPI-bypass scenarios What makes ZDT-D different from a classic VPN A traditional Android VPN usually works through VpnService, creates a virtual TUN interface, and routes traffic through a single VPN pipeline. ZDT-D uses a different model: - works with root privileges - applies rules through iptables / ip6tables - routes traffic by Android app UID - supports NFQUEUE-based packet processing - supports transparent redirect to local services on 127.0.0.1 - can combine multiple engines for different scenarios instead of forcing one global VPN tunnel This makes ZDT-D closer to a root-based transparent traffic manager than to a standard VPN client. Traffic routing model ZDT-D supports more than one traffic handling path. A. NFQUEUE path Used for packet-level processing. Typical logic: - selected Android packages are converted into UIDs - iptables rules are added in mangle - matching traffic is sent to NFQUEUE - userspace processor handles the packets B. Transparent local redirection Used for local service pipelines. Typical logic: - selected Android app UIDs are resolved - iptables rules are attached to OUTPUT - traffic is redirected to local listeners on 127.0.0.1:<port> - local component processes the stream C. DNS handling dnscrypt-proxy can be started before the rest of the pipeline so DNS resolution can be handled in a controlled way. How app selection works ZDT-D does not blindly route all device traffic. It can work with selected applications: 1. package names are collected from user settings 2. package names are resolved into Linux UIDs 3. iptables rules are generated using -m owner --uid-owner 4. only traffic belonging to those apps is redirected or queued This allows more selective routing than a simple "all traffic through one tunnel" design. Runtime protection ZDT-D includes a runtime protector for important service processes. Depending on configuration, it can: - acquire a kernel wake lock - adjust oom_score_adj - work in Off, On, or Auto mode - react differently to screen-on / screen-off states This part is intended to improve service stability during idle or power-managed device states. Privacy ZDT-D does not collect, transmit, sell, share, or use personal data. All configuration, routing, rule management, and runtime control required for the module to work are performed locally on the installed device. The project does not require remote telemetry or analytics for core functionality. If the application connects to external resources, it does so only for actions explicitly requested by the user, such as checking releases or downloading updates from official upstream sources. Safety - Some antivirus products may flag DPI-related tools because they work with low-level network behavior. - ZDT-D is intended for advanced network compatibility, routing control, and research / enthusiast use. - Device compatibility may vary depending on ROM behavior, SELinux handling, kernel options, and root environment. - Some features depend on working iptables/ip6tables support on the device. Notes - IPv6 behavior may differ across devices and firmware builds. - Some functions may depend on the behavior of the root environment and firmware implementation. - For additional usage notes and explanations, see: https://github.com/GAME-OVER-op/ZDT-D/blob/main/INSTRUCTIONS.md The app is available in Russian and English.