garble

go install mvdan.cc/garble@latest # oder @master

Verschleiert Go-Code, indem die Go-Toolchain umschlossen wird. Erfordert Go 1.27 oder neuer.

garble build [build flags] [packages]

Das Tool unterstützt außerdem garble test, um Tests mit verschleiertem Code auszuführen, garble run, um einfache Programme zu verschleiern und auszuführen, garble reverse, um Text wie Stack-Traces zu de-verschleiern, und garble bug, um einen vorausgefüllten Fehlerbericht einzureichen. Führen Sie garble -h aus, um alle verfügbaren Befehle und Flags anzuzeigen.

Zweck

Erzeugt ein Binary, das genauso gut funktioniert wie ein regulärer Build, aber so wenig Informationen über den ursprünglichen Quellcode wie möglich enthält.

Das Tool ist darauf ausgelegt:

• Mit cmd/go gekoppelt zu sein, um Module und Build-Caching zu unterstützen
• Deterministisch und reproduzierbar zu sein, bei gleichem Ausgangsquellcode
• Umkehrbar zu sein, bei vorliegendem Originalquellcode, um Panic-Stack-Traces zu de-verschleiern

Mechanismus

Das Tool umschließt Aufrufe an den Go-Compiler und -Linker, um den Go-Build zu transformieren, um:

• Bezeichner und Paketpfade durch kurze Base64-Hashes zu ersetzen
• Positionsinformationen durch kurze Base64-gehashte Dateinamen zu ersetzen
• Alle Build-, Modul- und Debug-Informationen zu entfernen
• Literale zu verschleiern, wenn das Flag -literals angegeben wird
• Zusätzliche Informationen zu entfernen, wenn das Flag -tiny angegeben wird

Das Tool verschleiert alle unterstützten Pakete, die gebaut werden, einschließlich der Standard-Runtime. Die nicht unterstützten Pakete runtime/cgo und crypto/internal/fips140 sind ausgeschlossen. Die Runtime-Verschleierung folgt den von Go unterstützten GOOS/GOARCH-Zielen; Garble führt keine engere Architektur-Allowlist.

Beachten Sie, dass Befehle wie garble build die go-Version verwenden, die in Ihrem $PATH gefunden wird. Um andere Go-Versionen zu verwenden, können Sie GOTOOLCHAIN verwenden.

Anwendungsfälle

Eine häufige Frage ist, warum ein Code-Obfuscator für Go, eine kompilierte Sprache, benötigt wird. Go-Binaries enthalten eine überraschende Menge an Informationen über den ursprünglichen Quellcode; selbst wenn Debug-Informationen und Symboltabellen entfernt werden, bleiben viele Namen und Positionen um der Traces, Reflection und des Debuggings willen erhalten.

Einige Anwendungsfälle für Go erfordern die Weitergabe eines Go-Binaries an den Endbenutzer. Wenn der Quellcode für das Binary privat ist oder gekauft werden muss, kann seine Verschleierung helfen, Reverse Engineering zu erschweren.

Ein ähnlicher Anwendungsfall ist eine Go-Bibliothek, deren Quellcode privat oder gekauft ist. Da Go-Bibliotheken nicht in Binärform importiert werden können und Go-Plugins ihre Mängel haben, wird die Weitergabe von verschleiertem Quellcode zu einer Option. Siehe #369.

Verschleierung kann auch bei Aspekten helfen, die völlig unabhängig von Lizenzierung sind. Zum Beispiel kann das Flag -tiny Binaries um 15 % kleiner machen, ähnlich der üblichen Praxis in Android, um App-Größen zu reduzieren. Verschleierung hat auch einigen Open-Source-Entwicklern geholfen, Anti-Virus-Scans zu umgehen, die Go-Binaries fälschlicherweise als Malware behandeln.

Literal-Verschleierung

Die Verwendung des Flags -literals bewirkt, dass literale Ausdrücke wie Strings durch komplexere Ausdrücke ersetzt werden, die zur Laufzeit denselben Wert ergeben. String-Literale, die über -ldflags=-X injiziert werden, werden durch dieses Flag ebenfalls ersetzt. Diese Funktion ist optional, da sie je nach Eingabecode zu Verlangsamungen führen kann.

Literale, die in konstanten Ausdrücken verwendet werden, können nicht verschleiert werden, da sie zur Kompilierzeit aufgelöst werden. Dies umfasst beispielsweise alle Ausdrücke, die Teil einer const-Deklaration sind.

Beachten Sie, dass dieser Prozess mit genügend Aufwand umgekehrt werden kann; siehe #984.

Tiny-Modus

Mit dem Flag -tiny werden noch mehr Informationen aus dem Go-Binary entfernt. Positionsinformationen werden vollständig entfernt, anstatt verschleiert zu werden. Runtime-Code, der Panics, fatale Fehler und Trace-/Debug-Informationen ausgibt, wird entfernt. Viele Symbolnamen werden zur Link-Zeit auch aus Binary-Abschnitten weggelassen. Alles in allem kann dies Binaries um etwa 15 % kleiner machen.

Mit diesem Flag werden niemals Panics oder fatale Runtime-Fehler ausgegeben, aber sie können weiterhin intern mit recover wie gewohnt behandelt werden.

Beachten Sie, dass dieses Flag das Debuggen von Abstürzen erschweren kann, da ein Panic einfach das gesamte Programm beendet, ohne einen Stack-Trace auszugeben, und Quellcode- Positionen und viele Namen entfernt werden. Ebenso ist garble reverse in diesem Modus im Allgemeinen nicht nützlich.

Kontrollfluss-Verschleierung

Siehe: CONTROLFLOW.md

Geschwindigkeit

garble build sollte etwa doppelt so lange dauern wie go build, da es zwei Builds abschließen muss. Den ursprünglichen Build, um den Eingabecode laden und typisieren zu können, und dann den verschleierten Build.

Garble verschleiert jeweils ein Paket, analog dazu, wie Go jeweils ein Paket kompiliert. Dies ermöglicht es Garble, den Build-Cache von Go vollständig zu unterstützen; inkrementelle garble build-Aufrufe sollten nur geänderten Code neu bauen und neu verschleiern.

Beachten Sie, dass der erste Aufruf von garble build vergleichsweise langsam sein kann, da er jedes Paket zum ersten Mal verschleiern muss. Dies ist vergleichbar mit dem Leeren von GOCACHE mit go clean -cache und dem Ausführen eines go build von Grund auf.

Garble nutzt außerdem seinen eigenen Cache, um Arbeit wiederzuverwenden, ähnlich wie Go's GOCACHE. Er verwendet standardmäßig ein Verzeichnis unter dem Cache-Verzeichnis Ihres Benutzers, wie ~/.cache/garble, und kann durch Setzen von GARBLE_CACHE an einen anderen Ort gelegt werden.

Determinismus und Seeds

Genau wie Go sind Garble-Builds von Natur aus deterministisch und reproduzierbar. Dies hat erhebliche Vorteile, wie das Cachen von Builds und die Möglichkeit, garble reverse zum De-Verschleiern von Stack-Traces zu verwenden.

Standardmäßig verschleiert Garble jedes Paket auf einzigartige Weise, was sich ändert, wenn sich seine Build-Eingabe ändert: die Version von Garble, die Version von Go, der Quellcode des Pakets oder ein Build-Parameter wie GOOS oder -tags. Dies ist eine vernünftige Standardeinstellung, da das Erraten dieser Eingaben sehr schwierig ist.

Sie können das Flag -seed verwenden, um Ihren eigenen Zufalls-Seed für die Verschleierung anzugeben. Die Wiederverwendung desselben Seeds kann helfen, dieselbe Code-Verschleierung zu erzeugen, was beim Debuggen oder Reproduzieren von Problemen hilfreich sein kann. Ein regelmäßiges Rotieren des Seeds kann auf lange Sicht auch gegen Reverse Engineering helfen, da man sonst Änderungen in der Art und Weise betrachten könnte, wie Go's Standardbibliothek verschleiert wird, um zu erraten, wann die Go- oder Garble-Versionen über eine Reihe von Builds hinweg geändert wurden.

Um für jeden Build immer einen anderen Seed zu verwenden, verwenden Sie -seed=random. Beachten Sie, dass bei benutzerdefinierten Seeds besondere Vorsicht geboten ist: Wenn ein in einem Build verwendeter -seed-Wert verloren geht, funktioniert garble reverse nicht.

Einschränkungen