Zero-Trust-Anti-Forensik-HTTP-Client. Löscht Geheimnisse. Trennt Spuren. CPR in einem Stealth-Tank. 👻
# 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](https://github.com/Krixx1337/ripstop-codec) für das Entschlüsseln von Assets im Arbeitsspeicher.
[Prinzipien](https://github.com/krixx1337/burner-net/blob/main/PRINCIPLES.md) • [Erste Schritte](#getting-started) • [Integrationspfade](#integration-paths) • [Sicherheitsrealität](#security-reality--the-white-box-defense)
## 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](https://github.com/krixx1337/burner-net/blob/main/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:
```cpp
#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:
```cpp
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](https://github.com/krixx1337/burner-net/blob/main/docs/CMAKE_INTEGRATION.md)
- [examples/cmake-consumer/README.md](https://github.com/krixx1337/burner-net/blob/main/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](https://github.com/krixx1337/burner-net/blob/main/docs/VISUAL_STUDIO_INTEGRATION.md)
- [examples/vs-consumer/README.md](https://github.com/krixx1337/burner-net/blob/main/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](https://github.com/krixx1337/burner-net/blob/main/docs/USAGE_BEST_PRACTICES.md)
- [docs/CMAKE_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/CMAKE_INTEGRATION.md)
- [docs/VISUAL_STUDIO_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/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](https://github.com/krixx1337/burner-net/blob/main/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](https://github.com/krixx1337/burner-net/blob/main/examples/01_basic_usage.cpp)
- [examples/02_zero_trust_pipeline.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/02_zero_trust_pipeline.cpp)
- [examples/03_custom_security_policy.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/03_custom_security_policy.cpp)
- [examples/04_bootstrap_runtime.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/04_bootstrap_runtime.cpp)
- [examples/05_mtls_usage.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/05_mtls_usage.cpp)
- [examples/06_hmac_custom_verifier.cpp](https://github.com/krixx1337/burner-net/blob/main/examples/06_hmac_custom_verifier.cpp)
Dokumentation:
- [PRINCIPLES.md](https://github.com/krixx1337/burner-net/blob/main/PRINCIPLES.md)
- [docs/USAGE_BEST_PRACTICES.md](https://github.com/krixx1337/burner-net/blob/main/docs/USAGE_BEST_PRACTICES.md)
- [docs/CMAKE_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/CMAKE_INTEGRATION.md)
- [docs/VISUAL_STUDIO_INTEGRATION.md](https://github.com/krixx1337/burner-net/blob/main/docs/VISUAL_STUDIO_INTEGRATION.md)
- [docs/LINUX_USAGE.md](https://github.com/krixx1337/burner-net/blob/main/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](https://github.com/krixx1337/burner-net/blob/main/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.