Go build obfuscator.

Hritik Vijay 66bdc8b124 Use go install instead of garble install 2 days ago
.github 2a10dc7f41 minor tweaks in preparation for Go 1.21 2 months ago
docs 9612b29423 add generic function support for control flow obfuscation 2 months ago
internal afe1aad916 Removing obsolete TODO 2 months ago
scripts 47296634f1 Include actual count of files with `CRLF` endings found 3 months ago
testdata 23c8641855 propagate "uses reflection" through SSA stores 1 month ago
.gitattributes ab560ff007 start testing on GitHub Actions 3 years ago
.gitignore 12bc0349e6 make bincmp keep binaries around when it fails 10 months ago
AUTHORS 404b2ce128 ignore embedded fields used in reflection (#768) 3 months ago
CHANGELOG.md 8f7248939c CHANGELOG: add entry for v0.10.1 2 months ago
CONTRIBUTING.md 8e7765ee6f CONTRIBUTING: introduce -toolexec and add more dev tips 1 year ago
LICENSE 805c895d59 set up an AUTHORS file to attribute copyright 3 years ago
README.md 8fd5f10d1d add control flow obfuscation docs 2 months ago
bench_test.go 7d1bd13778 replace our caching inside GOCACHE with GARBLE_CACHE 3 months ago
cmdgo_quoted.go 598d5182fb update x/tools version used in go:generate 8 months ago
go.mod 3364c5c38f update deps prior to release 3 months ago
go.sum 0e2e483472 add control flow obfuscation 2 months ago
go_std_tables.go c26734c668 simplify our handling of "go list" errors 3 months ago
hash.go 0e2e483472 add control flow obfuscation 2 months ago
main.go 66bdc8b124 Use go install instead of garble install 2 days ago
main_test.go 6dd5c53a91 internal/linker: place files under GARBLE_CACHE 3 months ago
position.go 4f743b0861 move curPkg and origImporter out of the globals 3 months ago
reflect.go 23c8641855 propagate "uses reflection" through SSA stores 1 month ago
reverse.go 79376a15f9 support computing missing pkgCache entries 3 months ago
runtime_patch.go 0c9a59127a rename cache global to sharedCache 4 months ago
shared.go c26734c668 simplify our handling of "go list" errors 3 months ago



go install mvdan.cc/garble@latest

Obfuscate Go code by wrapping the Go toolchain. Requires Go 1.20 or later.

garble build [build flags] [packages]

The tool also supports garble test to run tests with obfuscated code, garble run to obfuscate and execute simple programs, and garble reverse to de-obfuscate text such as stack traces. Run garble -h to see all available commands and flags.

You can also use go install mvdan.cc/garble@master to install the latest development version.


Produce a binary that works as well as a regular build, but that has as little information about the original source code as possible.

The tool is designed to be:

  • Coupled with cmd/go, to support modules and build caching
  • Deterministic and reproducible, given the same initial source code
  • Reversible given the original source, to de-obfuscate panic stack traces


The tool wraps calls to the Go compiler and linker to transform the Go build, in order to:

  • Replace as many useful identifiers as possible with short base64 hashes
  • Replace package paths with short base64 hashes
  • Replace filenames and position information with short base64 hashes
  • Remove all build and module information
  • Strip debugging information and symbol tables via -ldflags="-w -s"
  • Obfuscate literals, if the -literals flag is given
  • Remove extra information, if the -tiny flag is given

By default, the tool obfuscates all the packages being built. You can manually specify which packages to obfuscate via GOGARBLE, a comma-separated list of glob patterns matching package path prefixes. This format is borrowed from GOPRIVATE; see go help private.

Note that commands like garble build will use the go version found in your $PATH. To use different versions of Go, you can install them and set up $PATH with them. For example, for Go 1.17.1:

$ go install golang.org/dl/go1.17.1@latest
$ go1.17.1 download
$ PATH=$(go1.17.1 env GOROOT)/bin:${PATH} garble build

Literal obfuscation

Using the -literals flag causes literal expressions such as strings to be replaced with more complex expressions, resolving to the same value at run-time. String literals injected via -ldflags=-X are also replaced by this flag. This feature is opt-in, as it can cause slow-downs depending on the input code.

Literals used in constant expressions cannot be obfuscated, since they are resolved at compile time. This includes any expressions part of a const declaration, for example.

Tiny mode

With the -tiny flag, even more information is stripped from the Go binary. Position information is removed entirely, rather than being obfuscated. Runtime code which prints panics, fatal errors, and trace/debug info is removed. Many symbol names are also omitted from binary sections at link time. All in all, this can make binaries about 15% smaller.

With this flag, no panics or fatal runtime errors will ever be printed, but they can still be handled internally with recover as normal. In addition, the GODEBUG environmental variable will be ignored.

Note that this flag can make debugging crashes harder, as a panic will simply exit the entire program without printing a stack trace, and source code positions and many names are removed. Similarly, garble reverse is generally not useful in this mode.

Control flow obfuscation



garble build should take about twice as long as go build, as it needs to complete two builds. The original build, to be able to load and type-check the input code, and then the obfuscated build.

Garble obfuscates one package at a time, mirroring how Go compiles one package at a time. This allows Garble to fully support Go's build cache; incremental garble build calls should only re-build and re-obfuscate modified code.

Note that the first call to garble build may be comparatively slow, as it has to obfuscate each package for the first time. This is akin to clearing GOCACHE with go clean -cache and running a go build from scratch.

Garble also makes use of its own cache to reuse work, akin to Go's GOCACHE. It defaults to a directory under your user's cache directory, such as ~/.cache/garble, and can be placed elsewhere by setting GARBLE_CACHE.

Determinism and seeds

Just like Go, garble builds are deterministic and reproducible in nature. This has significant benefits, such as caching builds and being able to use garble reverse to de-obfuscate stack traces.

By default, garble will obfuscate each package in a unique way, which will change if its build input changes: the version of garble, the version of Go, the package's source code, or any build parameter such as GOOS or -tags. This is a reasonable default since guessing those inputs is very hard.

You can use the -seed flag to provide your own obfuscation randomness seed. Reusing the same seed can help produce the same code obfuscation, which can help when debugging or reproducing problems. Regularly rotating the seed can also help against reverse-engineering in the long run, as otherwise one can look at changes in how Go's standard library is obfuscated to guess when the Go or garble versions were changed across a series of builds.

To always use a different seed for each build, use -seed=random. Note that extra care should be taken when using custom seeds: if a -seed value used in a build is lost, garble reverse will not work.


Most of these can improve with time and effort. The purpose of this section is to document the current shortcomings of this tool.

  • Exported methods are never obfuscated at the moment, since they could be required by interfaces. This area is a work in progress; see #3.

  • Garble aims to automatically detect which Go types are used with reflection, as obfuscating those types might break your program. Note that Garble obfuscates one package at a time, so if your reflection code inspects a type from an imported package, and your program broke, you may need to add a "hint" in the imported package:

    type Message struct {
       Command string
       Args    string
    // Never obfuscate the Message type.
    var _ = reflect.TypeOf(Message{})
  • Go plugins are not currently supported; see #87.

  • Garble requires git to patch the linker. That can be avoided once go-gitdiff supports non-strict patches.


We welcome new contributors. If you would like to contribute, see CONTRIBUTING.md as a starting point.