BurnerNet

Zero-Trust, anti-forensischer HTTP-Client. Löscht Geheimnisse. Kappt Spuren. CPR in einem Stealth-Tank. 👻

BurnerNet ist ein C++20 anti-forensischer HTTP-Client. Es bietet eine fließende, CPR-ähnliche API für Anwendungen, die dem lokalen Rechner nicht vollständig vertrauen können – indem es Geheimnisse physisch aus dem RAM löscht und Ausführungsspuren kappt, um Ihre Logik vor Scannern und Debuggern zu verbergen.

Es bietet vertraute, host-kompatible Standardeinstellungen für gewöhnliches HTTP und ein explizites Hardened-Profil für feindliche Umgebungen. Beide Pfade bevorzugen kurzlebige Clients; fortgeschrittenes Vertrauen bleibt anwendungseigen.

Sie möchten die von BurnerNet heruntergeladenen Payloads schützen? Werfen Sie einen Blick auf RipStop Codec für das Entschlüsseln von Assets im Arbeitsspeicher.

Prinzipien • Erste Schritte • Integrationspfade • Sicherheitsrealität

Auf einen Blick

Warum es verwenden

Verwenden Sie BurnerNet, wenn ein normaler HTTP-Client für Ihre Umgebung zu vertrauensselig ist.

Es hilft, wenn Sie möchten:

• Anforderungs-Clients kurzlebig halten, anstatt einen globalen Transport zu teilen
• Abhängigkeit von lokalem DNS und anderen Host-Standards reduzieren
• Tokens, Zertifikate und Verifikationsgeheimnisse nur bei Bedarf abrufen
• Logik zur Antwortverifikation in Ihrem eigenen Anwendungscode belassen
• Offensichtliche Klartext-Strings und Metadaten in gehärteten Builds reduzieren

Für wen es gedacht ist

BurnerNet passt zu Projekten wie:

• Windows-Desktop-Apps mit hochwertigen Auth-, Lizenzierungs- oder Update-Anfragen
• Eingebetteter oder injizierter Code, der in einem nicht vollständig vertrauenswürdigen Host läuft
• Werkzeuge, die strengere Transportprüfungen wünschen, ohne auf eine fließende C++-API zu verzichten

Standard-Stack vs. BurnerNet

Defensive Ergebnisse

• Zero-Ghost-Memory-Architektur: BurnerNet verwendet einen benutzerdefinierten Prefix-Size-Scrubber, um die internen Speicherallokationspfade von libcurl und OpenSSL-gestützten Abläufen anzuhaken. Sensitive Transportpuffer werden gelöscht, wenn sie die von BurnerNet verwaltete Lebensdauer verlassen. Diese Hygiene wird sowohl unter Windows als auch unter Linux innerhalb der in der Dokumentation beschriebenen geprüften Konfigurationen verifiziert.
• Stack-Frame-Wischen: Nach jeder Anfrage löscht die Bibliothek proaktiv ihren eigenen Thread-Stack (High-Water-Mark-Scrubbing). Dies soll ephemere Transportfragmente zerstören, bevor die Kontrolle an Ihre Anwendung zurückgegeben wird.
• Moving-Target-Heap: Die Kombination aus wegwerfbaren Transports und ausgerichteten Metadaten-Headern erzeugt eine hohe Adressraum-Streuung, die den Prozessspeicher unvorhersehbar und resistent gegen stabile Zeigerzuordnungen macht.
• Kurzlebiger Anfragezustand: BurnerNet ist für wegwerfbare Clients ausgelegt, anstatt für prozessweite Singleton-Transports.
• Weniger Vertrauen in den Host: DoH-Unterstützung, Pinned-Key-Unterstützung und Transport-Überwachung helfen, die Abhängigkeit von kompromittierten lokalen Standards zu reduzieren.
• Geringere Klartext-Exposition: Provider-Callbacks und sichere Löschhilfsprogramme verringern die Lebensdauer von Zertifikaten, Schlüsseln, Tokens und anderen sensiblen Puffern.
• Anwendungseigene Verifikation: Antwortverifikation bleibt durch WithResponseVerifier(...) in Ihrem Code, anstatt in eine gemeinsam genutzte Bibliothek eingebettet zu sein.
• Schwereres statisches Fingerprinting: Gehärtete Builds können BURNERNET_DIAGNOSTIC_STRINGS=0 setzen, sodass ErrorCodeToString(...) stabile E<Nummer>-Werte zurückgibt, ohne symbolische Fehlernamen einzubetten.
• Import-arme Bereitstellungsoptionen: BURNERNET_HARDEN_IMPORTS=1 kann Laufzeitabhängigkeiten dynamisch auflösen, anstatt sie direkt in der Importtabelle zu bewerben, unter Verwendung von BurnerNets KernelResolver-Pfad unter Windows.
• Call-Stack-Isolation (Async Handoff): Wenn über .WithStackIsolation(true) aktiviert, führt die Bibliothek den Transportlebenszyklus auf einem getrennten Worker-Thread aus. Dies kann den Call-Stack des Aufrufers physisch trennen und die direkte Top-Down-Verfolgung der Anwendungslogik reduzieren.

Verifizierte Tarnung

BurnerNet behauptet nicht nur eine import-arme gehärtete Betriebsart; es liefert auch Prüfnotizen für spezifische getestete Konfigurationen. In einem Windows-x64-Release-Audit mit BURNERNET_HARDEN_IMPORTS=ON:

• IAT-Blackout: Im geprüften Binary wurden keine Einträge für libcurl.dll, ws2_32.dll, bcrypt.dll oder crypt32.dll beobachtet.
• Memory-Dark-out: Forensische Scans (Cheat Engine "All Strings") konnten keine sensiblen Canary-URLs oder Header im Prozess-Heap oder -Stack entdecken.
• Debugger-Blindheit: Integrierte Tests verifizieren, dass die Bibliothek einen "Identity Shift" auslöst. Der Entscheidungsträger (Ihre App) und der Transporteur (BurnerNet) arbeiten auf unterschiedlichen Thread-IDs, was die Top-Down-Verfolgung während Live-Debugging-Sitzungen reduziert.
• Noise-to-Signal: Die Bibliothek zielt auf forensische Hygiene innerhalb ihrer Löschbefugnis ab, unter Anerkennung verbleibender systemebener "Schatten" im Betriebssystem und der Laufzeitumgebung.

Details zur Prüfung und Methodik:

• docs/BINARY_STEALTH_AUDIT.md

Erste Schritte

Schnellster Weg:

• Fügen Sie BurnerNet zu Ihrem Build mit CMake oder Visual Studio Source-Drop hinzu.
• Binden Sie <burner/net.h> ein.
• Erstellen Sie einen Stack-Client, senden Sie eine Anfrage, und lassen Sie ihn dann den Gültigkeitsbereich verlassen.

Minimalbeispiel:

#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 verwendet die Standardeinstellungen: System-CA, DNS und Proxy mit aktivierter TLS-Peer- und Hostname-Verifikation. WithCasualDefaults() bleibt als Standard-Kompatibilitätsalias verfügbar.

Für sicherheitskritischen Verkehr verwenden Sie das Hardened-Profil. Build() lehnt fehlende Kontrollen vor jeder Anfrage ab:

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) // expliziter Fallback, nach DoH
    .WithResponseVerifier(VerifySignedResponse)
    .Build();

Hardened erfordert Peer- und Hostname-Verifikation, Stack-Isolation, DoH-first-Routing, einen App-Antwortverifizierer und einen app-eigenen Vertrauensanker. Persistente WithMtls(...)-Anmeldedaten werden abgelehnt; verwenden Sie WithMtlsProvider(...).

Integrationspfade

1. Standard-CMake

Verwenden Sie dies, wenn Ihr nachgelagertes Projekt bereits CMake verwendet und Sie den saubersten, dependency-verwalteten Pfad wünschen.

Dokumentation:

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

2. Visual Studio Source-Drop

Verwenden Sie dies, wenn Ihre Umgebung MSBuild-zentriert ist oder Sie BurnerNet direkt innerhalb Ihrer .vcxproj kompilieren möchten.

Dokumentation:

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

3. Gehärtete Laufzeitimporte

Verwenden Sie dies, wenn Sie die offensichtliche Exposition von Laufzeitabhängigkeiten reduzieren möchten und bereit sind, das Bootstrap-Laden explizit zu verwalten.

Aktivieren:

• BURNERNET_HARDEN_IMPORTS=1
• Verwendet BurnerNets KernelResolver-Pfad unter Windows für einen import-ärmeren Laufzeit-Fußabdruck

Referenz:

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

Linux-Unterstützung: BurnerNet bietet volle forensische Parität (Memory Wiping & Stack Isolation) unter Linux. Siehe docs/LINUX_USAGE.md für Build-Anleitungen.

Nutzungshinweise

Empfohlene Standardeinstellungen:

• Behandeln Sie Clients als wegwerfbare Transports
• Trennen Sie hochvertrauenswürdigen und niedrigvertrauenswürdigen Verkehr in verschiedene Clients
• Verwenden Sie Provider-Callbacks für mTLS-Material, Bearer-Tokens und Antwortverifikationsgeheimnisse
• Behalten Sie Geschäftsregeln und Vertrauensanker in Ihrer Anwendung

Beispiele und Dokus

Beispiele:

• 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

Dokumentation:

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

Voraussetzungen

• C++20
• Windows x64/x86 oder Linux (GCC 13+ / Clang 15+)
• libcurl 7.87.0+ und OpenSSL-Header
• Linux-Anleitung: Siehe docs/LINUX_USAGE.md

Sicherheitsrealität & die White-Box-Verteidigung

BurnerNet ist eine Härtungsschicht, die darauf ausgelegt ist, die Kosten eines Angriffs auf ein professionelles Niveau zu heben. Wir arbeiten nach dem Prinzip, dass Tarnung architektonisch und nicht nur oberflächlich sein sollte.

Kann ein Angreifer BurnerNet umgehen, wenn er den Quellcode hat? Die Kenntnis des BurnerNet-Quellcodes ist nicht automatisch ein Generalschlüssel für jede nachgelagerte Anwendung. BurnerNet folgt dem Kerckhoffs'schen Prinzip: Die Bibliothek ist so ausgelegt, dass Ihre app-spezifischen Vertrauensanker (HMAC-Geheimnisse, gepinnte Schlüssel, UI-Logik, Policy-Hooks) anwendungseigen bleiben. Die Kenntnis der Transportschicht liefert nicht automatisch eine universelle Umgehung Ihres spezifischen Sicherheitsablaufs.

• Tarnung als Verzögerung: Härtung zwingt Angreifer aus Standard-Komfortwerkzeugen in eine mühsame Anweisungs-für-Anweisungs-Analyse.
• Daten als Wurzel: Verwenden Sie Functional Dependency (Prinzip 6), um sicherzustellen, dass Ihre App buchstäblich ohne vom Server bereitgestellte Daten kaputt ist.
• Der Geistervorteil: Bis ein Angreifer Ihre Anforderungslogik findet, haben die Stack-Isolation und Memory-Wiping bereits die forensischen Beweise vernichtet, die sie benötigen.