
burner-net v1.3.0
Client HTTP anti-forense a fiducia zero. Cancella segreti. Recide tracce. CPR in un carro armato stealth. 👻
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
| Area | BurnerNet |
|---|---|
| Linguaggio | C++20 |
| Piattaforma | Windows x64/x86 (Di Prima Classe), Linux (Verificato) |
| Trasporto | HTTP(S) basato su libcurl |
| Igiene della memoria | Utility di cancellazione sicura e allocatori di cancellazione |
| Igiene forense | Pulizia automatica di heap/stack nello stato di trasporto gestito da BurnerNet |
| Analisi dinamica | L'isolamento dello stack di chiamata può recidere il collegamento tra consumatore e trasporto |
| Rafforzamento del build | Rimozione opzionale delle stringhe diagnostiche, letterali offuscati, metadati runtime C++ ridotti nelle build hardened |
| Rafforzamento runtime | Supporto DoH, segreti basati su provider e controlli di fiducia più severi |
| Integrazione | CMake o source-drop di Visual Studio |
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
| Aspetto | Stack HTTP tipico | BurnerNet |
|---|---|---|
| Durata del client | Spesso condiviso e di lunga durata | Progettato per client usa e getta e uso a raffica |
| Valori sensibili | I segreti spesso rimangono nella configurazione o memoria più a lungo del necessario | I callback del provider li recuperano vicino all'uso |
| DNS e fiducia | Di solito eredita il resolver locale e le impostazioni predefinite dell'host | Supporta controlli di fiducia più severi, inclusi fallback DoH e chiavi fissate |
| Verifica | I controlli di integrità specifici dell'app sono spesso aggiunti dopo | Progettato per funzionare con hook di verifica pre-volo, trasporto e risposta |
Risultati Difensivi
- Architettura della Memoria Zero-Ghost: BurnerNet utilizza un Prefix-Size Scrubber personalizzato per agganciare i percorsi interni di allocazione della memoria di
libcurle 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=0in modo cheErrorCodeToString(...)restituisca valoriE<numero>stabili senza incorporare nomi di errore simbolici. - Opzioni di distribuzione con import leggeri:
BURNERNET_HARDEN_IMPORTS=1può risolvere le dipendenze runtime dinamicamente invece di pubblicizzarle direttamente nella tabella degli import, utilizzando il percorsoKernelResolverdi BurnerNet su Windows. - Isolamento dello Stack di Chiamata (Passaggio Asincrono): Quando abilitato tramite
.WithStackIsolation(true), la libreria esegue il ciclo di vita del trasporto su un thread di lavoro separato. Questo può recidere fisicamente lo stack di chiamate del chiamante e ridurre la tracciabilità diretta top-down della logica dell'applicazione.
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.dllocrypt32.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:
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();