praetorian-inc/wasmforgeWasmForge — compile des programmes Go et C# en exécutables natifs monobinaires, sandboxés par WASM, avec une sortie polymorphe.
WasmForge compile des programmes Go et C# en WebAssembly, puis les empaquette sous forme de binaires natifs uniques. Les exécutables résultants font tourner le code invité en sandbox dans un runtime WASM (un fork par build de wazero). Depuis l'intérieur de ce sandbox, les invités bénéficient d'un accès transparent à la mise en réseau, aux sockets brutes, aux API Win32 et aux API des frameworks macOS.
Vous pouvez écrire du Go normal en utilisant net.Dial, net.Listen ou net/http. Vous pouvez également migrer un projet C# .NET Framework existant. Dans les deux cas, le résultat est un binaire unique qui s'exécute sur Windows ou macOS, sans que l'utilisateur ait à modifier le code source de l'invité.
Un coup d'œil rapide à ce projet suffit pour comprendre qu'il a été développé avec une utilisation MASSIVE de LLM. Une partie de la documentation aussi — mais pas cette section. J'ai fait de mon mieux pour déslopifier ce README tout en rendant le processus d'utilisation de WasmForge aussi simple que possible. Et bien que les LLM écrivent une documentation qui encense lourdement leurs propres réalisations, les limites ne sont pas rendues TOUT À FAIT aussi claires.
Pour bien fixer les attentes : même si cela a été testé avec de nombreuses fonctionnalités différentes pour Go, ce n'est PAS une solution complète pour tous les programmes Go. Il reste encore un bon pourcentage de l'API Win32 qui n'est pas correctement pris en charge (comme les API qui nécessitent des thunks de rappel). Sliver, par exemple, fonctionne pour un bon nombre de commandes, mais ce n'est PAS un port 1:1 complet en termes de fonctionnalités. ls, par exemple, affichera toujours des chemins avec des / au lieu du cheminement traditionnel C:\, car le blob WASM n'est pas complètement dupe et ne réalise pas qu'il est sous Windows. D'autres capacités déclencheront tout simplement un crash. Assurez-vous de tester toute fonctionnalité que vous souhaitez utiliser avant de l'employer sur une cible réelle. Si quelque chose ne fonctionne pas, essayez de construire l'exemple le plus basique de l'API qui est cassée et ouvrez une issue / soumettez une PR.
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.
Il y a trois façons d'obtenir wasmforge :
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.
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#.
Compilation depuis les sources.
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.
GOOS=windows GOARCH=amd64 ./wasmforge build \
--ghost traefik \
-o myapp.exe \
/path/to/your/project
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.
# Intel
GOOS=darwin GOARCH=amd64 ./wasmforge build -o myapp /path/to/your/project
# Apple Silicon
GOOS=darwin GOARCH=arm64 ./wasmforge build -o myapp /path/to/your/project
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.