BurnerNet

Client HTTP anti-forensique et zéro confiance. Efface les secrets. Coupe les traces. RCR dans un tank furtif. 👻

BurnerNet est un client HTTP anti-forensique en C++20. Il offre une API fluide de style CPR pour les applications qui ne peuvent pas faire entièrement confiance à la machine locale, en effaçant physiquement les secrets de la RAM et en supprimant les traces d'exécution pour dissimuler votre logique aux scanners et aux débogueurs.

Il propose des valeurs par défaut familières compatibles avec l'hôte pour le HTTP ordinaire et un profil Hardened explicite pour les environnements hostiles. Les deux chemins privilégient des clients à durée de vie courte ; la confiance avancée reste la propriété de l'application.

Vous cherchez à protéger les charges utiles téléchargées par BurnerNet ? Découvrez RipStop Codec pour le désembrouillage d'actifs en mémoire.

Principes • Pour commencer • Chemins d'intégration • Réalité sécuritaire – La défense boîte blanche

En un coup d'œil

Domaine	BurnerNet
Langage	C++20
Plateforme	Windows x64/x86 (Première classe), Linux (Vérifié)
Transport	HTTP(S) basé sur libcurl
Hygiène mémoire	Utilitaires de nettoyage sécurisé et allocateurs avec effacement
Hygiène forensique	Nettoyage automatique du tas/pile sur l'ensemble de l'état de transport géré par BurnerNet
Analyse dynamique	L'isolation de la pile d'appels peut rompre le lien entre le consommateur et le transport
Renforcement de la compilation	Suppression optionnelle des chaînes de diagnostic, littéraux obscurcis, métadonnées réduites du runtime C++ dans les versions renforcées
Renforcement à l'exécution	Prise en charge de DoH, secrets basés sur des fournisseurs et contrôles de confiance plus stricts
Intégration	CMake ou ajout de sources dans Visual Studio

Pourquoi l'utiliser

Utilisez BurnerNet lorsqu'un client HTTP normal est trop confiant pour votre environnement.

Il est utile quand vous voulez :

• garder les clients de requêtes à courte durée de vie plutôt que de partager un transport global
• réduire la dépendance au DNS local et autres valeurs par défaut de l'hôte
• récupérer les jetons, certificats et secrets de vérification uniquement en cas de besoin
• conserver la logique de vérification des réponses dans votre propre code applicatif
• réduire les chaînes en clair évidentes et les métadonnées dans les versions renforcées

À qui s'adresse-t-il

BurnerNet convient à des projets tels que :

• applications de bureau Windows avec des requêtes d'authentification, de licence ou de mise à jour à haute valeur
• code embarqué ou injecté s'exécutant sur un hôte auquel vous ne faites pas entièrement confiance
• outils qui souhaitent des contrôles de transport plus stricts sans renoncer à une API C++ fluide

Pile standard vs BurnerNet

Préoccupation	Pile HTTP typique	BurnerNet
Durée de vie du client	Souvent partagée et longue	Conçue pour des clients jetables et une portée en rafale
Valeurs sensibles	Les secrets restent souvent en mémoire plus longtemps que nécessaire	Les callbacks fournisseurs les récupèrent près de l'utilisation
DNS et confiance	Hérite généralement du résolveur local et des valeurs par défaut de l'hôte	Prend en charge des contrôles de confiance plus stricts, y compris le repli DoH et les clés épinglées
Vérification	Les contrôles d'intégrité spécifiques à l'application sont souvent ajoutés après coup	Construit pour fonctionner avec des hooks de vérification avant vol, transport et réponse

Résultats défensifs

• Architecture mémoire sans fantôme : BurnerNet utilise un nettoyeur à préfixe-taille personnalisé pour accrocher les chemins d'allocation mémoire interne de libcurl et des flux basés sur OpenSSL. Les tampons de transport sensibles sont effacés dès qu'ils quittent la durée de vie gérée par BurnerNet. Cette hygiène est vérifiée à la fois sur Windows et Linux dans les configurations auditées décrites dans la documentation.
• Balayage de la pile : Après chaque requête, la bibliothèque nettoie proactivement sa propre pile de threads (nettoyage à la marque de hautes eaux). Cela vise à détruire les fragments de transport éphémères avant que le contrôle ne revienne à votre application.
• Cible mouvante sur le tas : La combinaison de transports jetables et d'en-têtes de métadonnées alignés crée une dispersion élevée de l'espace d'adressage, rendant la mémoire du processus imprévisible et résistante au mappage stable de pointeurs.
• État de requête à courte durée de vie : BurnerNet est conçu autour de clients jetables plutôt que de transports singleton à l'échelle du processus.
• Moins de confiance dans l'hôte : La prise en charge de DoH, le support des clés épinglées et l'audit du transport aident à réduire la dépendance vis-à-vis des valeurs par défaut locales compromises.
• Exposition moindre au texte clair : Les callbacks fournisseurs et les utilitaires de nettoyage sécurisé réduisent la durée de vie des certificats, clés, jetons et autres tampons sensibles.
• Vérification propriétaire de l'application : La vérification des réponses reste dans votre code via WithResponseVerifier(...) au lieu d'être codée en dur dans une bibliothèque partagée.
• Empreinte statique plus difficile : Les versions renforcées peuvent définir BURNERNET_DIAGNOSTIC_STRINGS=0 afin que ErrorCodeToString(...) renvoie des valeurs stables E<numéro> sans intégrer de noms d'erreur symboliques.
• Options de déploiement à importations légères : BURNERNET_HARDEN_IMPORTS=1 peut résoudre les dépendances d'exécution dynamiquement au lieu de les annoncer directement dans la table d'importation, en utilisant le chemin KernelResolver de BurnerNet sur Windows.
• Isolation de la pile d'appels (délégation asynchrone) : Lorsqu'elle est activée via .WithStackIsolation(true), la bibliothèque exécute le cycle de vie du transport sur un thread de travail détaché. Cela peut physiquement rompre la pile d'appels de l'appelant et réduire le traçage descendant direct de la logique applicative.

Furtivité vérifiée

BurnerNet ne se contente pas de revendiquer un mode renforcé à importations légères ; il fournit également des notes d'audit pour des configurations testées spécifiques. Dans un audit Windows x64 Release avec BURNERNET_HARDEN_IMPORTS=ON :

• Blackout IAT : Aucune entrée pour libcurl.dll, ws2_32.dll, bcrypt.dll ou crypt32.dll n'a été observée dans le binaire audité.
• Obscurcissement mémoire : Les scans forensiques (Cheat Engine "All Strings") n'ont pas réussi à découvrir d'URL ou d'en-têtes sensibles (canary) dans le tas ou la pile du processus.
• Aveuglement du débogueur : Les tests intégrés vérifient que la bibliothèque déclenche un "changement d'identité". Le décideur (votre application) et le transporteur (BurnerNet) opèrent sur des identifiants de threads distincts, réduisant le traçage descendant lors de sessions de débogage en direct.
• Rapport signal/bruit : La bibliothèque vise une hygiène forensique dans son périmètre d'effacement, tout en reconnaissant les "ombres" résiduelles au niveau du système et de l'environnement d'exécution.

Détails et méthodologie de l'audit :

• docs/BINARY_STEALTH_AUDIT.md

Pour commencer

Chemin le plus rapide :

• Ajoutez BurnerNet à votre build avec CMake ou en ajoutant les sources dans Visual Studio.
• Incluez <burner/net.h>.
• Créez un client sur la pile, envoyez une requête, puis laissez-le sortir de la portée.

Exemple minimal :