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

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

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.

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 :

#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 utilise les valeurs par défaut Standard : autorité de certification système, DNS et proxy avec vérification TLS du pair et du nom d'hôte activée. WithCasualDefaults() reste disponible comme alias de compatibilité Standard.

Pour le trafic critique pour la sécurité, utilisez le profil Hardened. Build() rejette les contrôles manquants avant toute requête :

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) // repli explicite, après DoH
    .WithResponseVerifier(VerifySignedResponse)
    .Build();

Hardened exige la vérification du pair et du nom d'hôte, l'isolation de la pile, un routage DoH en premier, un vérificateur de réponse applicatif et un point de montage de confiance propriétaire de l'application. Les identifiants persistants WithMtls(...) sont rejetés ; utilisez WithMtlsProvider(...).

Chemins d'intégration

1. CMake standard

Utilisez cette approche lorsque votre projet en aval utilise déjà CMake et que vous souhaitez le chemin de gestion des dépendances le plus propre.

Documentation :

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

2. Ajout de sources dans Visual Studio

Utilisez cette approche lorsque votre environnement est basé sur MSBuild en priorité ou que vous souhaitez que BurnerNet soit compilé directement à l'intérieur de votre .vcxproj.

Documentation :

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

3. Importations d'exécution renforcées

Utilisez cette approche lorsque vous souhaitez réduire l'exposition évidente des dépendances d'exécution et que vous êtes prêt à gérer explicitement le chargement d'amorçage.

Activez :

• BURNERNET_HARDEN_IMPORTS=1
• Utilise le chemin KernelResolver de BurnerNet sur Windows pour prendre en charge une empreinte d'exécution plus légère en importations

Référence :

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

Support Linux : BurnerNet offre une parité forensique complète (effacement mémoire et isolation de la pile) sous Linux. Voir docs/LINUX_USAGE.md pour les instructions de construction.

Notes d'utilisation

Valeurs par défaut recommandées :

• traitez les clients comme des transports jetables
• séparez le trafic de haute confiance et de moindre confiance dans des clients différents
• utilisez des callbacks fournisseurs pour le matériel mTLS, les jetons porteurs et les secrets de vérification de réponse
• conservez les règles métier et les ancres de confiance dans votre application

Exemples et documentation

Exemples :

• 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

Documentation :

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

Prérequis

• C++20
• Windows x64/x86 ou Linux (GCC 13+ / Clang 15+)
• En-têtes libcurl 7.87.0+ et OpenSSL
• Guide Linux : Voir docs/LINUX_USAGE.md

Réalité sécuritaire – La défense boîte blanche

BurnerNet est une couche de renforcement conçue pour élever le coût d'une attaque à un niveau professionnel. Nous opérons sur le principe que la furtivité doit être architecturale, pas seulement superficielle.

Un attaquant peut-il contourner BurnerNet s'il dispose du code source ? La connaissance du code source de BurnerNet n'est pas, en soi, une clé maîtresse pour chaque application en aval. BurnerNet suit le principe de Kerckhoffs : la bibliothèque est conçue pour que vos ancres de confiance spécifiques à l'application (secrets HMAC, clés épinglées, logique d'interface utilisateur, hooks de stratégie) restent propriété de l'application. Connaître la couche de transport ne donne pas automatiquement un contournement universel de votre flux de sécurité spécifique.

• La furtivité comme moyen de retard : Le renforcement force les attaquants à sortir des outils de commodité standard et à entrer dans une analyse fastidieuse au niveau des instructions.
• Les données comme racine : Utilisez la dépendance fonctionnelle (principe 6) pour garantir que votre application est littéralement cassée sans les données fournies par le serveur.
• L'avantage du fantôme : Au moment où un attaquant trouve votre logique de requête, l'isolation de la pile et l'effacement mémoire ont déjà détruit les preuves forensiques dont il a besoin.