Plattformübergreifende Electron-GUI für das Sliver-C2-Framework, die Session- und Beacon-Dashboards, Payload-Generierung, Listener, Loot und Cloud-Deployment-Verwaltung bietet.
Sliver GUI ist eine plattformübergreifende Electron-Desktop-Anwendung für Sliver. Sie kombiniert Backend-Verbindungen, Live-Statusansichten, dedizierte Arbeitsbereiche und eine native Sliver-Konsole in einer React-Oberfläche, die mit HeroUI, HeroUI Pro und Font Awesome erstellt wurde.
Die GUI implementiert nicht jeden Upstream-Befehl oder jede Option. Operator- Verbindungen verwenden mTLS; WireGuard-Operator-Konfigurationen werden erkannt, können aber keine Verbindung herstellen. Siehe den Operator-Paritätsbericht für verfolgte Abdeckung und die folgenden Funktionsdokumente für spezifische Grenzen.
Die unterstützten Versionen und gesperrten Abhängigkeiten sind in package.json und package-lock.json aufgezeichnet. Der Anwendungscode verwendet striktes TypeScript; Build-Helfer verwenden Node.js-ES-Module.
npm ci --strict-allow-scripts
npx heroui-pro login
npx heroui-pro install --yes
npm run dev
Die HeroUI-Anmelde-/Installationsschritte sind für die erstmalige Workstation-Einrichtung erforderlich; sie
können übersprungen werden, wenn HEROUI_AUTH_TOKEN bereits für die Installation konfiguriert ist.
Halten Sie Anmeldedaten aus versionierten Dateien heraus.
npm run dev baut und startet die statische Anwendung unter
sliver://app/index.html und verwendet die Produktions-Content-Security-Policy.
Starten Sie den Befehl nach Quellcodeänderungen neu; dieser Workflow verwendet kein HMR.
Der TypeScript-Client wird aus dem gepinnten sliver-script-npm-Paket installiert.
Ein benachbarter Client-Checkout ist nicht erforderlich. Die gewöhnliche Anwendungsentwicklung
erfordert keinen Sliver-Quellcode-Checkout; das Erstellen der nativen Konsole hingegen schon.
Das Standard-Sliver-Client-Root ist ~/.sliver-client; SLIVER_CLIENT_ROOT_DIR
kann ein anderes Root auswählen. Anwendungseinstellungen, einschließlich Übersichtsgraph-
Optionen, werden in gui/application-settings.json gespeichert; der Arbeitsbereichs-Zoom wird in
gui/workspace-zoom.json gespeichert und Texteditor-Einstellungen in
gui/text-editor-settings.json unterhalb dieses Roots. Die GUI erkennt vorhandene
Operator-Konfigurationen in configs/ und aktualisiert den
geöffneten Selektor, wenn dort eine gültige Konfiguration gespeichert wird. Sie speichert Konfigurationen, die
über Import ausgewählt wurden, als private Dateireferenzen in gui/operator-configs.json.
Import und Forget kopieren oder löschen die Quellkonfigurationen nicht.
Ghostty-kompatible Terminalfarben werden in Einstellungen → Terminal konfiguriert und
in gui/ghostty/config gespeichert. Benutzerdefinierte Themes gehören in gui/ghostty/themes/;
installierte native Ghostty-Themes werden automatisch erkannt. Siehe
Terminaldarstellung und Ghostty-Themes für Konfigurations-
freigabe, den Monaco-Editor, Plattform-Transparenzunterstützung und Laufzeitgrenzen.
| Befehl | Zweck |
|---|---|
npm run typecheck | Überprüft die TypeScript-Projekte für Main/Preload und Renderer. |
npm test | Führt Vitest-Unit- und Komponententests aus. |
npm run test:watch | Führt Vitest interaktiv aus. |
npm run test:e2e:electron | Baut Electron und testet es über Renderer, Preload und IPC. |
npm run protocol:check | Überprüft den gepinnten Client, die Upstream-Baseline und Paritätsartefakte. |
npm run build | Typecheck und Build der Anwendungsausgabe in dist/. |
npm run build:console | Baut die gepinnte native Sliver-Konsole. |
npm run package | Erstellt eine entpackte Anwendung unter release/. |
npm run dist | Erstellt Plattform-Installer unter release/. |
npm run test:e2e:packaged | Überprüft und testet eine vorhandene entpackte Anwendung gegen ein lokales Fixture. |
Unit- und Komponententests befinden sich neben den Quelldateien; Electron-Szenarien befinden sich in
src/e2e/. Tests mit echtem Server sind separate, optionale Prüfungen, die konfigurierte
Wegwerf-Infrastruktur erfordern. Ein Fixture-Test belegt keine Kompatibilität mit Live-Servern oder
installierten Paketen.
Die Protokollprüfung verwendet Go und lädt den gepinnten Upstream-Quellcode in ein temporäres Verzeichnis. Siehe Protokolldokumentation für Herkunftsprüfungen und die Verwendung einer explizit ausgewählten lokalen Baseline.
Konsolen- und Distributions-Builds erfordern Go 1.27.1 und einen sauberen Sliver-Checkout
beim Commit und Tree, die in
Konsolen-Herkunft aufgezeichnet sind. Platzieren Sie ihn in
sliver/ oder setzen Sie SLIVER_SOURCE_DIR. Der Konsolen-Build validiert die Quelle;
er lädt diesen Checkout nicht herunter und ändert ihn nicht.
Der Build deaktiviert das automatische Umschalten der Go-Toolchain. Legen Sie die erforderliche Go-Binary
in PATH oder setzen Sie SLIVER_GO_BINARY auf ihren absoluten Pfad. Universelle macOS-Konsolen-
Builds erfordern macOS und /usr/bin/lipo.
npm run package und npm run dist bereiten die native Laufzeit, die Konsole und
das Lizenzinventar vor der Paketierung vor. Generierte Ausgaben unter dist/, release/,
native/sliver-console/ und .e2e-dist/ werden von Git ignoriert.
Die CI-Paketierungsmatrix ist:
| Plattform | Pakete | Automatische Updates |
|---|---|---|
| macOS universal | DMG und ZIP | Installierte App lädt das ZIP-Update herunter. |
| Windows x64 | NSIS-Installer und portable EXE | Nur NSIS-Installationen; portable Builds werden manuell aktualisiert. |
| Linux x64 | AppImage und DEB | Nur AppImage; DEB-Pakete werden manuell aktualisiert. |
Unterstützte Pakete sind so konfiguriert, dass sie GitHub Releases prüfen, Updates im Hintergrund herunterladen und bei Restart to update oder normalem Anwendungs- ende installieren. Stable-Builds akzeptieren keine Prerelease-Updates. Es ist kein GitHub-Token in die Anwendung eingebettet.