WasmForge — kompiliert Go- und C#-Programme zu Single-Binary, WASM-sandboxierten nativen ausführbaren Dateien mit polymorpher Ausgabe.
WasmForge kompiliert Go- und C#-Programme zu WebAssembly und verpackt sie dann als einzelne native Binärdateien. Die resultierenden ausführbaren Dateien sandboxen den Gastcode in einer WASM-Laufzeitumgebung (einem pro Build erstellten Fork von wazero). Innerhalb dieser Sandbox erhalten Gäste transparenten Zugriff auf Netzwerk, Raw-Sockets, Win32-APIs und macOS-Framework-APIs.
Sie können normales Go mit net.Dial, net.Listen oder net/http schreiben. Sie können auch ein bestehendes .NET Framework C#-Projekt migrieren. In beiden Fällen ist die Ausgabe eine einzelne Binärdatei, die unter Windows oder macOS läuft, ohne dass der Benutzer Änderungen am Gastquellcode vornehmen muss.

Ein kurzer Blick auf dieses Projekt macht ziemlich deutlich, dass es mit starker Nutzung von LLMs entwickelt wurde. Ein Teil der Dokumentation wurde ebenfalls so erstellt – dieser Abschnitt jedoch nicht. Ich habe mein Bestes getan, um dieses README von unnötigem Ballast zu befreien und den Prozess zur tatsächlichen Nutzung von WasmForge so unkompliziert wie möglich zu gestalten. Außerdem, während die LLMs eine Dokumentation schreiben, die ihre eigenen Leistungen stark lobt, werden die Einschränkungen nicht ganz so klar gemacht.
Um die Erwartungen richtig zu setzen: Obwohl dies mit vielen verschiedenen Funktionen für Go getestet wurde, ist es KEINE vollständige Lösung für alle Go-Programme. Es gibt immer noch einen gesunden Prozentsatz der Win32-API, die nicht ordnungsgemäß unterstützt wird (wie APIs, die Callback-Thunks erfordern). Sliver funktioniert beispielsweise für eine gesunde Anzahl von Befehlen, ist aber KEINE vollständige 1:1-Portierung mit allen Funktionen. ls zeigt zum Beispiel immer noch Pfade mit / anstelle des traditionellen C:\-Pfads, da der WASM-Blob nicht vollständig davon überzeugt ist, dass er sich in Windows befindet. Es gibt andere Fähigkeiten, die einfach einen Absturz auslösen. Stellen Sie sicher, dass Sie alle Funktionen testen, die Sie verwenden möchten, bevor Sie versuchen, sie auf einem echten Ziel einzusetzen. Wenn etwas nicht funktioniert, versuchen Sie, das einfachste Beispiel der API zu erstellen, das defekt ist, und eröffnen Sie ein Issue / reichen Sie einen PR ein.
Die C#-Seite ist letztlich mehr Proof-of-Concept als Implementierung. Der Prozess, der zum Kompilieren von C# zu WASM verwendet wird, ist einfach zu experimentell, und das bedeutet, dass WasmForge oft einen gesunden Teil des Programms neu schreiben muss, damit es läuft. Letztendlich habe ich mich wahrscheinlich zu sehr in dieses Kaninchenloch verloren und hätte einfach empfehlen sollen, dass Leute ein LLM verwenden, um C#-Code in Go-Code umzuschreiben. Das ist wahrscheinlich weniger schmerzhaft zu handhaben. Das gesagt, das allgemeine Muster C# -> Wasm -> WasmForge FUNKTIONIERT und es bricht eine gesunde Anzahl von C#-spezifischen Erkennungen.
In diesem Zusammenhang: WasmForge ist in erster Linie für den Umgang mit STATISCHEN Erkennungen gedacht. Der Transpilationsprozess bricht die meisten Erkennungen, sogar für In-Memory-Scans, aber letztendlich, wenn Ihre Binärdatei einige sehr offensichtliche Zeichenfolgen wie mimikatz oder sliver enthält, gibt es einige In-Memory-Scans mit geringem Aufwand, die eine Erkennung verursachen. Automatische Zeichenfolgenverschleierung wird wahrscheinlich in Zukunft hinzugefügt, da es eine ziemlich einfache Funktion zur Automatisierung ist, aber für den ersten Durchlauf wollte ich keine zusätzliche Komplexität zur Build-Pipeline hinzufügen, um das Debuggen relativ einfach zu halten.
Obwohl es einige Bemühungen gab, den Quellcode in diesem Repository zu bereinigen/zu konsolidieren, ist er immer noch ziemlich unorganisiert. Es gibt mehrere verschiedene Ordner für verschiedene Testprozesse. Grundlegende Unit-Tests befinden sich normalerweise in examples/ und test/, während einige der komplexeren Tests, die in einer vollständigen Laborumgebung ausgeführt werden sollen, in testdata/ leben. Es gibt auch eine Reihe von Entwicklungs-/Test-only-Tools in den Ordnern scripts/ und internal/devtools. Diese sind nur notwendig, wenn Sie versuchen, Ihre eigene Testumgebung für die weitere Entwicklung einzurichten. Im Allgemeinen erfordert jede LLM-Entwicklung einer so komplexen Sache eine Reihe von sehr expliziten Testfällen, um die Generierung zu leiten, sonst erhalten Sie etwas, das überhaupt nicht funktioniert. Das Projekt enthält diese Testumgebungen, damit jeder Interessierte seine eigene Tool-Entwicklung vorantreiben oder zum Projekt beitragen kann.
Hoffentlich findet die Community dieses Tool relativ einfach zu bedienen, und im Laufe der Zeit werden wir es weiter verbessern. Vielleicht wird die C#-Kompilierung eines Tages genauso gut funktionieren wie die Go-Kompilierung.
Es gibt drei Möglichkeiten, wasmforge zu erhalten:
Vorgebaute Binärdatei. Holen Sie sich ein Release von der Releases-Seite — Linux-, macOS- und Windows-Builds der CLI sind jedem Tag beigefügt.
Docker-Image. Für C# / .NET-Projekte enthält das gebündelte Image alle
Voraussetzungen (.NET 10 SDK, NativeAOT-LLVM-Workload, WASI SDK 24.0,
wasm-ld, osslsigncode) vorinstalliert. Bauen Sie es einmal mit
make docker-build und steuern Sie es mit make docker-run — siehe
docs/CSHARP.md für den vollständigen Workflow. Dies ist der
empfohlene Weg für C#.
Aus dem Quellcode bauen.
make build
make build regeneriert das eingebettete internal/build/build_assets.tar.gz
und kompiliert dann die CLI. Wenn Sie nur go build -o wasmforge ./cmd/wasmforge ausführen, erhalten Sie eine funktionierende Binärdatei, aber
Distribution-Mode-Builds (wenn die CLI außerhalb dieses Quellbaums läuft)
verwenden ein veraltetes eingebettetes Archiv. Siehe CONTRIBUTING.md für die längere Erklärung.
Das Verzeichnis examples/ enthält ausführbare Go-Programme, die Sie sofort
bauen können. Siehe examples/README.md für die vollständige Übersicht.
GOOS=windows GOARCH=amd64 ./wasmforge build \
--ghost traefik \
-o myapp.exe \
/pfad/zu/ihrem/projekt
Die Win32-API-Brücke wird automatisch aktiviert, wenn GOOS=windows gesetzt ist – Sie müssen
--win32-apis für den Normalfall nicht mehr übergeben.
--ghost traefik tauscht die eingebettete gopclntab-Symbolverteilung aus, um wie der Traefik-Reverse-Proxy auszusehen. Von den gebündelten Profilen erzeugt dieses die niedrigste Erkennungsrate auf VirusTotal. Andere Profile und Anweisungen zum Erstellen eigener Profile finden Sie in docs/GHOST-PROFILES.md.
Windows-Ziele werden standardmäßig mit einem selbstsignierten Zertifikat signiert. Verwenden Sie --sign google.com, um das TLS-Zertifikat einer Domain zu fälschen, oder --no-sign, um die Signierung vollständig zu deaktivieren.
# Intel
GOOS=darwin GOARCH=amd64 ./wasmforge build -o myapp /pfad/zu/ihrem/projekt
# Apple Silicon
GOOS=darwin GOARCH=arm64 ./wasmforge build -o myapp /pfad/zu/ihrem/projekt
Keine zusätzlichen Flags erforderlich. Die macOS-Framework-Brücke wird automatisch aktiviert, wenn GOOS=darwin gesetzt ist. Siehe docs/MACOS.md für die Framework-Brücke, purego/ObjC-Unterstützung und andere Apple-spezifische Hinweise.