BurnerNet

Zero-trust, anti-forensic HTTP client. Wipes secrets. Severs traces. CPR in a Stealth Tank. 👻

BurnerNet is a C++20 anti-forensic HTTP client. It provides a fluent, CPR-like API for apps that cannot fully trust the local machine—physically wiping secrets from RAM and severing execution traces to hide your logic from scanners and debuggers.

It offers familiar host-compatible defaults for ordinary HTTP and an explicit Hardened profile for hostile environments. Both paths favor short-lived clients; advanced trust remains application-owned.

Looking to protect the payloads downloaded by BurnerNet? Check out RipStop Codec for in-memory asset descrambling.

Principles • Getting Started • Integration Paths • Security Reality

At a Glance

Why Use It

Use BurnerNet when a normal HTTP client is too trusting for your environment.

It helps when you want to:

• keep request clients short-lived instead of sharing one global transport
• reduce reliance on local DNS and other host defaults
• fetch tokens, certs, and verification secrets only when needed
• keep response verification logic in your own application code
• reduce obvious plaintext strings and metadata in hardened builds

Who It's For

BurnerNet fits projects such as:

• Windows desktop apps with high-value auth, licensing, or update requests
• embedded or injected code running in a host you do not fully trust
• tools that want stricter transport checks without giving up a fluent C++ API

Standard Stack vs BurnerNet

Defensive Outcomes

• Zero-Ghost Memory Architecture: BurnerNet uses a custom Prefix-Size Scrubber to hook the internal memory allocation paths of libcurl and OpenSSL-backed flows. Sensitive transport buffers are wiped as they leave BurnerNet-managed lifetime. This hygiene is verified on both Windows and Linux within the audited configurations described in the docs.
• Stack-Frame Swiping: After every request, the library proactively scrubs its own thread stack (High-Water Mark scrubbing). This is intended to destroy ephemeral transport fragments before control returns to your application.
• Moving-Target Heap: The combination of disposable transports and aligned metadata headers creates high address-space dispersion, making the process memory unpredictable and resistant to stable pointer-mapping.
• Short-lived request state: BurnerNet is designed around disposable clients instead of process-wide singleton transports.
• Less trust in the host: DoH support, pinned-key support, and transport auditing help reduce dependence on compromised local defaults.
• Lower plaintext exposure: Provider callbacks and secure wiping utilities reduce the lifetime of certs, keys, tokens, and other sensitive buffers.
• App-owned verification: Response verification stays in your code through WithResponseVerifier(...) instead of being hardcoded into a shared library.
• Harder static fingerprinting: hardened builds can set BURNERNET_DIAGNOSTIC_STRINGS=0 so ErrorCodeToString(...) returns stable E<number> values without embedding symbolic error names.
• Import-light deployment options: BURNERNET_HARDEN_IMPORTS=1 can resolve runtime dependencies dynamically instead of advertising them directly in the import table, using BurnerNet's KernelResolver path on Windows.
• Call Stack Isolation (Async Handoff): When enabled via .WithStackIsolation(true), the library executes the transport lifecycle on a detached worker thread. This can physically sever the caller's call stack and reduce direct top-down tracing of application logic.

Verified Stealth

BurnerNet does not just claim an import-light hardened mode; it also ships with audit notes for specific tested configurations. In a Windows x64 Release audit with BURNERNET_HARDEN_IMPORTS=ON:

• IAT Blackout: No entries for libcurl.dll, ws2_32.dll, bcrypt.dll, or crypt32.dll were observed in the audited binary.
• Memory Dark-out: Forensic scans (Cheat Engine "All Strings") failed to discover sensitive canary URLs or headers in the process heap or stack.
• Debugger Blindness: Integrated tests verify that the library triggers an "Identity Shift." The Decision-Maker (your app) and the Transporter (BurnerNet) operate on distinct Thread IDs, reducing top-down tracing during live debugging sessions.
• Noise-to-Signal: The library aims for forensic hygiene within its wipe authority, while acknowledging remaining system-level "shadows" in the OS and runtime environment.

Audit details and methodology:

• docs/BINARY_STEALTH_AUDIT.md

Getting Started

Fastest path:

• Add BurnerNet to your build with CMake or Visual Studio source-drop.
• Include <burner/net.h>.
• Create a stack client, send a request, then let it leave scope.

Minimal example:

#include <iostream>

#include <burner/net.h>

int main() {
    burner::net::Client client;
    if (!client.IsReady()) {
        std::cerr << burner::net::ErrorCodeToString(client.InitError()) << '\n';
        return 1;
    }

    const auto response = client
        .Get("https://example.com")
        .WithHeader("Accept", "text/html")
        .WithTimeoutSeconds(10)
        .Send();

    if (!response.TransportOk()) {
        std::cerr << burner::net::ErrorCodeToString(response.transport_error) << '\n';
        return 1;
    }

    std::cout << "HTTP " << response.status_code << '\n';
    return 0;
}

Client uses Standard defaults: system CA, DNS, and proxy with TLS peer and hostname verification enabled. WithCasualDefaults() remains available as a Standard compatibility alias.

For security-critical traffic, use the Hardened profile. Build() rejects missing controls before any request:

auto secure = burner::net::ClientBuilder(burner::net::ClientProfile::Hardened)
    .WithMtlsProvider(ProvideMtlsCredentials)
    .WithSecurityPolicy(AppSecurityPolicy{})
    .WithDnsFallback(burner::net::DnsMode::Doh,
                     "https://resolver.example/dns-query",
                     "Primary DoH")
    .AllowSystemDns(true) // explicit fallback, after DoH
    .WithResponseVerifier(VerifySignedResponse)
    .Build();

Hardened requires peer and hostname verification, stack isolation, DoH-first routing, an app response verifier, and an app-owned trust mount. Persistent WithMtls(...) credentials are rejected; use WithMtlsProvider(...).

Integration Paths

1. Standard CMake

Use this when your downstream project already uses CMake and you want the cleanest dependency-managed path.

Docs:

• docs/CMAKE_INTEGRATION.md
• examples/cmake-consumer/README.md

2. Visual Studio Source-Drop

Use this when your environment is MSBuild-first or you want BurnerNet compiled directly inside your .vcxproj.

Docs:

• docs/VISUAL_STUDIO_INTEGRATION.md
• examples/vs-consumer/README.md

3. Hardened Runtime Imports

Use this when you want to reduce obvious runtime dependency exposure and are prepared to manage bootstrap loading explicitly.

Enable:

• BURNERNET_HARDEN_IMPORTS=1
• Uses BurnerNet's KernelResolver path on Windows to support a more import-light runtime footprint

Reference:

• docs/USAGE_BEST_PRACTICES.md
• docs/CMAKE_INTEGRATION.md
• docs/VISUAL_STUDIO_INTEGRATION.md

Linux Support: BurnerNet provides full forensic parity (Memory Wiping & Stack Isolation) on Linux. See docs/LINUX_USAGE.md for build instructions.

Usage Notes

Recommended defaults:

• treat clients as disposable transports
• separate high-trust and lower-trust traffic into different clients
• use provider callbacks for mTLS material, bearer tokens, and response verification secrets
• keep business rules and trust anchors in your application

Examples and Docs

Examples:

• examples/01_basic_usage.cpp
• examples/02_zero_trust_pipeline.cpp
• examples/03_custom_security_policy.cpp
• examples/04_bootstrap_runtime.cpp
• examples/05_mtls_usage.cpp
• examples/06_hmac_custom_verifier.cpp

Documentation:

• PRINCIPLES.md
• docs/USAGE_BEST_PRACTICES.md
• docs/CMAKE_INTEGRATION.md
• docs/VISUAL_STUDIO_INTEGRATION.md
• docs/LINUX_USAGE.md

Requirements

• C++20
• Windows x64/x86 or Linux (GCC 13+ / Clang 15+)
• libcurl 7.87.0+ and OpenSSL headers
• Linux Guide: See docs/LINUX_USAGE.md

Security Reality & The White-Box Defense

BurnerNet is a hardening layer designed to raise the cost of attack to a professional level. We operate on the principle that stealth should be architectural, not just superficial.

Can an attacker bypass BurnerNet if they have the source code? Knowledge of BurnerNet's source code is not, by itself, a master key to every downstream application. BurnerNet follows Kerckhoffs's Principle: the library is designed so that your app-specific trust anchors (HMAC secrets, pinned keys, UI logic, policy hooks) remain application-owned. Knowing the transport layer does not automatically yield a universal bypass of your specific security flow.

• Stealth as a Delay: Hardening forces attackers out of standard convenience tools and into tedious instruction-level analysis.
• Data as the Root: Use Functional Dependency (Principle 6) to ensure your app is literally broken without server-provided data.
• The Ghost Advantage: By the time an attacker finds your request logic, the Stack Isolation and Memory Wiping have already destroyed the forensic evidence they need.