Abstract#

Linux Kodachi is not a single program but a complete privacy platform. It spans three tiers: a hardened, Debian-based operating system; a server fleet of VPN, proxy, and authentication nodes on takedown-resistant hosting; and an online service layer at kodachi.cloud that provides verification tools, license management, and software distribution. The design goal is that an ordinary user can reach a strong, verifiable anonymity posture in minutes rather than hours, can verify that the software they run is the software that was published, and can collapse their posture to a safe state instantly under duress.

This paper documents the platform as built, across all three tiers. Tier one (the operating system) is a Rust backend of roughly seventeen single-purpose service binaries plus an eight-binary AI workspace, driven by a single Tauri and Svelte desktop dashboard, shipped as a live ISO in Terminal, Desktop (XFCE), and Minimal editions with an extensive hardening stack (hardened_malloc, tirdad, kloak, AppArmor, USBGuard, a DNSCrypt-only DNS architecture, and over forty kernel sysctl hardening directives). Tier two (the server fleet) is provisioned by twenty-seven Bash scripts across five phases and distributes single-use, session-encrypted VPN configuration "cards" from elastic worker nodes to a master node. Tier three (the online platform) hosts a public verification toolkit (IP, DNS, Tor, fingerprint, domain, and freshness checks), a customer license portal, an access-controlled admin command center, and an in-house downloads platform with live telemetry.

The paper presents Kodachi's threat model and design principles, deep-dives every layer, analyzes the cryptographic and authentication machinery that binds a client to the fleet, documents the end-to-end signing and integrity chain, and closes with a security analysis, a comparison with Tails, Whonix, and Qubes OS, a candid statement of limitations, and a roadmap. The central thesis is that privacy tooling fails most often not because its cryptography is weak but because its operational surface is hard to use correctly and impossible to verify. Kodachi's answer is defense in depth plus operability across the whole stack: every privacy control is a signed, single-purpose, JSON-emitting binary; every binary is verifiable against a published manifest; every dangerous action has a graduated, reversible counterpart; and the same discipline that governs the client extends to the fleet and the cloud services behind it.

1. Introduction and Motivation#

1.1 The problem#

Network privacy on the modern internet is not a single control but a system property. A user who runs a VPN but leaks DNS is not private. A user who routes traffic through Tor but reuses a stable MAC address on a hostile local network is not anonymous. A user who achieves perfect network anonymity but leaves recoverable artifacts in RAM, swap, and browser storage is not forensically safe. Privacy fails at the seams between tools, and those seams are exactly where non-expert users cannot see.

Three structural problems recur across the privacy-tooling landscape:

1. Assembly burden. Strong anonymity usually requires correctly composing a VPN, Tor, an encrypted DNS resolver, a firewall kill switch, MAC randomization, and anti-forensic storage handling. Each component has its own configuration language and failure modes. Misconfiguration is silent and the cost of a mistake is deanonymization.

2. Verification gap. Even a user who installs the right tools generally cannot answer the question "is the binary I am about to run the binary the project published, and has it been tampered with?" Without an end-to-end signing and integrity chain, the trust placed in privacy software is faith, not evidence.

3. No graceful failure. Privacy tools tend to be binary: connected or not, on or off. Real adversarial situations are graduated. A user who detects that something is wrong needs a response that matches the threat, from "block new connections but keep my session" up to "wipe RAM, destroy keys, and power off," without having to improvise under stress.

A fourth problem is structural to the service, not the client: a privacy distribution that depends on third-party VPN providers inherits their logging policies, their jurisdictions, and their willingness to fold under legal pressure. To control that, Kodachi runs its own infrastructure.

1.2 Kodachi's response#

Kodachi treats anonymity as an engineered, observable, and reversible system property, end to end. Its response rests on four commitments:

• A single coherent stack, not a toolbox. VPN, Tor, encrypted DNS, leak detection, MAC and hostname randomization, firewall control, integrity verification, and anti-forensic wiping are all first-class, pre-integrated services driven from one dashboard, and they are backed by infrastructure the project owns.
• Everything verifiable. Every Kodachi-authored binary is signed with an RSA-4096 key and published alongside a hash manifest. The running system can verify itself against that manifest, and a remote user can verify a download before installing it.
• Graduated, reversible controls. Emergency response is a four-level ladder, from suspicious-activity monitoring to a hard panic that wipes RAM and powers off, plus a kill switch with explicit arm, activate, and disarm states. Nothing destructive is one accidental click away.
• Operability as a security property. The hardest part of privacy is using it correctly. Kodachi invests as heavily in the dashboard, the consistency of its command surface, the verification tools, and its self-checks as it does in the underlying cryptography, because an unusable control is a control that will be used wrong.

1.3 Who Kodachi is for#

Kodachi is built for privacy-conscious individuals who need anonymous internet access without becoming network engineers; for security researchers and penetration testers who need a disposable, hardened, instrumented base; for journalists, activists, and others operating in high-risk environments; for government, defense, law enforcement, and intelligence teams, and for critical-infrastructure operators (telecom and regulatory authorities, power and utility networks, hospital networks, and financial-market infrastructure) for whom network isolation and operational security are non-negotiable requirements rather than preferences; and for anyone who needs forensic-resistant computing where the goal is to leave as little recoverable trace as possible.

1.4 How this document is organized#

After the threat model (section 2) and design principles (section 3), the paper is organized in three parts that mirror the platform's three tiers:

• Part I, the operating system (sections 4 to 10): architecture, the Rust backend and its third-party components, the desktop dashboard, authentication, routing, the live-build editions with their packages, tuning, and hardening, and the integrity chain.
• Part II, the server infrastructure (section 11): the fleet topology, the twenty-seven-script provisioning system, the card lifecycle, and the Apache and PKI layer.
• Part III, the online platform (sections 12 to 16): the public verification toolkit, the customer license portal, the admin command center, the licensing and payment model, and the downloads platform.

The cross-cutting analysis (sections 17 to 22) covers emergency response, a security analysis against the threat model, a comparison with related work, limitations, future directions, and the conclusion, followed by appendices.

2. Threat Model#

A privacy system is only meaningful against a stated adversary. Kodachi is designed against the following adversaries and goals, and explicitly not against others.

2.1 Adversaries Kodachi defends against#

2.2 What Kodachi does not claim to defend against#

Honesty about scope is itself a security feature. Kodachi does not claim protection against:

• A compromised hardware platform or firmware (malicious BIOS/UEFI, hardware implants, compromised CPU microcode). Kodachi assumes the hardware is trustworthy at boot, while still applying microcode updates and firmware refresh where it can.
• A global passive adversary capable of correlating traffic at both ends of the Tor network simultaneously. This is an open problem for all low-latency anonymity systems, including Tor itself.
• An adversary with persistent root on the running system before Kodachi's integrity checks run. Kodachi verifies its own binaries, but a kernel-level rootkit installed prior to boot is outside scope.
• User operational mistakes outside the tooling, such as logging into a personally identifying account over an anonymous circuit.
• Physical access to an unlocked, running machine. The emergency controls assume the legitimate user is present to trigger them.

2.3 Trust assumptions#

• Root access is available and required for system-level operations (firewall, MAC, DNS, wiping).
• The hardware is not physically compromised at boot.
• The Kodachi VPS infrastructure is trusted operationally to route traffic, but the design deliberately minimizes what any single node learns: worker nodes generate configuration, the master node mediates authentication, and cards are single-use and session-bound. Beyond per-session log wiping, the worker fleet is treated as ephemeral: rather than maintaining long-lived servers, the entire fleet of VPS nodes is periodically destroyed and rebuilt from clean images, so no node accumulates state over time and no compromise can persist across a rebuild cycle. The infrastructure runs on DMCA-resistant hosting precisely so the routing layer survives legal pressure that would shut down conventional providers. Users who do not wish to extend that trust can bring their own VPN configuration, use the free, account-less Riseup or VPN Gate pools, connect through any of the commercial providers wired into the dashboard ready to use (NordVPN, ProtonVPN, Mullvad, IVPN, Private Internet Access, Surfshark, AirVPN, Windscribe, ExpressVPN, TorGuard), or route through Tor.
• The signing private key is held only by the maintainer and never ships with the product. The corresponding public key ships everywhere and can only verify, not sign.

3. Design Principles#

Kodachi's engineering is governed by hard rules enforced across the codebase. These are the load-bearing invariants that make the security claims credible.

3.1 Single-purpose, composable services#

Each privacy capability is its own binary with one job: dns-switch manages DNS, tor-switch manages Tor, routing-switch manages multi-protocol routing, integrity-check verifies signatures. Services compose through a shared CLI contract rather than through a monolith, which keeps each component auditable in isolation and keeps the blast radius of any one bug small.

3.2 Uniform CLI and JSON-first output#

Every service is built on a shared cli-core library and shares a common flag contract: -v/--version, -n/--info, -h/--help, and the JSON output family (--json, --json-pretty, --json-human) are available on every service, and most services additionally expose the cli-core global set (-e/--examples, -t/--timeout, and -o/--output-format, which forces text or json). All machine-readable output is JSON produced via serde_json. This uniformity is what lets a single dashboard drive over 150 commands across a dozen backends without bespoke parsing per service: the GUI tunnels almost every call through one generic executor and appends --json.

3.3 Embedded configuration, not external YAML#

Static configuration lives in each service's config.rs, compiled into the binary. External files are reserved for genuinely runtime-generated data (the DNS database, session tokens, profiles), always in JSON. A signed binary with embedded configuration cannot have its behavior silently altered by editing a side-car config file, and there is no YAML parser surface to attack.

3.4 No hardcoded paths or identities#

No service hardcodes a username or absolute path. Locations are detected dynamically through $HOME, $USER, getpwuid, and the XDG conventions. This prevents an attacker from predicting and pre-seeding paths, and it lets the same binary run correctly for any user.

3.5 Execution-folder containment#

Every service confines its file I/O to its own base directory (temp, cache, logs, output, config subfolders derived from base_dir.join(...)). Services do not write to /tmp or scatter artifacts. For a privacy tool this is essential: uncontrolled temporary files are forensic residue.

3.6 Memory safety and no panics in production#

The entire backend is Rust. Beyond the language's memory-safety guarantees, the codebase forbids .unwrap() and other panic-on-error patterns in production paths; errors are handled with ?, match, if let, and contextual fallbacks, enforced by zero-tolerance warning checks at build time. A panic in a privacy service is not merely a crash; it is a denial-of-service vector and potentially a fail-open condition.

3.7 Additive evolution and verifiable change tracking#

Existing code is preserved: new behavior is added alongside old rather than silently refactoring it away, which keeps the audit trail intact. Every change is recorded in an append-only delta log.

3.8 A consistent release profile#

Every Rust crate, services and dashboard alike, builds with the same release profile: opt-level = 3, lto = "thin", codegen-units = 1, panic = "abort", and strip = true. Full link-time optimization is deliberately avoided because it triggers out-of-memory hangs in the build environment; thin LTO is the tuned compromise.

Part I: The Operating System#

4. Architecture at a Glance#

Kodachi employs a three-tier, service-oriented architecture. Part I covers the client device; Parts II and III cover the fleet and the cloud.

4.1 The layers (client side)#

1. GUI layer (Tauri 2 + Svelte 5 + Vite). The Kodachi Dashboard, a single desktop application presenting every capability through three layouts (Full, Lite, Circle) plus a Security Operations Center (SOC) page and the AutoShield first-boot hardening wizard.
2. Orchestration layer (dashboard hooks). The dashboard/hooks/ directory: the compiled Rust binaries, their JSON configuration (DNS database, Tor config, session tokens, and 96 operation profiles), centralized logs, and result files. In production this lives at /opt/kodachi/dashboard/hooks/.
3. Backend services layer (Rust). Roughly seventeen standalone service binaries, two shared libraries (cli-core, auth-shared), the logs-hook signed logging binary, and the kodachi-ai workspace (8 binaries plus 13 libraries), plus two bundled third-party binaries (oniux, tun2socks). Section 5 gives the precise accounting.

4.2 Control and data flow#

The control plane runs top-down: a user action invokes a Tauri command, which executes the relevant signed Rust binary with the right subcommand, captures its JSON on stdout, and renders the result. Every invocation is logged centrally through logs-hook.

The data plane is separate and runs through the routing stack: user traffic is captured by routing-switch and steered into the selected transport (a native VPN interface, a tun2socks shared tunnel for proxy protocols, or Tor via redsocks), with DNS forced through the same tunnel and continuously checked for leaks.

User action ─▶ Tauri Dashboard ─invoke()▶ Rust command handler ─exec▶ signed service binary
                                                                          │
                                                                          ├─ stdout JSON ─▶ Dashboard ─▶ User
                                                                          └─ audit ─▶ logs-hook

User traffic ─▶ routing-switch ─▶ {VPN tun0/wg0 | tun2socks(localhost:300xx) | Tor via redsocks} ─▶ exit ─▶ Internet
                                          │
                                          └─ dns-switch (encrypted, in-tunnel) ─▶ dns-leak (continuous verification)

5. The Rust Backend and Third-Party Components#

All Rust services follow the patterns in section 3: embedded configuration, JSON-first output, dynamic path detection, a uniform CLI, no .unwrap(), and the shared release profile.

5.1 The complete project inventory and how to count it#

Kodachi 9 comprises 26 Kodachi-authored binaries plus 2 bundled third-party binaries, for 28 signed release binaries in total. Because several different but valid counts circulate, this paper states the full reconciliation explicitly:

• 17 standalone Kodachi service binaries: the privacy and infrastructure tools listed in 5.3 through 5.5 (logs-hook through kodachi-soc).
• 8 AI workspace binaries: the kodachi-ai workspace (5.6).
• 1 Tauri desktop dashboard (section 6).
• 17 + 8 + 1 = 26 Kodachi-authored binaries, all on the unified 9.x version scheme.
• + 2 third-party binaries (oniux, tun2socks) = 28 signed binaries, which is the count in the published manifest.

In addition there are 2 shared libraries (cli-core, auth-shared) and the kodachi-ai workspace's 13 internal libraries, which are not standalone binaries. Separately from the signed-release count, the dashboard's executor enforces an invocation allow-list of 27 permitted hook-binary names; that list is not identical to the 26 authored binaries (it excludes the dashboard, which cannot invoke itself, and it includes the third-party oniux plus the oniux-launcher script wrapper that sets up Linux namespaces before handing off). The top-level release hook directory ships oniux; the launcher exists in the hooks scripts/livebuild install paths. Anything not on the list cannot be invoked. Wherever this paper says "the services," it means the 17 standalone Kodachi service binaries unless stated otherwise.

5.2 Shared foundations#

• cli-core provides the unified CLI infrastructure used by every service: the command builder, the standard result envelope, and the output formatter that implements the --json family of flags and the -e settings-discovery flag. It also carries the signature-verification feature.
• auth-shared is the high-performance authentication cache. It exposes verify_authenticated() and a format-aware variant, serving cached results in under a millisecond by design and falling back to the online-auth binary (typically 100 to 500 ms) only on a cache miss. Every hook that links auth-shared must be listed in the cache's known-binary whitelist, or a valid session will still be refused.
• logs-hook is the secure centralized logging service with rotation. It is a separate signed binary, invoked as a subprocess by every other service (not statically linked into them), which is why it carries its own signature and its own frozen interface while still providing a uniform audit trail. Because it is invoked externally by critical integrations, it is treated as a frozen interface changed only with deliberate care.

5.3 Security services#

• health-control (~15 MB shipped, the largest Kodachi-authored service) is the system's hands. It performs network connectivity checks; blocks and unblocks all internet traffic across nftables, iptables, and UFW; arms, activates, and disarms the kill switch; runs the three panic modes (soft, medium, hard); randomizes MAC addresses and hostnames and synchronizes timezone; reports system, hardware, process, security, network, storage, and service information; computes a security score; manages keyboard anonymization (kloak), file-integrity monitoring (AIDE), and USB protection (USBGuard); and performs anti-forensic wiping of RAM, swap, browser data, and logs. It is the active-response engine. Notably, RAM wiping that earlier privacy distributions delegated to an external package is implemented natively here.
• online-auth (~4.5 MB) performs the challenge-response authentication handshake with the master node (section 7). It uses AES-256-GCM and ChaCha20-Poly1305 for payload and at-rest encryption and zeroize for in-memory key hygiene. It is a critical externally-invoked integration treated as a frozen interface.
• integrity-check (~3.7 MB) is the verification engine. It verifies binary signatures, generates and checks file hashes, and scans directories. It hashes with BLAKE3 (faster than SHA-256 per the upstream BLAKE3 benchmarks) for its per-binary integrity manifests, including the published generated_hashes-v9.0.1.json, with parallel processing. A subtle but important fact, and a recurring source of false alarms: the manifest hashes are BLAKE3, not SHA-256, even though both render as 64 hex characters; they must never be compared against sha256sum. SHA-256 appears only in the human-readable .sig.info reports and as the digest over which the RSA signature is computed.
• kodachi-soc (~3.6 MB) is a read-only host Security Operations Center monitor. It runs sixteen telemetry collectors covering vitals, network state, connections, processes, threats, authentication, privacy posture, and system state, plus dedicated audits for file-integrity monitoring, SUID binaries, the dynamic-linker preload list, kernel taint, and process capabilities, with findings annotated by MITRE ATT&CK technique. It is read-only by design: it never kills a process or edits configuration, because active response is health-control's job. It is hardening-aware: it knows that Kodachi's own defenses (the hardened_malloc preload, a kernel taint from the tirdad module, integrity entries for its own hardening) are expected and does not flag the system's own armor as a compromise.

5.4 Network services#

• dns-switch (~6.6 MB) is the DNS control plane. It ships with a compiled-in curated server set and maintains a runtime database that grows past a thousand servers after remote discovery, across categories (reputable, normal, encrypted, fallback, remotely-fetched). It switches and randomizes servers, performs health monitoring, backs up and restores configuration, manages DNSCrypt and Pi-hole, and operates in a modern mode (driven by systemd-resolved, with global, per-interface, NetworkManager, or automatic methods) or a legacy mode (direct /etc/resolv.conf editing). It performs its own leak verification.
• dns-leak (~5.4 MB) is a dedicated leak detector: it discovers interfaces, queries multiple resolvers, and reports whether DNS is escaping the tunnel.
• ip-fetch (~4.5 MB) is the geolocation and public-IP resolver, with multi-provider fallback and CGNAT detection. It is a dependency of nearly every other network service.
• tor-switch (~8.3 MB) is the Tor control plane, with over sixty commands. It starts, stops, and reloads Tor; torrifies and de-torrifies the entire system through iptables or nftables, with optional DNS-over-Tor and load-balanced multi-instance variants; controls exit nodes by country, region, surveillance alliance, or traffic volume, with matching exclusions; and manages multiple Tor instances including creation, cloning, listing with live exit IPs, and timer-based automatic IP rotation. The instance count scales with available RAM on a square-root curve clamped to three to twenty, budgeting roughly 150 MB per instance, so a typical 8 GB machine runs five instances at about nine percent of RAM. The cap of twenty exists because a single user's browsing cannot meaningfully saturate more circuits, and excess instances only raise entry-guard overlap risk.
• routing-switch (~9.6 MB) is the multi-protocol data-plane router supporting twelve protocols (section 8). It accepts configuration from several sources, all selectable from the dashboard's External VPN Providers tab: the Kodachi worker fleet; the free, account-less Riseup and VPN Gate pools; around a dozen commercial providers wired in ready to use (NordVPN, ProtonVPN, Mullvad, IVPN, Private Internet Access, Surfshark, AirVPN, Windscribe, ExpressVPN, TorGuard); and bring-your-own configs, with auto-detected import of OpenVPN, WireGuard, Shadowsocks, V2Ray, and Hysteria2 files plus the vmess://, vless://, trojan://, ss://, and subscription formats.

5.5 Infrastructure services#

• permission-guard (~2.0 MB) monitors and corrects file permissions in real time.
• online-info-switch (~6.3 MB) is the online-information hub: online/offline detection, a security-news RSS feed, cryptocurrency prices, and system freshness proofs.
• workflow-manager (~4.3 MB) executes batches of commands from JSON templates with conditional logic, dry-run, pause and resume, and resource limits. It is the engine behind Kodachi's saved operation profiles.
• deps-checker (~2.9 MB) verifies system dependencies and can generate an install script for what is missing.
• global-launcher (~2.0 MB) handles global binary deployment with containment, verification, and rollback, including the multicall symlinks in /usr/local/bin.
• conky-status (~4.1 MB) is the unified data gateway for the desktop Conky widgets. It self-verifies its own signature (cached 60 seconds, tied to the binary mtime), runs an async tokio runtime, and aggregates privacy-aware system data.
• kodachi-session-helper is a user-session daemon watching for X11 keyboard shortcuts bound to emergency actions, with anti-spoofing so a synthetic event cannot trigger a panic.

5.6 The Kodachi AI workspace#

kodachi-ai is a Rust workspace providing a natural-language command interface. It comprises eight binaries (ai-cmd, ai-trainer, ai-learner, ai-admin, ai-gateway, ai-discovery, ai-scheduler, ai-monitor, whose crate directories carry longer kodachi- names but whose shipped binaries use the short forms) and thirteen internal libraries spanning core inference, an NLP engine, a learning engine, a command registry, a SQLite data layer, voice and vector operations, and gateway logic. It runs models locally through two inference paths: the bundled essential models (an intent classifier and the all-MiniLM-L6-v2 embedding model with their tokenizers) are ONNX models run through the ONNX Runtime and ship in the binary pack, while larger conversational models are distributed in GGUF format, downloaded after installation, and run through a separate llama.cpp-compatible runtime. Keeping the assistant local-first is a security decision: an AI assistant for a privacy OS that phoned home would be self-defeating. The engine is tiered for cost and accuracy, escalating from a near-instant keyword/TF-IDF match, to the bundled ONNX intent classifier and semantic model, to the local GGUF conversational model, and only optionally to an external model if the user explicitly configures one. A dedicated gateway classifies every AI-invokable command into passive, active, and dangerous tiers, applies per-agent rate limiting and an audit trail, and requires a short-lived approval ticket before any dangerous operation runs, so an AI agent cannot silently perform destructive actions.

5.7 Third-party components#

Kodachi bundles two third-party binaries that are signed at release alongside the Kodachi-authored ones:

• oniux (~25 MB) provides Linux namespace isolation (network and mount namespaces, capability management) for running individual applications through Tor. It is maintained upstream by the Tor Project and tracks the upstream version (v0.11.0 at the time of writing), so it is the one component off the unified 9.x scheme.
• tun2socks (shipped as tun2socks-linux-amd64, ~10 MB) is the userspace tunnel that presents a SOCKS-style proxy as a routable network interface. It is the attachment mechanism for every proxy-class protocol (Shadowsocks, V2Ray, the Xray family, Mieru, Dante, Hysteria2). It is bundled and signed at its upstream version.

Several further third-party components are used but ship as ordinary system packages rather than signed Kodachi binaries: the Tor daemon itself, HAProxy (Tor load balancing), redsocks (Tor transparent proxying), and dnscrypt-proxy (encrypted DNS). The proxy server binaries (V2Ray, Xray, Hysteria2, Mieru) and the Pi-hole installer ship in the offline package cache (section 9) for no-internet installation, but are not part of the signed release manifest.

5.8 Retired projects#

Three earlier AI and desktop workspaces (kodachi-claw, zero-claw, and zeroclaw-desktop) were retired on 2026-05-18 and moved to a rust-archive/ tree. They are no longer built, signed, or shipped. The formerly standalone AutoShield hardening application was merged into the main dashboard on 2026-06-01, so there is now a single GUI application rather than two.

6. The Desktop Dashboard#

The Kodachi Dashboard is the single interface to the entire client stack, built on Tauri 2, Svelte 5, SvelteKit, and Vite. As of the 2026-06-01 consolidation it is the only GUI application. Its frontend uses a custom token-based CSS theme rather than a utility framework. The shipped binary is roughly 25 MB because the Svelte frontend is embedded; a binary near 23.5 MB is a tell-tale sign of an incorrect dev-mode build that would try to serve a local dev URL instead of the embedded UI.

6.1 Layouts and the SOC page#

The dashboard ships three interchangeable layouts that all drive the same backend services and share the same settings, session, and notification state; the user picks one at the welcome screen and can switch at any time. They differ in how much they show on screen and how much memory they keep resident, so the choice is about the operator's needs and the machine's resources, not about feature lock-in. A capability removed from a smaller layout's surface is hidden, not disabled: it is still reachable through the command library or the CLI.

In short: Full is the everything-visible control center, Lite is the trimmed everyday driver, and Circle is the minimal at-a-glance ring. The same security score, status, and command dispatch sit behind all three, so switching layout never changes what Kodachi can do, only how much of it is on screen and how much RAM the GUI holds.

The SOC page is a live security-monitoring view backed by the kodachi-soc service. It renders a neural-map visualization of the host's security posture, grouping telemetry into themed clusters (network into TCP, UDP, and link; threats into rootkit, persistence, integrity, and hardening) so dense signal does not overlap into illegibility. Its refresh interval is user-selectable and defaults to two minutes, conservatively, so the monitor itself does not become a CPU burden on low-power machines.

6.2 The pages and their controls#

The Full layout organizes roughly forty pages into collapsible sidebar groups; the Lite layout exposes a compact subset of about seventeen as flat tabs, and the Circle layout reduces the same capabilities to a radial set of toggles. The groups below describe the user-facing pages and what each one drives. Every page is a thin front end over one or more of the backend services described earlier (section 5), so the controls listed are surfaced from those binaries rather than reimplemented in the GUI.

Overview. A central monitoring hub showing the live security score (0 to 100), the current network identity (IP, geolocation, ISP), a per-module health grid, and a world-map view of the active exit. The score is a weighted sum across categories (system security, privacy and anonymity, network, authentication, device, advanced privacy, and data protection) with an adaptive denominator: checks that do not apply to the current environment drop out of the maximum rather than counting as failures, so both a live ISO and an installed system can legitimately reach 100 percent. It is read-only apart from a refresh toggle and click-to-copy.

Essentials. The everyday privacy controls, grouped for one-click use:

• Actions: one-click toggles for the common operations, login and logout, connect a VPN, torrify routing, enable encrypted DNS, harden the system, randomize MAC, hostname, and timezone, arm the kill switch, verify integrity, run a workflow, wipe, and shut down (with confirmation).
• Hardening: per-module hardening toggles across internet, hardware, services, security, and privacy categories, with apply, revert, and status indicators.
• Tor Instances: turn Tor on or off, view a running/stopped instance grid, browse and select exit nodes by country, speed, and latency, refresh circuits, and choose a load-balancing mode (round-robin, weighted, or consistent-hashing).
• DNS Servers: choose a DNS provider (the Kodachi default, Pi-hole, or DNS-over-Tor), add or remove custom resolvers, toggle DNSCrypt and DNSSEC, and run a leak check.
• Workflows: build, run, edit, and delete multi-step automation sequences with conditional branching.
• Library: search and filter the full catalog of several hundred commands across all services by keyword, service, and danger level, then execute, copy, or inspect any one.
• Emergency: panic controls, kill-switch arm and trigger, integrity verification, RAM and bootloader wipes, clipboard clear, and an emergency egress proxy.
• VPN Providers: the external-provider catalog (the Kodachi fleet, the free Riseup and VPN Gate pools, and the commercial providers wired in ready to use) with browse, fastest or random connect, latency testing, per-provider credential editors, and a config importer that auto-detects OpenVPN, WireGuard, Shadowsocks, V2Ray, Xray, and Hysteria2 formats plus subscription links.
• Mobile Manager: export each protocol's configuration to a phone as a QR code, share link, or downloadable file, with per-protocol app recommendations and bulk export.
• Passwords: generate strong passwords or passphrases via several methods, with entropy display and copy.
• AI Assistant: a natural-language command interface backed by the local AI workspace, with command preview before execution.

Advanced. The same capabilities exposed at full granularity, one page per backend service: Favorites (saved commands), Authentication and the Auth Card (session and credential view), Routing, Tor Switch, DNS Switch, Health Control, Workflow Manager, IP Fetch, Online Info, System Tools, and the AI Assistant. Each page drives its namesake service directly with the service's full command set.

System Monitor. A read-only observability group of seven sub-pages: Resources (CPU, memory, disk with history), Processes (a sortable grid with signal controls), Network (connections and per-interface bandwidth), Firewall (nftables and iptables rules), Startup (auto-start services and boot order), Logs (a filterable system-log viewer), and a Full-only Terminal Tools page that launches TUI monitors such as htop and iftop.

Standing surfaces (footer). Health (the issue-first health dashboard), the SOC page (section 6.1), the Notification Center, Settings, About, and the Help Center. The Settings page has four tabs: Appearance (theme, layout, auto-start, sound), Auto Command Runner (scheduled persistent tasks), Security (password and TOTP protection, auto-lock, threat-response level, recovery codes, an audit log, emergency hotkeys, and the visibility toggle for the destroy control), and Backup and Restore (encrypted restic backups with a target selector and verify/restore). The Help Center is a searchable index of every page and includes a step-by-step routing-configuration wizard.

Guarded controls. A lock screen (when protection is enabled) unlocks with password, TOTP, or recovery code under a progressive lockout, and a clearly-marked destroy control is hidden unless explicitly enabled in Settings, with a configurable confirmation style. As in AutoShield, these destructive actions are deliberately gated, never one accidental click away.

6.3 The command-dispatch model#

A defining architectural choice is that the Svelte components are deliberately thin. Almost every backend interaction tunnels through a single generic Tauri executor in services.rs (execute_service_command / execute_binary_command): the front end names a service (a hook binary) and a subcommand with flags, the executor validates the binary against the 27-name invocation allow-list, resolves its path through a fallback chain (environment variable, then the production /opt/kodachi/dashboard/hooks, then the development tree), builds the actual command line, appends --json, runs the binary (with sudo -n when privileged), and returns its output. There are around twenty commands_*.rs handler modules (ai, autoshield, backup, command_runner, destroy, dns, emergency, guard, health, killswitch, library, logs, monitoring, protection, routing, services, soc, startup, terminal, tor), but the heavy lifting funnels through that one path. This is what makes the dashboard maintainable: adding a capability is mostly a matter of exposing an existing binary subcommand, not writing new IPC plumbing.

A drag-and-drop command queue lets users compose sequences with sequential or parallel execution, real-time status indicators, and four output formats (Text, JSON, JSON Pretty, and a human-readable JSON rendering). A centralized Notification Center unifies event and standing notifications with thresholds, muting, snooze, and grouping. Other surfaces include an embedded terminal, a Mobile manager for per-protocol mobile app configuration, a backup and restore tab, and a connectivity troubleshooter.

6.4 AutoShield#

AutoShield is the guided first-boot hardening wizard. It can be armed so that, on next boot, if at least one action is enabled and the terms have been accepted, the welcome countdown pauses and the system auto-runs the selected hardening steps. Its control grid is grouped and collapsible across eight categories (identity, connectivity, DNS, Tor, hardening, hardware, maintenance, and profiles), exposing roughly thirty controls: VPN-protocol selection, DNS modes, torrify variants, identity masking (hostname, MAC, timezone), hardening levels, hardware toggles (Bluetooth, Wi-Fi, webcam, microphone, USB), RAM wipe, auto-updates, the tirdad and kloak modules, cold-boot defense, IPv6 control, and screen-lock. The destructive verbs are excluded from the GUI by design: there is no panic, nuke, paranoid-mode, or kill-network button in AutoShield; destructive actions live only behind the deliberate, graduated emergency controls. Settings persist atomically (mode 0600, with an optimistic-lock revision counter) to a JSON file in the hooks config directory. The Terminal edition has its own separate login-time welcome script under the same AutoShield brand.

7. Authentication and the Client-to-Fleet Trust Model#

Kodachi binds a client to its VPN fleet through a challenge-response protocol implemented in the PHP authentication system on the master node and the online-auth binary on the client. The goals are: confirm liveness and a valid license, bind the session to a specific device, resist replay and brute force, and hand the client a single-use, session-encrypted VPN configuration.

7.1 The handshake#

Phase 1 (Challenge):
  Client (online-auth) ──POST [challenge endpoint] {hardware_id}──▶ Master
  Master: generate a 64-char challenge from 32 cryptographically random bytes
          generate CSRF token, check blocked-user list, store challenge + timestamp
  Master ──{challenge, csrf_token}──▶ Client

Phase 2 (Solve & Validate):
  Client: apply a fixed, deterministic transform to the challenge to derive the solution
  Client ──POST [validate endpoint] {solution, hardware_id, csrf_token, client_version}──▶ Master
  Master: validate JSON, verify hardware_id format, check CSRF, check rate limit,
          verify client-version compatibility, validate solution against stored challenge
  On success:
          invalidate any existing session for the same hardware_id
          create a new hardware-bound session
          assign a VPS card based on the user's tier
          encrypt the card/API key under the session token
  Master ──{session_token, user_group, card_available, api_key}──▶ Client

Phase 3 (Maintenance, when keep-alive is enabled):
  Client local checker: every 5 minutes, verify session state
  Client heartbeat sender: every 15 minutes
  Client ──POST [session endpoint] {heartbeat, session_token, hardware_id}──▶ Master
  Master: verify session + hardware binding, extend expiration

Phase 4 (Authenticated requests):
  Client ──POST [session-check endpoint] {session_token, hardware_id}──▶ Master ──{valid}──▶ Client

The exact server endpoint paths and the precise challenge-to-solution transform are intentionally omitted from this public edition. They add no defensive value when disclosed: the challenge is a public, single-use value with no client secret in it, so the transform is a liveness and anti-replay check, not the credential. Real entitlement rests on license-key validation and hardware-ID binding over the certificate-pinned TLS channel, plus the single-active-session rule.

7.2 Security parameters#

The handshake rate limit is keyed on the hashed hardware ID, with a ceiling of twenty attempts before a ten-minute lockout (the ceiling was deliberately raised from a stricter default to tolerate retry cascades through Tor and VPN). A separate, stricter throttle (10 attempts per IP per 15 minutes, 5 per key, with a one-hour block) governs the distinct license-activation endpoint (section 15), not this handshake; the two should not be conflated. The client-to-master channel runs over certificate-pinned HTTPS, so the AES-256-GCM and ChaCha20-Poly1305 ciphers above are the application-payload and local auth-cache encryption rather than the wire transport.

The hardware binding is central: a stolen session token is useless without the matching device hash, and only one active session is permitted per device, so a successful authentication elsewhere immediately invalidates the original. The device identifier is a privacy-preserving one-way hash computed locally; raw hardware details never leave the machine, which is what lets device binding work without the server learning anything about the user's hardware.

A note on the challenge construction: the reverse-and-hash step provides liveness and replay protection within the five-minute window. The entitlement decision itself rests on license-key validation and hardware-ID binding carried over the certificate-pinned TLS channel, together with the single-active-session rule. The handshake is slated to move to an HMAC or signature-based construction in a future revision.

7.3 Server-side field encryption#

Sensitive request metadata is encrypted at rest on the server side using public-key cryptography. The server holds only the public key, so it can encrypt incoming data but cannot read it back, which limits what a compromise of stored data can reveal.

8. Routing, Tunneling, and DNS#

8.1 The twelve protocols#

Kodachi's routing-switch supports twelve routing and tunneling protocols, organized by how they attach to the network stack.

Native VPNs own their own kernel interfaces. Tor is attached through redsocks and iptables redirection. Every proxy-style protocol is attached through a shared tun2socks tunnel, each mapped to its own distinct localhost port range. Because the tun2socks protocols share one routing interface, two of them cannot be layered simultaneously; a native VPN, however, can be layered with Tor (for example WireGuard or OpenVPN first, then Tor forced on top). Mita is Kodachi's integration layer over the upstream open-source Mieru protocol, engineered specifically to resist strong national-firewall fingerprinting.

A note on ports: the server-side listening ports for every transport are operationally mutable and are rotated in production in response to ISP-level and censor-level filtering, which is why this paper does not publish the live port numbers. The architectural contract is the protocol set and the attachment model, not any specific port; the only fixed value shown is the standard client-local Tor SOCKS port, which is not remotely reachable. Clients discover the current ports from their signed configuration card, not from a fixed table.

8.2 Routing and DNS modes#

The default routing mode is Direct, which installs the tunnel route as the preferred default route and keeps the original route only as a high-metric recovery path in the current tun2socks code. A Metric mode keeps the original route as an intentional lower-cost fallback for resilience at the cost of a potential leak. Direct remains the strongest default, but the kill-switch guarantee comes from the surrounding leak checks and health-control response, not from the absence of any backup route in the kernel route table.

DNS handling has four modes: auto (DNS flows naturally through the tunnel, the safe default), hybrid (the VPN server's DNS bypasses the tunnel), strict (all DNS is forced through the tunnel), and system (DNS bypasses the tunnel entirely, a leak risk). Direct routing with auto or strict DNS gives the strongest posture, and dns-leak runs continuously to confirm it is holding.

8.3 Tor exit control#

tor-switch exposes fine-grained exit-node control: single country, random, random-worldwide, by continent, and by traffic-volume class, each with a matching exclusion control. Of particular note are the surveillance-alliance selectors, which let a user either target or, more usefully, exclude the Five Eyes (US, GB, CA, AU, NZ), Nine Eyes (adding DK, FR, NL, NO), or Fourteen Eyes (adding DE, BE, IT, ES, SE) jurisdictions. Multi-instance management with per-instance and global timer-based IP rotation rounds out the surface, and load balancing across instances supports round-robin, weighted, and consistent-hashing (client-affinity) modes, with an additional HAProxy application-level layer.

8.4 Encrypted DNS#

DNS can run through DNSCrypt (local or remote, IPv4 and IPv6), through Pi-hole layered on DNSCrypt for combined ad-blocking and encryption, or over Tor for anonymous resolution. The reputable provider set includes Cloudflare, Quad9, AdGuard, OpenDNS, NextDNS, and CleanBrowsing, with IPv4 and IPv6 endpoints, and the runtime database extends well beyond these. The operating system ships configured for DNSCrypt-only resolution (section 9.2), so even a misconfiguration cannot silently fall back to a cleartext resolver.

9. The Live System: Editions, Packages, Tuning, and Hardening#

Kodachi ships as a live bootable ISO that can run amnesically from USB or DVD, be installed to disk with encrypted partitions, or run in a virtual machine. This section documents what is actually in the image.

9.1 Editions and package sets#

The build system is overlay-based: a shared Common base (around 46 explicit packages: live-boot, NetworkManager, OpenSSH, git, build-essential, restic, and core utilities) feeds three distributable editions, with an ARM64 edition scaffolded but not yet shipping.

• Terminal edition (~2.5 GB) adds roughly 250 explicit packages: a deep CLI security and privacy toolkit. It includes networking and analysis tools (nmap, tcpdump, tshark, mtr, whois, macchanger, ethtool, nyx), VPN and anonymity packages (tor, openvpn, wireguard-tools, shadowsocks-libev, torsocks, obfs4proxy, openconnect), proxy and traffic-control tools (proxychains, redsocks, iptables, nftables, haproxy, microsocks), privacy and anti-forensics tools (gnupg2, firejail, apparmor and its profiles, mat2, steghide, scrub, secure-delete, bleachbit, wipe, nwipe, secure-delete), auditing and monitoring (aide, auditd, usbguard, lynis, rkhunter, chkrootkit, fail2ban), a large filesystem and recovery set (lvm2, mdadm, parted, gdisk, btrfs-progs, testdisk, gddrescue, clonezilla, cryptsetup with the nuke-password module, nvme-cli), entropy daemons (rng-tools-debian, jitterentropy-rngd, haveged), and cryptocurrency wallets (electrum, monero). OnionShare-CLI ships for anonymous file sharing.
• Desktop edition (GUI-XFCE) (~4.0 GB) adds the XFCE desktop (around sixty always-on packages) plus optional layers for browsing and networking, multimedia, office, printing and scanning, GUI security tools, and development. It ships the WebKitGTK and GStreamer runtime the dashboard needs, a PipeWire audio stack, the LightDM display manager, the Thunar file manager, KeePassXC, Kleopatra, OnionCircuits, Riseup VPN, GUFW, and the Calamares installer.
• Minimal edition (<1 GB) is the XFCE core only, for emergency boot and forensics. A dedicated forensics boot mode runs entirely in RAM and never touches the target machine's disks, so analysis leaves no trace on the examined system.

9.2 The hardening stack#

Kodachi layers multiple independent hardening mechanisms, several enabled by default:

• hardened_malloc (GrapheneOS, v14, pinned commit, compiled generic-baseline for portability) is installed to /usr/lib/libhardened_malloc.so. Its activation is scoped rather than system-wide: at boot a oneshot service reads the kernel command-line flag kodachi.hmalloc=scoped (included in the default GRUB entry) and records the library path, and a wrapper then prepends it to LD_PRELOAD for specific security-sensitive applications such as the browser. The scoped approach deliberately avoids forcing a hardened allocator on every system daemon, where it can cause compatibility and performance problems, while still protecting the highest-risk processes.
• tirdad, the Whonix TCP initial-sequence-number randomization kernel module, is built via DKMS and force-loaded at boot (with a conditional loader service that respects kernel signature enforcement), to defeat a class of TCP-ISN-based correlation and host-clock leaks.
• kloak, keystroke-timing anonymization, ships as an offline tarball and is installable from the Whonix/Kicksecure repository; its systemd unit is created and enabled when the dependency installer runs, but it is not pre-installed or running by default.
• AppArmor mandatory access control is installed and enabled with the maintained profile set.
• USBGuard device whitelisting and AIDE file-integrity monitoring are installed; firejail application sandboxing is enabled (with the firetools GUI in the desktop edition).
• A DNSCrypt-only DNS architecture: dnscrypt-proxy is installed and enabled, systemd-resolved is disabled and masked, and NetworkManager is configured with dns=none so the resolver chain cannot silently fall back to a cleartext upstream. Belt-and-suspenders services restore the correct resolv.conf if anything disturbs it.
• Encrypted swap and LUKS support: cryptsetup is wired into the initramfs with increased unlock retries and a reboot-on-failure hook that denies an attacker an initramfs rescue shell, plus the cryptsetup-nuke-password capability for emergency key destruction. A boot service activates encrypted swap.
• IPv6 is disabled by default at the kernel command line and reinforced with sysctl, with a boot service that flushes link-local addresses, removing an entire class of leak surface.
• MAC randomization is privacy-by-default through NetworkManager rather than an afterthought script: Wi-Fi scans use a fully random address, each Wi-Fi connection uses a per-boot stable pseudo-random address, and Ethernet uses a per-connection random address, with health-control able to force a fresh randomization on demand.
• The bootloader offers graduated security tiers. The GRUB menu exposes several boot entries arranged as escalating hardening levels, with the stricter tiers adding kernel protections such as integrity lockdown and module signature enforcement, and the highest adding IOMMU/DMA protection, so a user can match boot hardening to their threat level.
• Bluetooth is conditionally disabled by a boot service, and microcode and firmware updates (intel-microcode, amd64-microcode, fwupd) are applied.

9.3 Kernel and system tuning#

A single sysctl profile (/etc/sysctl.d/99-kodachi-hardening.conf, loaded last) applies over forty hardening directives drawn from the Kernel Self-Protection Project and CIS benchmarks. Highlights: kernel pointer and dmesg restriction (kptr_restrict=2, dmesg_restrict=1), disabled unprivileged BPF and restricted perf events, disabled kexec loading, the full set of protected-symlink/hardlink/fifo/regular filesystem protections, ptrace scoping (yama.ptrace_scope=1), a core-dump pattern that discards dumps to prevent information leaks, increased ASLR entropy (mmap_rnd_bits=32), and a network stack hardened with reverse-path filtering, disabled source routing and ICMP redirects, SYN cookies, and martian logging. IPv4 forwarding is intentionally enabled because VPN and Tor routing require it. For memory hygiene against cold-boot and use-after-free exposure, the hardened boot path can also enable init_on_free=1 so freed memory is zeroed.

At boot, a small, deliberate set of systemd units is enabled (Bluetooth conditional-disable, user-group setup, IPv6 link-local flush, encrypted-swap activation, Plymouth first-boot theming, the tirdad loader, and live-session cleanup). The service binaries themselves are on-demand CLI tools, not always-on daemons.

9.4 The build pipeline and offline cache#

Builds always go through a single wrapper script (build-iso.sh), never a bare lb build, because the wrapper synchronizes overlays into the build config, refreshes templates, and verifies boot-theme assets first. It offers graduated build modes from a fast cache-preserving build through a full production "purge" build that pulls from clean Debian mirrors. The image is not assembled from a frozen snapshot: live assets (Conky configuration, the XFCE theme, icons, fonts, and browser profile) are synchronized from the build host's running system on every build, which keeps the shipped desktop identical to the tested one.

The build runs a set of hook files in numeric order across phases (pre-bootstrap, package installation, system configuration, security finalization, cleanup, and a final binary-installation hook); the count is edition-dependent, around 49 for the Terminal edition and around 67 for the Desktop edition (the shared common hooks plus each edition's own). The final hook copies the prebuilt, signed Rust binaries from an offline cache into place and enables only the small set of core boot units. An offline package overlay bundles the proxy tools (V2Ray, Xray, Hysteria2, Mieru), dnscrypt-proxy, the Pi-hole installer, the precompiled Rust binary pack, and a set of cached external GUI applications for the desktop edition (LibreWolf as the default hardened browser, VeraCrypt, the Monero GUI, the Session messenger, OpenSnitch application firewall, and developer tools), so a freshly booted system can be fully provisioned with no internet access.

9.5 Versioning#

A note on versioning that frequently confuses observers: 9.0.1 is the architectural and licensing baseline, but the three product channels (binary pack, terminal ISO, desktop ISO) each carry an independently advancing nightly build stamp, so the live development stamp reads as a higher number (for example in the 9.8.x range) even though the licensed major version remains 9. The stamp advances under a weighted policy combining the three channels: a release's weighted points are the binary-pack build count at half weight plus the terminal-ISO and desktop-ISO build counts at full weight, with every five weighted points advancing the patch level, nine patches rolling into the next minor, and nine minors into the next major. A single 9.0.1-scheme license covers the entire 9.x.x series.

10. The Integrity, Signing, and Verification Chain#

The claim that a user can verify that the code they run is the code that was shipped rests on a concrete, end-to-end chain that spans the build host, the download server, and the running system.

10.1 Signing at build time#

Every Kodachi-authored binary is signed with an RSA-4096 key pair. The private key is held only by the maintainer and never ships; the public key ships everywhere. Each binary gets a detached OpenSSL signature (over a SHA-256 digest) plus a human-readable verification report (.sig.info) recording the SHA-256 hash, author, version, and timestamp. Twenty-eight release binaries are signed before packaging: the twenty-six Kodachi-authored binaries plus the two bundled third-party binaries. The ISO itself is signed with a detached signature by the same toolchain.

10.2 Verification at runtime and at download#

• Runtime self-verification. Dashboard-driven commands verify a binary's signature before executing it. If a binary is present but its .sig and .sig.info are missing or do not match, the service refuses to run with a tamper warning. Shipping a binary without its matching signature files is itself treated as tampering. Some services verify their own signature fatally on startup.
• Download verification. A remote user fetches the binary pack, the per-binary manifest (generated_hashes-v9.0.1.json for the baseline series, with later manifests generated by integrity-check generate during packaging), and the public key, then verifies the detached archive signature with OpenSSL and checks each binary against the manifest before installing. The release should ship the manifest, changelog, and version metadata together as an atomic set.

10.3 Two hash algorithms, two purposes#

Kodachi uses BLAKE3 for the per-binary integrity manifests produced by the integrity-check tool, including the published generated_hashes-v9.0.1.json, chosen for speed. SHA-256 is used only for the .sig.info reports and the digest over which the RSA signature is computed. BLAKE3 and SHA-256 both render as 64 hex characters, so the manifest superficially looks like SHA-256 but is not; running sha256sum against a file and comparing it to the manifest produces a guaranteed false "integrity mismatch." The correct verification uses b3sum (or the integrity-check tool itself) against the manifest, and OpenSSL over the SHA-256 digest against the signature. A separate plain SHA-256 sidecar of the distributed tarball is checked with sha256sum in the normal way.

Part II: The Server Infrastructure#

11. The VPS Fleet and Provisioning System#

Kodachi does not resell a third party's VPN; it runs its own elastic fleet, and that fleet is itself a hardened, scripted, reproducible system.

11.1 Topology and node roles#

There is always exactly one master node; the worker tier scales on demand, currently a master plus a handful of workers, with the production worker count deliberately not published as part of the contract. The worker nodes are treated as disposable infrastructure: beyond routine log wiping, the entire fleet is periodically torn down and rebuilt from clean images rather than maintained in place, so no routing node is long-lived and none carries state across rebuild cycles. The architecture defines four node roles.

All worker nodes run on DMCA-resistant hosting so the routing layer survives legal pressure that would shut down conventional providers. The nodes are connected to each other over a Tailscale mesh for management. Tiers map by hostname prefix: premium-tier hosts to the VIP card pool, free-tier to the normal pool, and dedicated-tier to the custom pool.

11.2 Provisioning: twenty-seven scripts in five phases#

A node is brought up by twenty-seven Bash scripts (around nineteen mandatory plus a set of optional ones) executed in five phases, configured from shared environment files (ports.env for central port allocation, server-config.env for node settings) and shared function libraries.

1. Foundation and hardening (vps-initial-setup.sh, csf_setup.sh, node-tuner.sh, dnscrypt_setup.sh, tailscale_setup.sh): BBR TCP congestion control, a one-million file-descriptor limit, a non-standard SSH port, fail2ban, AIDE, kernel sysctl hardening, unattended security upgrades, the ConfigServer firewall, the encrypted DNS resolver, and the Tailscale management mesh. The encrypted resolver and the mesh are foundational, all-node services auto-invoked by the initial setup script rather than VPN-tier services.
2. Web and PKI (apache-routine-setup-master.sh, apache-ipv6-setup.sh): Apache 2.4+, the Browscap browser-classification database, the PKI key store, IPv6 dual-stack, and the security headers and CSP for the web tier.
3. VPN services (openvpn-setup.sh, wireguard-setup.sh, tor_setup.sh): the encrypted tunnels and the Tor relay/bridge with redsocks and HAProxy.
4. Proxy services (shadowsocks_setup.sh, v2ray_setup.sh, xray_setup.sh, dante_setup.sh, hysteria2_setup.sh, mita_setup.sh): the obfuscation and SOCKS layers, each on its allocated port from ports.env.
5. Synchronization, cards, and health (lsyncd_setup.sh, card-generator.sh, vps-services-health-check.sh): card synchronization to the master, cron-driven card generation, and continuous service health monitoring.

Optional scripts cover DNS-API management (Porkbun), the Virtualmin control panel and its security hardening, Let's Encrypt automation, Netdata and ntopng monitoring, a dedicated DDoS detection and auto-ban script, and a DNSCrypt-plus-BIND integration.

11.3 The card lifecycle#

A "card" is a JSON document containing complete, ready-to-use configuration for every service on a node: OpenVPN and WireGuard configs with node-specific endpoints, Dante and Shadowsocks credentials, Xray, V2Ray, Hysteria2, Mita, and Tor service details, and DNS settings, alongside node metadata. The lifecycle is designed to minimize exposure:

1. A worker generates plain-JSON cards on a configurable cron cycle (a few times per hour). Each worker independently maintains a healthy per-node card buffer for its tier with a low-water refill policy and capacity-skip logic, so an exhausted pool is never force-allocated. Because the buffer is per node, the tier pool scales with the number of active workers rather than thinning as nodes are added.
2. Cards are pushed to the master by lsyncd, which watches the card directory with inotify (no polling) and synchronizes over SSH as a restricted syncuser on a non-standard port with key-only authentication.
3. On authentication, the master selects a card from the tier-appropriate pool (uniformly at random, under a global assignment lock so concurrent requests cannot double-allocate), encrypts it into an AES-256 ZIP keyed by the session token, delivers it over HTTPS, and deletes the card from the pool. Cards are single-use.
4. The client decrypts the card in memory using its session token and never persists the key.

A note on the encryption boundary: the AES-256 ZIP protects the card in transit and against casual exposure, and the single-use plus short-session-lifetime design keeps the exposure window small. Card assignment has been audited and confirmed uniform across nodes.

11.4 Apache and PKI#

The master's web tier is Apache 2.4+ with PHP, fronted by HAProxy. A PKI key store outside the web root holds the RSA-4096 keys used for field-level encryption (section 7.3), the live session and CSRF data, the license records and their audit chain, and the admin data. Any web deploy to the master must be followed by a post-upload routine that fixes ownership, rebuilds the access-control rules, and gracefully reloads Apache; skipping it produces 403 errors. Sensitive directories carry obfuscated names and restrictive permissions, and direct access to library and config PHP files is denied.

Part III: The Online Platform (kodachi.cloud)#

The public web platform is both a marketing and verification front end and the operational control plane for licensing and distribution. It runs on the master node's Apache and PHP stack, with private data held outside the web root.

12. The Public Verification Toolkit#

Kodachi publishes a suite of browser-accessible tools so that a user can independently verify their privacy posture rather than take the OS's word for it. These are the "online tools" the platform offers.

• Anonymity Verifier (the flagship "see what the web sees" tool). A live report that compares an ordinary connection against a Kodachi-protected one, surfacing IPv4/IPv6 exposure, WebRTC leaks, Tor routing status, proxy detection, and DNS-leak and session signals as real-time cards.
• IP Information Extractor. Pulls full IP intelligence, ASN, geolocation, reverse DNS, blacklist status, and datacenter or Tor-exit detection, from roughly seven primary providers with a cascade of plain-text fallbacks and cross-validation, with CGNAT detection and persistent caching. A companion plain endpoint returns the caller's IP in text, JSON, XML, YAML, CSV, or HTML for scripts, and an extractor tells a visitor whether their current IP belongs to the Kodachi network.
• DNS Leak Checker. A live leak test that detects rogue resolvers, transparent proxies, unencrypted lookups, and resolver fingerprints visible to remote sites.
• Browser Fingerprint. Analyzes canvas, fonts, WebGL, audio context, screen, plugins, timezone, language, and hardware attributes to show how identifiable a browser is, plus an SSL-certificate fingerprint endpoint for arbitrary domains.
• System Freshness Checker. Proves a running Kodachi install is current, untampered, and matches the signed release by combining UTC and local timestamps, a random selection of current world-news headlines from several major feeds, and the latest blockchain block height, the same triangulation an amnesic live system uses to prove it is not replaying a stale snapshot.
• DNS Propagation. Queries a domain across resolvers worldwide to spot DNS censorship, GeoDNS splits, poisoning, and propagation gaps in real time, with latency ranking, geographic distribution, consensus detection, and background processing with status polling for large queries.
• Domain Security Analyzer. Inspects a domain's full security posture, DNS records, MX/SPF/DMARC/DKIM mail configuration, TLS chain, security-header hygiene, blacklist status, and exposure footprint, with a risk score, persistent caching, and background processing.
• IP Queries Analytics. Aggregated, privacy-preserving analytics from the verifier: query volumes, top ASNs and countries, datacenter-versus-residential mix, and trend lines over time.
• File Hash Verify. Verifies any ISO or binary against Kodachi's signed release manifests, with BLAKE3 as the primary algorithm and SHA-256 as a fallback, so a user can confirm that what they downloaded is exactly what was shipped. This is the public, browser-based counterpart to the runtime self-verification and the offline download-verification chain described in section 10.
• System Status. A live operational-status dashboard for the verifier APIs, IP and DNS endpoints, mirrors, and update channels, with real-time uptime, response times, and incident notes. It uses an issue-first verdict banner, a needs-attention list, and a worst-first node matrix, probing services with real TCP connects where possible and send-only UDP probes where not, and it never exposes node IP addresses; by design it treats TCP/53 as blocked fleet-wide so DNS is reachable only through the encrypted tunnel.
• Verifier User Guide and API Docs. A step-by-step walkthrough of every verifier signal (what each check means, how it is computed, and how to fix anything flagged red), plus a REST API reference for programmatic access to the verifier and the IP/DNS intelligence, with endpoints, parameters, auth, rate limits, and example responses.

Supporting these are a Tor-exit detector, a tightly whitelisted and rate-limited CORS proxy (GET-only, restricted to Kodachi and partner domains), an aggregated security-news feed from around a dozen reputable sources, and a release-metadata manifest that drives the downloads page and the wiki changelog.

All of these are read-only verification surfaces. They share a multi-tiered caching strategy, CORS locked to Kodachi domains, and the same encryption discipline for any sensitive data they touch.

13. The Customer License Portal#

The customer-facing license portal is a self-service web application reached through an obfuscated, link-only directory (its URL is revealed on the post-purchase page and in the support FAQ rather than published broadly). It uses a key-based credential model with no accounts and no sign-up: the customer never creates a username, email login, or profile. The license key itself is the only credential, pasted directly (up to twenty keys at once), so a customer can check their license and nodes while remaining anonymous, the portal never asks who they are.

After validation, a customer sees a license dashboard: a tier banner ("you are in the Premium group, N nodes available"), a per-key info card (tier, price paid, purchase date, devices used and allowed, and an expiry gauge that shows days remaining or a version ceiling colored by urgency), with any sibling seats from a multi-key order shown prefix-masked. A "Your Nodes" panel lists the group-scoped VPN nodes with country and flag, IP, and a per-tier available-card count, plus per-node service up/down status loaded asynchronously after first paint. A transaction-history table shows one row per order, and a downloads section links to the installer and release notes. A release function lets a customer free all device activations for a key (with a type-to-confirm guard) so the license can be moved to another machine.

The portal mirrors the master's card-assignment routing exactly (the same license-group, custom-VPS, and pool mapping logic that get_card.php uses), so what a customer sees matches what they would actually be assigned. It is built for privacy and abuse-resistance: it never returns activation IPs, masks sibling keys, validates an HMAC checksum before any disk lookup (the real brute-force barrier), suppresses error output that could leak file paths, and enforces a shared per-IP lockout (ten failed lookups trigger a one-hour lock that covers both the info and status endpoints). Its theme matches the neon-green-on-black house style.

14. The Admin Command Center#

The administrative dashboard is a single-page application behind an obfuscated, access-controlled directory protected by HTTP Basic Auth plus per-admin TOTP two-factor authentication, with login tracking. It is the operational control plane for the whole licensing and fleet-routing system, backed by a dedicated set of internal API endpoints.

Its surfaces include: an overview of active licenses, users, sessions, and node health; full license-key management (generate in bulk with tier, device limit, and expiry basis; list with time-left gauges; modify, revoke, delete, reactivate, and transfer); user management (blocked, VIP, and custom lists, batch reassignment, and pool assignment); VPS and pool management (add, modify, remove, and status nodes, set per-node card limits, view card usage, and define the pool-to-hostname mappings that enforce tier isolation); payment configuration for both payment gateways (sandbox toggles, credentials, and price overrides); a version-rules engine (client-version allow and block ranges); an admin messaging system that can target all clients, a specific hardware key, or a client-version range (among other target types) and is delivered to clients through the license-status endpoint they poll after authentication; branded short-link management; and an audit log of admin actions and logins. The admin interface shares the neon-green-on-black house color of the rest of the platform and is distinguished from the customer portal by its layout and content rather than its palette; it carries its own CSP and no-index headers.

A standing operational rule governs the messaging system: because a broadcast target reaches every live user, testing is always done against a specific test hardware key, never a broadcast.

15. The Licensing and Payment Model#

Kodachi 9 uses an annual licensing model. Pricing is Premium at 99 USD per device per year (mapped to the VIP card pool) and Dedicated at 600 USD per device per year (mapped to the custom pool, sold by sales policy in quantities of roughly five to fifty devices, though the key generator itself permits any device count from one to ninety-nine); the free tier requires no license and uses the normal pool. A license key has the form of four random groups followed by a checksum group: the four random groups draw on a reduced alphabet that omits visually ambiguous characters, and the fifth group is a hexadecimal HMAC checksum derived from a server secret. Keys are stored as individually hashed JSON records in a private directory with an accompanying audit chain.

Annual keys are time-based: the key carries a 365-day validity that is stamped on first activation rather than at issuance, and the validity of a time-based key is governed by time rather than version, which lets one license cover the entire 9.x series and beyond. (A version-and-time key, by contrast, keeps a real version cap.) Activation runs through a defined sequence: rate-limit and format check, HMAC checksum before any disk lookup, hardware and company block checks, honeypot detection, status check, version-compatibility check, time-expiry check, and finally device-binding against the per-key device limit; a matching release endpoint frees a device binding so the license can be transferred. Payment flows through two gateways, and the key-minting paths for both, plus the admin-issued path, are kept in sync so they all issue the same annual key shape. Pricing is enforced consistently across the payment and admin paths so that issuance and billing cannot drift.

16. The Downloads Platform and Wiki#

Software distribution is in-house rather than delegated to a third-party host. The downloads page presents the three editions (Desktop ISO, Terminal ISO, and the binaries tarball) plus a Trends tab, all as accessible tabs. A dependency-free canvas chart renders download trends (daily, weekly, monthly, and yearly, with peak markers and tooltips) from a time-series endpoint, alongside by-country and by-OS breakdowns. Every download flows through a gating script that validates the file, tags it with geolocation (IP to country via a bounded cache with an API fallback) and OS (from the user agent), and atomically updates a persistent JSON catalog of counts, time series, and geo breakdowns. The actual ISO and binary files sit behind access-controlled directories that enforce the gate. The release metadata (the version manifest, the per-binary hash manifest, and the changelog) ships as an atomic three-file set, and the binary pack with its hash sidecars and public key lives under a dedicated downloads path.

A public MkDocs wiki documents the project: an overview and architecture, installation and per-edition guides, a binary-overview and per-binary CLI reference generated to JSON, a FAQ, a changelog rendered from the same release metadata with build-count charts, and a post-purchase landing page that reveals the customer portal link. The entire public platform follows one house theme (pure black, neon green, and the Orbitron typeface), with cache-busting version strings on assets so live changes take effect.

Cross-Cutting Concerns#

17. Emergency Response and Anti-Forensics#

This subsystem is what most distinguishes Kodachi from a conventional privacy bundle. It assumes things will go wrong and that the user needs a graduated, reversible, present-operator response.

17.1 The four-level response ladder#

17.2 Panic modes and the kill switch#

The three panic modes form a clear escalation. Soft blocks new connections but preserves the existing session, allowing immediate recovery. Medium kills all network, wipes browser data, and randomizes the MAC, requiring re-authentication to recover. Hard adds RAM wiping, encryption-key destruction, and a forced shutdown, requiring a cold boot from clean media. Independently, the kill switch has three explicit states (arm, activate, disarm), so the instant-disconnect capability can be staged ready without firing and stood down without consequence. Separating "arm" from "activate" is a usability-as-safety decision: the destructive capability is one deliberate step away, never one accidental click. The session helper binds these to anti-spoofed keyboard shortcuts (a configurable press-and-hold) so a present operator can trigger them without the GUI. For coercion scenarios, Kodachi also supports a LUKS "nuke" password that, when entered at the disk-unlock prompt instead of the real passphrase, destroys the LUKS key slots and renders the encrypted volume unrecoverable (a timestamped, separately-encrypted header backup is kept so the legitimate owner can restore deliberately), and a duress mode that presents a decoy screen rather than the real desktop.

17.3 Data-destruction standards#

Kodachi implements multiple overwrite methods matched to data sensitivity: a single zero pass for quick sanitization, configurable multi-pass random overwrites for general use (the shred-based tiers run one, three, or seven passes), the three-pass DoD 5220.22-M pattern (zeros, then ones, then random, with verification) for high-sensitivity data, and a simplified Gutmann-style multi-pass overwrite built in. The full thirty-five-pass classic Gutmann method is available through the optional nwipe integration rather than the built-in routine. RAM wiping defends against cold-boot attacks and can run automatically on shutdown; swap can be disabled or encrypted; browser data and logs can be securely deleted. Sensitivity levels map to defaults: session tokens get a single zero pass at session end, browser cache a random pass on medium panic, keys the DoD pattern on hard panic or logout, and full-drive multi-pass sanitization is always user-initiated and never automatic.

18. Security Analysis#

This section evaluates Kodachi against the threat model of section 2. The table is the scannable summary; the prose gives the reasoning and the residual risk for each adversary.

Against the local network observer, Kodachi removes the cheapest deanonymizers (a stable MAC and hostname), disables IPv6 to eliminate a whole leak class, and ensures DNS never crosses the local link in clear text. Direct routing makes the tunnel path preferred and is paired with leak checks plus health-control kill-switch response. Residual risk: local timing and volume analysis is not addressed.

Against the ISP or on-path observer, all traffic is in a tunnel with DNS bound to it, and the obfuscation protocols raise the cost of identifying the traffic. Residual risk: obfuscation is an arms race.

Against the censor, pluggable transports, bridges, Mieru, and an elastic takedown-resistant fleet give multiple independent paths through a filter. Residual risk: a censor who blocks the discovery and authentication endpoints can deny bootstrap; mitigations there are operational (fleet elasticity, domain rotation).

Against correlation, single-use session-bound cards, hardware-bound sessions, exit control with alliance exclusion, and circuit isolation reduce linkability. Residual risk: a global passive adversary remains out of scope.

Against opportunistic forensics, RAM wipe, swap encryption, browser and log wiping, standardized overwrite methods, and LUKS with a nuke password leave little recoverable residue. Residual risk: these assume an orderly shutdown or a present operator.

Against supply-chain tampering, the RSA-4096 signing chain, the BLAKE3 manifest, and runtime self-verification detect a modified binary before it runs and a tampered download before it installs. Residual risk: the model trusts key custody and the first public-key fetch.

Against software-level attackers, Rust memory safety, the hardened allocator, the no-panic discipline, command whitelisting, input filtering, dynamic path detection, zeroize, and constant-time comparisons close the common local-attack classes. Residual risk: the PHP server tier is a larger, more conventional attack surface, defended in depth (rate limiting, CSRF tokens, field-level encryption, input validation, HMAC-before-lookup, TOTP on the admin tier) but distinct from the Rust core.

The overall picture is a platform that is strong and honest at the layers it claims, with clearly stated boundaries at the layers it does not. Defense in depth means the failure of any single layer degrades gracefully rather than collapsing the whole.

19. Comparison with Related Work#

Tails is amnesic-by-default and routes everything through Tor, with an intentionally minimal and locked-down surface. Kodachi can also run amnesically from live media, so amnesia is not the dividing line. The real distinction is the anonymity model: Tails commits to one fixed Tor-only path, while Kodachi offers many transports beyond Tor (twelve routing protocols, an owned VPN fleet, bring-your-own configs) and a far larger operational surface for users who need to choose their anonymity tradeoff. The cost is a larger surface to use correctly; the benefit is adaptability to censored or Tor-hostile environments.

Whonix achieves strong anonymity through a two-VM split (a gateway that forces all traffic through Tor and a workstation that cannot learn its own IP), which is very robust against IP leaks. Kodachi takes a single-system, service-oriented approach: rather than isolating the network in a separate VM, it isolates capabilities into separate signed binaries and uses tunnel-preferred routing, continuous leak detection, and a health-control kill switch to enforce the no-leak property. Whonix's isolation is structurally stronger against accidental leaks; Kodachi's is lighter-weight, runs on bare metal as a live system, and integrates VPN and obfuscation that Whonix leaves to the user. Notably, Kodachi borrows hardening directly from the Whonix and Kicksecure lineage (tirdad, kloak, hardened_malloc).

Qubes OS pursues security by compartmentalization, isolating activities into separate virtualized domains. It is the strongest of the three against software compromise because a breach within one qube is contained to that qube's isolation domain, provided the Xen hypervisor and the GUI domain themselves remain uncompromised. Kodachi does not attempt VM-level compartmentalization; its threat model centers on network anonymity and forensic resistance rather than on containing arbitrary software compromise, and it explicitly cedes the "contain a root compromise" goal that Qubes is built to meet.

In short, Tails optimizes for amnesic Tor simplicity, Whonix for leak-proof Tor isolation, and Qubes for compromise containment, while Kodachi optimizes for operable, verifiable, multi-transport anonymity with graduated forensic resistance, backed by infrastructure it owns. Kodachi's most differentiating features (the owned takedown-resistant fleet with single-use session cards, the twelve-protocol obfuscation set, the end-to-end signing chain with runtime self-verification, the four-level graduated emergency ladder, and the public self-verification toolkit) are not the focus of any of the three.

20. Limitations and Known Gaps#

• Infrastructure trust. Although single-use session-bound cards and periodic full-fleet rebuilds minimize what any node retains, a user on the turnkey path still trusts the fleet for the VPN leg. Bring-your-own configs, the free Riseup and VPN Gate pools, the supported commercial providers (NordVPN, ProtonVPN, Mullvad, IVPN, PIA, and others), or Tor are the alternatives.
• Obfuscation is an arms race. No transport is permanently undetectable; Kodachi mitigates by shipping several and making switching cheap. Some combinations also have inherent edges: layering Tor over an XTLS-Reality transport breaks Tor's bootstrap because Reality inspects and rewrites the nested TLS, so the documented path for Tor-over-obfuscation is to use an obfs4 bridge instead.
• Out-of-scope adversaries. A global passive adversary, compromised hardware or firmware, a pre-boot rootkit, and a seized-while-unlocked machine are outside the envelope.
• Web-tier surface. The internet-facing PHP server tier is a more conventional attack surface than the memory-safe Rust core, and it is hardened accordingly (rate limiting, CSRF tokens, HMAC-before-lookup, field-level encryption, input validation, and TOTP on the admin tier).
• Key-custody single point. The signing model depends on the maintainer's private-key custody and on users obtaining the public key over a trustworthy channel.
• Built-in Gutmann is reduced. The native multi-pass overwrite is a simplified Gutmann variant; the full 35-pass method requires the optional nwipe integration.

21. Future Directions#

Signed-baseline anomaly detection. The host SOC monitor's detection is evolving toward a signed known-good baseline of autostart and file-integrity state, diffed against the live system, so the question shifts from "is this an expected artifact" to the stronger "has this changed since the system was known good."

Stat-gated BLAKE3 file-integrity monitoring. Continuous monitoring that uses cheap filesystem metadata as a gate, computing the BLAKE3 hash only when metadata changes, so integrity monitoring can run continuously without the cost of rehashing an unchanged filesystem.

Stronger handshake construction. Binding the handshake response to a client-held secret through an HMAC or signature construction, so the handshake itself proves possession of a credential rather than relying on the surrounding controls.

Expanded public documentation. Continuing to broaden the published operator and recovery documentation alongside the architecture material in this paper.

Evolving the transport set and the ARM edition. Treating the obfuscation transport set as something to keep extending as censorship evolves, and finishing the scaffolded ARM64 edition.

22. Conclusion#

Linux Kodachi is an argument that privacy is an engineering and operability problem as much as a cryptography problem, and that the argument must hold across an entire platform rather than a single binary. Its cryptography is sound and conventional (RSA-4096 signing, AES-256-GCM and ChaCha20-Poly1305, BLAKE3 and SHA-256 integrity, RSA-OAEP field encryption, hardware-bound challenge-response over cert-pinned TLS), and it deliberately avoids inventing its own primitives. The distinguishing contribution is the composition across three tiers: a hardened operating system of signed, single-purpose, JSON-emitting Rust services driven by one consistent dashboard; an owned, scripted, takedown-resistant server fleet that hands out single-use, session-encrypted configuration; and an online platform that lets anyone verify their own privacy posture, manage their license, and obtain software through a chain they can check.

The platform is honest about its boundaries. It does not claim to defeat a global passive adversary, to survive compromised hardware, or to contain an arbitrary software breach the way a compartmentalized OS does. Within the envelope it claims, network anonymity, leak prevention, verifiable integrity, and forensic resistance for a present operator, it is a defense-in-depth system whose layers fail gracefully and whose controls are designed to be used correctly under stress. That combination of depth, ownership, and operability across the whole stack is Kodachi's reason to exist.

Appendix A: Complete Component Inventory#

Rust service binaries (17 standalone)#

Sizes below are the deployed, stripped production binaries (/opt/kodachi/dashboard/hooks/). The unstripped development builds in the source tree are substantially larger; the strip = true release profile is what produces these shipped sizes.

Other Kodachi-authored binaries#

• kodachi-ai workspace: 8 binaries (ai-cmd, ai-trainer, ai-learner, ai-admin, ai-gateway, ai-discovery, ai-scheduler, ai-monitor) + 13 libraries; local-first NLP (ONNX Runtime + llama.cpp).
• kodachi-dashboard: the Tauri 2 + Svelte 5 desktop GUI (~25 MB).

Shared libraries#

• cli-core, auth-shared (and logs-hook, which is both a library-like dependency and a signed service binary).

Bundled third-party binaries (signed at release)#

• oniux (~25 MB, Tor Project, namespace isolation, tracks upstream v0.11.0).
• tun2socks (shipped as tun2socks-linux-amd64, ~10 MB; userspace tunnel for all proxy-class protocols).

Counts#

17 services + 8 AI binaries + 1 dashboard = 26 Kodachi-authored; + 2 third-party = 28 signed binaries.

Appendix B: Cryptographic Standards#

Appendix C: VPS Provisioning Scripts (by phase)#

Appendix D: Glossary#

• Card: a single-use JSON document containing complete VPN/proxy configuration for one node, delivered session-encrypted.
• Hook: a compiled Rust service binary in dashboard/hooks/, invoked by the dashboard; also, a numbered live-build script run during ISO assembly.
• Torrify: to route all system traffic through Tor via firewall rules (iptables or nftables).
• tun2socks: a userspace tunnel that presents a SOCKS-style proxy as a routable network interface, used to attach all proxy-class protocols.
• AutoShield: the first-boot guided hardening wizard, merged into the dashboard in 2026.
• SOC page: the dashboard's read-only Security Operations Center view, backed by kodachi-soc.
• Panic mode: a graduated emergency lockdown (soft, medium, hard).
• Card pool / tier: the VIP, normal, and custom pools mapped from the premium, free, and dedicated license tiers.
• Weighted-points versioning: the policy by which the three product channels advance their nightly build stamps independently of the 9.0.1 licensing baseline (binary pack at half weight plus terminal and desktop ISOs at full weight, five points per patch).

Appendix E: References#

URLs are provided for verification; access date 2026-06-28.

1. Aumasson, J-P., Neves, S., Wilcox-O'Hearn, Z., Winnerlein, C. "BLAKE3: one function, fast everywhere." https://github.com/BLAKE3-team/BLAKE3
2. U.S. Department of Defense. "National Industrial Security Program Operating Manual (NISPOM), DoD 5220.22-M." (Media sanitization overwrite standard.)
3. Gutmann, P. "Secure Deletion of Data from Magnetic and Solid-State Memory." 6th USENIX Security Symposium, 1996.
4. MITRE Corporation. "MITRE ATT&CK." https://attack.mitre.org
5. Dingledine, R., Mathewson, N., Syverson, P. "Tor: The Second-Generation Onion Router." 13th USENIX Security Symposium, 2004. https://www.torproject.org
6. The Tor Project. "oniux: Linux namespace isolation for routing applications through Tor." https://gitlab.torproject.org/tpo/core/oniux
7. Donenfeld, J. A. "WireGuard: Next Generation Kernel Network Tunnel." NDSS 2017. https://www.wireguard.com
8. OpenVPN Inc. https://openvpn.net
9. "Shadowsocks." https://shadowsocks.org
10. "Project X (Xray-core): VLESS, VMess, Trojan, REALITY." https://github.com/XTLS/Xray-core
11. "V2Ray / V2Fly." https://www.v2fly.org
12. "Hysteria2." https://v2.hysteria.network
13. "Mieru." https://github.com/enfein/mieru
14. "tun2socks." https://github.com/xjasonlyu/tun2socks
15. "DNSCrypt." https://dnscrypt.info
16. "Pi-hole." https://pi-hole.net
17. GrapheneOS. "hardened_malloc." https://github.com/GrapheneOS/hardened_malloc
18. Whonix / Kicksecure. "tirdad, kloak, system hardening." https://www.whonix.org
19. Microsoft. "ONNX Runtime." https://onnxruntime.ai
20. "llama.cpp (GGUF model format)." https://github.com/ggml-org/llama.cpp
21. The Tails Project. "Tails: The Amnesic Incognito Live System." https://tails.net
22. The Qubes OS Project / Rutkowska, J., Wojtczuk, R. "Qubes OS Architecture." 2010. https://www.qubes-os.org
23. Nakamoto, S. "Bitcoin: A Peer-to-Peer Electronic Cash System." 2008. (Referenced as a model of concise whitepaper structure.)
24. The Calamares Project. "Calamares: distribution-independent installer framework." https://calamares.io
25. ConfigServer. "CSF: ConfigServer Security & Firewall." https://configserver.com/cp/csf.html

This document describes the complete Kodachi platform as verified against the live repository and operational playbooks as of 2026-06-28. Port numbers, worker counts, and obfuscated directory names are operational details that change or are intentionally withheld; the architecture, security model, and verification chain are the stable contract.