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

Bereich	BurnerNet
Sprache	C++20
Plattform	Windows x64/x86 (First-Class), Linux (Verifiziert)
Transport	`libcurl`-gestütztes HTTP(S)
Arbeitsspeicher-Hygiene	Sichere Löschhilfsprogramme und löschnde Allokatoren
Forensische Hygiene	Automatische Heap/Stack-Bereinigung über den von BurnerNet verwalteten Transportzustand
Dynamische Analyse	Call-Stack-Isolation kann die Verbindung zwischen Verbraucher und Transport trennen
Build-Härtung	Optionale Entfernung von Diagnose-Strings, obfuskierte Literale, reduzierte C++-Laufzeitmetadaten in gehärteten Builds
Laufzeithärtung	DoH-Unterstützung, anbieterbasierte Geheimnisse und strengere Vertrauenskontrollen
Integration	CMake oder Visual Studio Source-Drop

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

Aspekt	Typischer HTTP-Stack	BurnerNet
Client-Lebensdauer	Oft geteilt und langlebig	Ausgelegt für wegwerfbare Clients und Burst-Scope-Nutzung
Sensible Werte	Geheimnisse liegen oft länger als nötig in Konfiguration oder Speicher	Provider-Callbacks rufen sie nahe der Verwendung ab
DNS und Vertrauen	Erbt normalerweise lokalen Resolver und Host-Standards	Unterstützt strengere Vertrauenskontrollen inkl. DoH-Fallback und gepinnte Schlüssel
Verifikation	App-spezifische Integritätsprüfungen werden oft später hinzugefügt	Entwickelt, um mit Pre-Flight-, Transport- und Antwortverifikations-Hooks zu arbeiten

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;
    }

burner-net v1.3.0