wasmforge

WasmForge — Go および C# プログラムを、ポリモーフィックな出力を備えたシングルバイナリの WASM サンドボックス化ネイティブ実行ファイルにコンパイルします。

C# 側は、最終的には実装というよりも概念実証です。C# を WASM にコンパイルするプロセスはあまりにも実験的であり、そのため、WasmForge はプログラムを実行可能にするために、そのかなりの部分を書き換える必要がしばしば発生します。結局のところ、この機能に深入りしすぎたかもしれません。人々に LLM を使って C# コードを Go コードとして書き直すことを勧めるべきだったでしょう。おそらくそのほうが苦痛が少ないです。とはいえ、C# -> Wasm -> WasmForge という一般的なパターンは機能し、C# 固有の検出のかなりの数を回避できます。

その点について言えば、WasmForge は主に静的検出への対処を目的としています。トランスパイルプロセスは、インメモリスキャンであってもほとんどの検出を回避します。ただし、バイナリ内に mimikatz や sliver のような非常に明白な文字列が含まれている場合、労力の少ないインメモリスキャンで検出される可能性があります。文字列の自動難読化は、自動化が比較的容易な機能であるため、将来追加される可能性があります。ただし、最初のパスでは、デバッグを比較的簡単に保つためにビルドパイプラインに追加の複雑さを加えたくありませんでした。

このリポジトリのソースコードを整理・統合する努力は行われてきましたが、まだかなり整理されていません。テストプロセスごとに異なるフォルダがいくつかあります。基本的な単体テストは examples/ と test/ に置かれる傾向があり、本格的なラボ環境で実行することを意図したより複雑なテストは testdata/ に置かれています。また、scripts/ と internal/devtools フォルダには、開発/テスト専用のツールが多数あります。これらは、独自のテスト環境をセットアップしてさらなる開発を行おうとする場合にのみ必要です。一般に、このような複雑なものを LLM で開発するには、生成を導くための非常に明示的なテストケースが多数必要であり、そうでなければまったく動作しないものができあがります。このプロジェクトにはこれらのハーネスが含まれているため、興味のある人は誰でもツールの開発を進めたり、プロジェクトに貢献したりできます。

コミュニティがこのツールを比較的使いやすいと感じてくれれば幸いです。そして、時間をかけて改善を続けていきます。いつか C# のコンパイルが Go のコンパイルと同じくらい実際に機能するようになるかもしれません。

クイックスタート（Go プロジェクト）

wasmforge を入手する方法は 3 つあります。

1. プリビルドバイナリ。 Releases ページ から リリースを取得してください。Linux、macOS、Windows ビルドの CLI が各タグに添付されています。

2. Docker イメージ。 C# / .NET プロジェクト向けに、バンドルされたイメージには すべての前提条件（.NET 10 SDK、NativeAOT-LLVM ワークロード、WASI SDK 24.0、wasm-ld、 osslsigncode）がプリインストールされています。make docker-build で一度ビルドし、 make docker-run で実行してください。完全なワークフローについては docs/CSHARP.md を参照してください。これは C# に推奨される方法です。

3. ソースからビルド。

   root@kitploit:~

   make build
   

   make build は埋め込まれた internal/build/build_assets.tar.gz を再生成してから CLI をコンパイルします。単に go build -o wasmforge ./cmd/wasmforge を実行しただけでも動作するバイナリは得られますが、ディストリビューションモードのビルド （CLI がこのソースツリーの外で実行される場合）では古い埋め込みアーカイブが使用されます。 詳細な説明については CONTRIBUTING.md を参照してください。

examples/ ディレクトリには、すぐにビルドできる実行可能な Go プログラムがあります。完全な一覧は examples/README.md を参照してください。

Windows ターゲット

Win32 API ブリッジは GOOS=windows のときに自動的に有効になります。通常のケースでは --win32-apis を渡す必要はなくなりました。

--ghost traefik は、埋め込まれた gopclntab シンボル分布を Traefik リバースプロキシのように見えるように置き換えます。バンドルされているプロファイルの中で、これが最も低い VirusTotal 検出率を実現します。他のプロファイルと独自のプロファイルを生成する手順は docs/GHOST-PROFILES.md にあります。

Windows ターゲットはデフォルトで自己署名証明書によって自動署名されます。--sign google.com を使用してドメインの TLS 証明書を偽装するか、--no-sign を使用して署名を完全に無効にします。

macOS ターゲット

追加のフラグは必要ありません。macOS フレームワークブリッジは GOOS=darwin のときに自動的に有効になります。フレームワークブリッジ、purego/ObjC サポート、その他の Apple 固有の注意事項については docs/MACOS.md を参照してください。

オプションフラグ

C# / .NET プロジェクトのコンパイル

C# プロジェクト（.csproj ファイル）は自動検出されます。WasmForge は、NativeAOT-WASI の移行、パッチ、ビルドのパイプライン全体を 1 つのコマンドで実行します：

C# の作業には Docker ビルド環境を強くお勧めします。すべての前提条件（.NET 10 SDK、NativeAOT-LLVM ワークロード、WASI SDK 24.0、wasm-ld）がバンドルされているため、ホストにそれらをインストールする必要はありません。完全な手順は docs/CSHARP.md にあります。

CLI 概要

機能

WasmForge は WASM と基盤となるホストの間のギャップを埋めるため、ゲストプログラム側で対応する必要はありません。

プラットフォーム API。 TCP、UDP、DNS、HTTP、TLS、raw ソケットは、Windows と macOS の両方でゲストコードの変更なしに動作します。Windows では、WasmForge はレジストリ、ファイル I/O、プロセス、DLL ロード、最大 15 引数の SyscallN など、Win32 の全機能をプロキシします。ポインタ変換は自動です。COM vtable チェーンはミラーリングされるため、CLR やその他の COM を多用する API がエンドツーエンドで動作します。macOS では、dlopen と dlsym が任意のフレームワーク（Security、CoreGraphics、IOKit など）に到達でき、ebitengine/purego と Objective-C ランタイムがそのまま動作します。

.NET ホスティングと移行。 CLR は標準のチェーン（CoInitializeEx、CLRCreateInstance、Load_3、Invoke_3）を通じてロードされます。AMSI は起動時にパッチされるため、Assembly.Load(byte[]) が既知のツールをブロックしません。別の NativeAOT-WASI パイプラインは、既存の .NET Framework プロジェクトを取得し、ターゲットに .NET ランタイムを必要としない単一の Windows PE バイナリを生成します。

ホストメモリとシェルコード。 VirtualAlloc をバックエンドとするホストメモリプロキシは、ゲスト内部から到達可能です。これにより、WASM サンドボックスから脱出することなく、COFF/BOF ローダーとシェルコード実行が可能になります。

協調的ヨールド。 ブロッキング Win32 API（Sleep、WaitForSingleObject、ReadFile など）は WASM ゴルーチンをフリーズさせません。ホストはバックグラウンドのゴルーチンで呼び出しをディスパッチし、結果が準備できるまでゲストにヨールドを指示します。

ポリモーフィックな出力。 すべてのビルドは構造的に一意なバイナリを生成します。WASM オペコードは並べ替えられ、セクション ID とマジックバイトはランダム化され、すべての識別子、PE インポート、VERSIONINFO 文字列、ライセンスブロック、ソースファイル名がスクラブされます。バンドルされた wazero フォークは、並べ替えられたバイトコードに一致するように書き換えられます。ゴーストプロファイリングは、実際のエンタープライズ Go バイナリ（Traefik、Caddy、Terraform）に一致するように gopclntab シンボルを書き換えます。Windows の出力はデフォルトで Authenticode 署名され、自己署名または osslsigncode による実際のドメインの TLS 証明書の偽装のいずれかです。

アーキテクチャ

ビルドパイプラインは 6 つのステージで実行されます。

1. パッチ適用済み GOROOT の準備。 Go の標準ライブラリをシンボリックリンクし、WASM ネットワーキングのために syscall/ と net/ にパッチを適用します。~/.wasmforge/cache/ にキャッシュされます。
2. Go を WASM にコンパイル。 パッチ適用済みの標準ライブラリに対して GOOS=wasip1 GOARCH=wasm でビルドします。オートスタブがプラットフォーム固有のギャップをカバーします。golang.org/x/sys と ebitengine/purego の sysshim は、それらのインポートが存在するときに注入されます。
3. WASM のリマップ。 ビルドごとのオペコード並べ替え、セクション ID の並べ替え、カスタムマジックバイト、ペイロード全体のバイト置換。
4. ホストバイナリの生成。 ランダム化された識別子を持つポリモーフィックな main.go、ビルドごとに一致する wazero フォーク、組み込みの PE リソース、-trimpath。
5. PE 後処理（Windows のみ）。 インポートの拡充、PE チェックサム、名前付き PE セクションとしてのペイロード注入。
6. コード署名（オプション）。 osslsigncode による Authenticode 署名。

実環境での検証

WasmForge は、複雑なプラットフォーム固有コードを含む、未改変のサードパーティ Go プロジェクトをコンパイルして実行できます。

.NET NativeAOT-WASI プログラム：

ステップバイステップの Sliver チュートリアルについては docs/BUILDING-SLIVER.md を、C# パイプラインについては docs/CSHARP.md を参照してください。

要件

WasmForge は Linux、macOS、または Windows のビルドホストで動作します。Go 1.25 以降が必要です。

いくつかの機能には追加のセットアップが必要です。raw ソケットには CAP_NET_RAW または root 権限が必要です。Win32 ブリッジには --win32-apis を指定した Windows ターゲットが必要です（他のターゲットは ENOSYS を返します）。macOS フレームワークブリッジには macOS ターゲットが必要で、GOOS=darwin から自動検出されます。コード署名には PATH 上の osslsigncode が必要です。C# プロジェクトには、.NET 10 SDK、NativeAOT-LLVM ワークロード、WASI SDK 24.0 が必要です。あるいは、バンドルされた Docker イメージ（docs/CSHARP.md で説明）にはそれらがすべてプリインストールされています。

パリティテストハーネス（test/parity/）と scripts/lab-setup/ 配下のラボ構築スクリプトはさらに、Ludus で構築され GOAD (Game of Active Directory) を実行している Active Directory レンジがあることを前提としています。ハードコードされた sevenkingdoms.local / kingslanding / SEVENKINGDOMS-CA のデフォルトはすべて GOAD のデフォルトであり、WASMFORGE_PARITY_* 環境変数で上書きできます（test/parity/internal/lab/lab.go を参照）。完全なラボセットアップについては、docs/internals/PARITY-HARNESS.md と docs/internals/LAB-STABILITY.md を参照してください。

ドキュメント

ここから始める

さらに詳しく

メンテナー向けリファレンス

ライセンス

Apache License、Version 2.0 の下でライセンスされています。LICENSE と NOTICE を参照してください。

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