BurnerNet

Client HTTP anti-forense a fiducia zero. Elimina i segreti. Recide le tracce. CPR in un carro armato stealth. 👻

BurnerNet è un client HTTP anti-forense in C++20. Fornisce un'API fluida, simile a CPR, per applicazioni che non possono fidarsi completamente della macchina locale—cancellando fisicamente i segreti dalla RAM e recidendo le tracce di esecuzione per nascondere la tua logica da scanner e debugger.

Offre impostazioni predefinite familiari e compatibili con l'host per HTTP ordinario e un profilo Hardened esplicito per ambienti ostili. Entrambe le strade favoriscono client di breve durata; la fiducia avanzata rimane di proprietà dell'applicazione.

Cerchi di proteggere i payload scaricati da BurnerNet? Dai un'occhiata a RipStop Codec per il descrambling delle risorse in memoria.

Principi • Primi Passi • Percorsi di Integrazione • Realtà della Sicurezza

In Breve

Perché Usarlo

Usa BurnerNet quando un normale client HTTP è troppo fiducioso per il tuo ambiente.

Aiuta quando vuoi:

• mantenere i client di richiesta di breve durata invece di condividere un trasporto globale
• ridurre la dipendenza da DNS locale e altre impostazioni predefinite dell'host
• recuperare token, certificati e segreti di verifica solo quando necessario
• mantenere la logica di verifica delle risposte nel codice della tua applicazione
• ridurre stringhe in chiaro e metadati evidenti nelle build hardened

A Chi è Destinato

BurnerNet si adatta a progetti come:

• App desktop Windows con autenticazione, licenze o richieste di aggiornamento di alto valore
• codice embedded o iniettato in esecuzione su un host di cui non ti fidi completamente
• strumenti che vogliono controlli di trasporto più severi senza rinunciare a un'API C++ fluida

Stack Standard vs BurnerNet

Risultati Difensivi

• Architettura della Memoria Zero-Ghost: BurnerNet utilizza un Prefix-Size Scrubber personalizzato per agganciare i percorsi interni di allocazione della memoria di libcurl e dei flussi basati su OpenSSL. I buffer di trasporto sensibili vengono cancellati quando escono dalla durata gestita da BurnerNet. Questa igiene è verificata sia su Windows che su Linux nelle configurazioni controllate descritte nella documentazione.
• Swipe degli Stack Frame: Dopo ogni richiesta, la libreria pulisce proattivamente il proprio stack di thread (pulizia High-Water Mark). Questo è inteso per distruggere i frammenti di trasporto effimeri prima che il controllo ritorni alla tua applicazione.
• Heap a Bersaglio Mobile: La combinazione di trasporti usa e getta e intestazioni di metadati allineati crea un'elevata dispersione dello spazio degli indirizzi, rendendo la memoria del processo imprevedibile e resistente alla mappatura stabile dei puntatori.
• Stato della richiesta di breve durata: BurnerNet è progettato attorno a client usa e getta invece di trasporti singleton a livello di processo.
• Meno fiducia nell'host: Il supporto DoH, il supporto delle chiavi fissate e il controllo del trasporto aiutano a ridurre la dipendenza da impostazioni predefinite locali compromesse.
• Minore esposizione del testo in chiaro: I callback del provider e le utility di cancellazione sicura riducono la durata di certificati, chiavi, token e altri buffer sensibili.
• Verifica di proprietà dell'app: La verifica della risposta rimane nel tuo codice tramite WithResponseVerifier(...) invece di essere hardcodata in una libreria condivisa.
• Impronta statica più difficile: Le build hardened possono impostare BURNERNET_DIAGNOSTIC_STRINGS=0 in modo che ErrorCodeToString(...) restituisca valori E<numero> stabili senza incorporare nomi di errore simbolici.

Furtività Verificata

BurnerNet non si limita a dichiarare una modalità hardened con import leggeri; include anche note di audit per configurazioni specifiche testate. In un audit di Windows x64 Release con BURNERNET_HARDEN_IMPORTS=ON:

• Blackout IAT: Nessuna voce per libcurl.dll, ws2_32.dll, bcrypt.dll o crypt32.dll è stata osservata nel binario sottoposto ad audit.
• Dark-out della Memoria: Le scansioni forensi (Cheat Engine "All Strings") non sono riuscite a scoprire URL canary sensibili o intestazioni nell'heap o stack del processo.
• Cecità del Debugger: I test integrati verificano che la libreria attivi un "Identity Shift." Il Decision-Maker (la tua app) e il Transporter (BurnerNet) operano su ID thread distinti, riducendo la tracciabilità top-down durante sessioni di debug dal vivo.
• Rumore-Segnale: La libreria mira all'igiene forense all'interno della sua autorità di cancellazione, riconoscendo al contempo le "ombre" residue a livello di sistema nell'ambiente OS e runtime.

Dettagli e metodologia dell'audit:

• docs/BINARY_STEALTH_AUDIT.md

Primi Passi

Percorso più veloce:

• Aggiungi BurnerNet al tuo build con CMake o source-drop di Visual Studio.
• Includi <burner/net.h>.
• Crea un client stack, invia una richiesta, poi lascia che esca dallo scope.

Esempio minimale:

#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 utilizza le impostazioni predefinite Standard: CA di sistema, DNS e proxy con verifica del peer TLS e del nome host abilitata. WithCasualDefaults() rimane disponibile come alias di compatibilità Standard.

Per il traffico critico per la sicurezza, usa il profilo Hardened. Build() rifiuta i controlli mancanti prima di qualsiasi richiesta:

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 richiede verifica del peer e del nome host, isolamento dello stack, routing DoH-first, un verificatore di risposta dell'app e un mount di fiducia di proprietà dell'app. Le credenziali persistenti WithMtls(...) sono respinte; usa WithMtlsProvider(...).

Percorsi di Integrazione

1. Standard CMake

Usa questo quando il tuo progetto downstream utilizza già CMake e desideri il percorso più pulito con gestione delle dipendenze.

Docs:

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

2. Visual Studio Source-Drop

Usa questo quando il tuo ambiente è MSBuild-first o vuoi BurnerNet compilato direttamente all'interno del tuo .vcxproj.

Docs:

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

3. Hardened Runtime Imports

Usa questo quando vuoi ridurre l'esposizione delle dipendenze runtime e sei pronto a gestire esplicitamente il caricamento bootstrap.

Enable:

• BURNERNET_HARDEN_IMPORTS=1
• Utilizza il percorso KernelResolver di BurnerNet su Windows per supportare un footprint runtime più leggero

Reference:

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

Supporto Linux: BurnerNet fornisce piena parità forense (Memory Wiping & Stack Isolation) su Linux. Vedi docs/LINUX_USAGE.md per le istruzioni di build.

Note sull'Utilizzo

Impostazioni predefinite consigliate:

• tratta i client come trasporti usa e getta
• separa il traffico ad alta fiducia e a bassa fiducia in client diversi
• usa callback del provider per materiale mTLS, token bearer e segreti di verifica della risposta
• mantieni le regole aziendali e gli anchor di fiducia nella tua applicazione

Esempi e Documentazione

Esempi:

• 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

Documentazione:

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

Requisiti

• C++20
• Windows x64/x86 o Linux (GCC 13+ / Clang 15+)
• libcurl 7.87.0+ e header OpenSSL
• Guida Linux: Vedi docs/LINUX_USAGE.md

Realtà della Sicurezza e la Difesa White-Box

BurnerNet è un livello di rafforzamento progettato per alzare il costo dell'attacco a un livello professionale. Operiamo sul principio che la furtività dovrebbe essere architetturale, non solo superficiale.

Un attaccante può bypassare BurnerNet se ha il codice sorgente?

La conoscenza del codice sorgente di BurnerNet non è, di per sé, una chiave maestra per ogni applicazione downstream. BurnerNet segue il Principio di Kerckhoffs: la libreria è progettata in modo che i tuoi anchor di fiducia specifici dell'app (segreti HMAC, chiavi fissate, logica UI, hook delle policy) rimangano di proprietà dell'applicazione. Conoscere il livello di trasporto non produce automaticamente un bypass universale del tuo flusso di sicurezza specifico.

• Furtività come Ritardo: Il rafforzamento costringe gli attaccanti a uscire dagli strumenti di comodo standard e ad entrare in un'analisi noiosa a livello di istruzioni.
• Dati come Radice: Usa la Dipendenza Funzionale (Principio 6) per assicurarti che la tua app sia letteralmente rotta senza dati forniti dal server.
• Il Vantaggio del Fantasma: Nel momento in cui un attaccante trova la tua logica di richiesta, l'Isolamento dello Stack e la Cancellazione della Memoria hanno già distrutto le prove forensi di cui hanno bisogno.