wasmforge

WasmForge — compile des programmes Go et C# en exécutables natifs monobinaires, sandboxés par WASM, avec une sortie polymorphe.

Le versant C# est au final plus une preuve de concept qu'une implémentation. Le processus utilisé pour compiler le C# vers WASM est trop expérimental, ce qui signifie que WasmForge doit souvent réécrire une bonne partie du programme de toute façon pour le faire fonctionner. Au final, je me suis probablement trop enfoncé dans ce terrier de lapin sur cette capacité et j'aurais simplement dû recommander aux gens d'utiliser un LLM pour réécrire le code C# en code Go. C'est probablement moins pénible à gérer. Cela dit, le schéma général C# -> Wasm -> WasmForge fonctionne VRAIMENT et il casse effectivement un bon nombre de détections spécifiques au C#.

À ce propos — WasmForge est avant tout conçu pour faire face aux détections STATIQUES. Le processus de transpilation casse la plupart des détections, même pour l'analyse en mémoire, mais au final, si votre binaire contient des chaînes très évidentes comme mimikatz ou sliver, certains scans en mémoire à faible effort déclencheront une détection. L'obfuscation automatique des chaînes sera probablement ajoutée à l'avenir, car c'est une fonctionnalité assez facile à automatiser, mais pour une première passe, je ne voulais pas ajouter de complexité supplémentaire au pipeline de build afin de garder le débogage relativement simple.

Bien que des efforts aient été faits pour nettoyer/consolider le code source de ce dépôt, il reste encore assez désorganisé. Il y a plusieurs dossiers différents pour différents processus de test. Les tests unitaires de base se trouvent généralement dans examples/ et test/, tandis que certains des tests les plus complexes, destinés à être exécutés dans un environnement de lab complet, se trouvent dans testdata/. Il y a aussi un certain nombre d'outils réservés au développement et aux tests dans les dossiers scripts/ et internal/devtools. Ils ne seront nécessaires que si vous cherchez à mettre en place votre propre environnement de test pour poursuivre le développement. En général, tout développement par LLM d'un projet aussi complexe nécessite un grand nombre de cas de test très explicites pour guider la génération, sinon on aboutit à quelque chose qui ne fonctionne pas du tout. Le projet inclut ces bancs de test afin que toute personne curieuse puisse approfondir son propre développement d'outillage ou contribuer au projet.

Espérons que la communauté trouvera cet outillage relativement facile à utiliser et que nous continuerons à l'améliorer au fil du temps. Peut-être qu'un jour la compilation C# fonctionnera aussi bien que la compilation Go.

Démarrage rapide (projets Go)

Il y a trois façons d'obtenir wasmforge :

1. Binaire précompilé. Téléchargez une release depuis la page Releases — les builds Linux, macOS et Windows de la CLI sont attachés à chaque tag.

2. Image Docker. Pour les projets C# / .NET, l'image fournie embarque tous les prérequis (.NET 10 SDK, workload NativeAOT-LLVM, WASI SDK 24.0, wasm-ld, osslsigncode) préinstallés. Construisez-la une fois avec make docker-build et pilotez-la avec make docker-run — voir docs/CSHARP.md pour le workflow complet. C'est la voie recommandée pour le C#.

3. Compilation depuis les sources.

   root@kitploit:~

   make build
   

   make build régénère l'archive embarquée internal/build/build_assets.tar.gz puis compile la CLI. Si vous exécutez simplement go build -o wasmforge ./cmd/wasmforge, vous obtiendrez un binaire fonctionnel, mais les builds en mode distribution (lorsque la CLI s'exécute en dehors de cet arbre source) utiliseront une archive embarquée obsolète. Voir CONTRIBUTING.md pour l'explication complète.

Le répertoire examples/ contient des programmes Go exécutables que vous pouvez compiler immédiatement. Voir examples/README.md pour la liste complète.

Cibler Windows

Le pont d'API Win32 est activé automatiquement dès que GOOS=windows — vous n'avez plus besoin de passer --win32-apis dans le cas courant.

--ghost traefik remplace la distribution de symboles gopclntab embarquée pour ressembler au reverse proxy Traefik. Parmi les profils fournis, c'est celui qui produit le taux de détection VirusTotal le plus bas. Les autres profils et les instructions pour générer les vôtres se trouvent dans docs/GHOST-PROFILES.md.

Les cibles Windows sont signées automatiquement avec un certificat auto-signé par défaut. Utilisez --sign google.com pour usurper le certificat TLS d'un domaine, ou --no-sign pour désactiver entièrement la signature.

Cibler macOS

Aucun drapeau supplémentaire n'est requis. Le pont de frameworks macOS s'active automatiquement dès que GOOS=darwin. Voir docs/MACOS.md pour le pont de frameworks, le support purego/ObjC et les autres notes spécifiques à Apple.

Drapeaux optionnels

Compiler des projets C# / .NET

Les projets C# (fichiers .csproj) sont détectés automatiquement. WasmForge exécute l'intégralité du pipeline de migration, de patch et de compilation NativeAOT-WASI en une seule commande :

Pour le travail en C#, nous recommandons vivement l'environnement de build Docker. Il regroupe tous les prérequis (.NET 10 SDK, workload NativeAOT-LLVM, WASI SDK 24.0, wasm-ld) afin que vous n'ayez à en installer aucun sur l'hôte. Les instructions complètes se trouvent dans docs/CSHARP.md.

Résumé de la CLI

Fonctionnalités

WasmForge comble le fossé entre WASM et l'hôte sous-jacent afin que les programmes invités n'aient pas à le faire.

API de plateforme. TCP, UDP, DNS, HTTP, TLS et sockets brutes fonctionnent sans modification du code invité, sur Windows comme sur macOS. Sur Windows, WasmForge agit comme proxy pour toute la surface Win32 : registre, entrées/sorties fichier, processus, chargement de DLL et SyscallN avec jusqu'à 15 arguments. La traduction de pointeurs est automatique. Les chaînes de vtable COM sont répliquées afin que le CLR et les autres API fortement basées sur COM fonctionnent de bout en bout. Sur macOS, dlopen et dlsym atteignent n'importe quel framework (Security, CoreGraphics, IOKit, etc.), et ebitengine/purego ainsi que le runtime Objective-C fonctionnent directement.

.NET : hébergement et migration. Le CLR se charge via la chaîne standard (CoInitializeEx, CLRCreateInstance, Load_3, Invoke_3). AMSI est patché au démarrage afin que Assembly.Load(byte[]) ne bloque pas les outils connus. Un pipeline séparé NativeAOT-WASI prend les projets .NET Framework existants et produit des binaires Windows PE uniques, sans runtime .NET requis sur la cible.

Mémoire hôte et shellcode. Un proxy mémoire hôte adossé à VirtualAlloc est accessible depuis l'intérieur de l'invité. Cela rend possibles les chargeurs COFF/BOF et l'exécution de shellcode sans sortir du sandbox WASM.

Cession coopérative (yield). Les API Win32 bloquantes (Sleep, WaitForSingleObject, ReadFile, etc.) ne gèlent pas les goroutines WASM. L'hôte délègue l'appel à une goroutine d'arrière-plan et signale à l'invité de céder la main jusqu'à ce que le résultat soit prêt.

Sortie polymorphe. Chaque build produit un binaire structurellement unique. Les opcodes WASM sont permutés, les identifiants de section et les octets magiques sont randomisés, et chaque identifiant, import PE, chaîne VERSIONINFO, bloc de licence et nom de fichier source est nettoyé. Le fork wazero embarqué est réécrit pour correspondre au bytecode permuté. Le profilage fantôme réécrit les symboles gopclntab pour correspondre à de vrais binaires Go d'entreprise (Traefik, Caddy, Terraform). Les sorties Windows sont signées Authenticode par défaut, soit auto-signées, soit en usurpant le certificat TLS d'un domaine réel via osslsigncode.

Architecture

Le pipeline de build se déroule en six étapes.

1. Préparer le GOROOT patché. Créez des liens symboliques vers la stdlib de Go et patchez syscall/ et net/ pour la mise en réseau WASM. Mis en cache dans ~/.wasmforge/cache/.
2. Compiler Go vers WASM. Compilez avec GOOS=wasip1 GOARCH=wasm contre la stdlib patchée. Des auto-stubs couvrent les lacunes spécifiques aux plateformes. Des sysshims pour golang.org/x/sys et ebitengine/purego sont injectés lorsque ces imports sont présents.
3. Remapper WASM. Permutation des opcodes par build, permutation des identifiants de section, octets magiques personnalisés et substitution d'octets sur l'intégralité du payload.
4. Générer le binaire hôte. main.go polymorphe avec des identifiants randomisés, un fork wazero correspondant par build, des ressources PE intégrées et -trimpath.
5. Post-traitement PE (Windows uniquement). Enrichissement des imports, somme de contrôle PE et injection du payload en tant que section PE nommée.
6. Signature de code (optionnelle). Signature Authenticode via osslsigncode.

Validation dans le monde réel

WasmForge compile et exécute des projets Go tiers non modifiés, y compris ceux qui contiennent du code complexe spécifique à une plateforme.

Programmes .NET NativeAOT-WASI :

Voir docs/BUILDING-SLIVER.md pour un guide pas à pas de Sliver, et docs/CSHARP.md pour le pipeline C#.

Prérequis

WasmForge s'exécute sur des hôtes de build Linux, macOS ou Windows. Go 1.25 ou plus est requis.

Quelques fonctionnalités nécessitent une configuration supplémentaire. Les sockets brutes nécessitent CAP_NET_RAW ou root. Le pont Win32 nécessite une cible Windows avec --win32-apis (les autres cibles renvoient ENOSYS). Le pont de frameworks macOS nécessite une cible macOS et est détecté automatiquement via GOOS=darwin. La signature de code nécessite osslsigncode dans le PATH. Les projets C# nécessitent le SDK .NET 10, le workload NativeAOT-LLVM et le WASI SDK 24.0. Alternativement, l'image Docker fournie (décrite dans docs/CSHARP.md) est livrée avec tout cela préinstallé.

Le banc de test de parité (test/parity/) et les scripts de montage du lab sous scripts/lab-setup/ supposent en outre un domaine Active Directory mis en place avec Ludus exécutant GOAD (Game of Active Directory) — chaque valeur par défaut codée en dur sevenkingdoms.local / kingslanding / SEVENKINGDOMS-CA est une valeur par défaut de GOAD, remplaçable via les variables d'environnement WASMFORGE_PARITY_* (voir test/parity/internal/lab/lab.go). Voir docs/internals/PARITY-HARNESS.md et docs/internals/LAB-STABILITY.md pour la configuration complète du lab.

Documentation

Commencer ici

Aller plus loin

Références pour les mainteneurs

Licence

Sous licence Apache License, Version 2.0. Voir LICENSE et NOTICE pour plus de détails.

Copyright (c) 2025-2026 Praetorian Security, Inc.