For each Go package we obfuscate, we need to store information about how we obfuscated it, which is needed when obfuscating its dependents. For example, if A depends on B to use the type B.Foo, A needs to know whether or not B.Foo was obfuscated; it depends on B's use of reflect. We record this information in a gob file, which is cached on disk. To avoid rolling our own custom cache, and since garble is so closely connected with cmd/go already, we piggybacked off of Go's GOCACHE. In particular, for each build cache entry per `go list`'s Export field, we would store a "garble" sibling file with that gob content. However, this was brittle for two reasons: 1) We were doing this without cmd/go's permission or knowledge. We were careful to use filename suffixes similar to Export files, meaning that `go clean` and other commands would treat them the same. However, this could confuse cmd/go at any point in the future. 2) cmd/go trims cache entries in GOCACHE regularly, to keep the size of the build and test caches under control. Right now, this means that every 24h, any file not accessed in the last five days is deleted. However, that trimming heuristic is done per-file. If the trimming removed Garble's sibling file but not the original Export file, this could cause errors such as "cannot load garble export file" which users already ran into. Instead, start using github.com/rogpeppe/go-internal/cache, an exported copy of cmd/go's own cache implementation for GOCACHE. Since we need an entirely separate directory, we introduce GARBLE_CACHE, defaulting to the "garble" directory inside the user's cache directory. For example, on Linux this would be ~/.cache/garble. Inside GARBLE_CACHE, our gob file cache will be under "build", which helps clarify that this cache is used when obfuscating Go builds, and allows placing other kinds of caches inside GARBLE_CACHE. For example, we already have a need for storing linker binaries, which for now still use their own caching mechanism. This commit does not make our cache properly resistant to removed files. The proof is that our seed.txtar testscript still fails the second case. However, we do rewrite all of our caching logic away from Export files, which in itself is a considerable refactor, and we add a few TODOs. One notable change is how we load gob files from dependencies when building the cache entry for the current package. We used to load the gob files from all packages in the Deps field. However, that is the list of all _transitive_ dependencies. Since these gob files are already flat, meaning they contain information about all of their transitive dependencies as well, we need only load the gob files from the direct dependencies, the Imports field. Performance is largely unchanged, since the behavior is similar. However, the change from Deps to Imports saves us some work, which can be seen in the reduced mallocs per obfuscated build. It's unclear why the binary size isn't stable. When reverting the Deps to Imports change, it then settles at 5.386Mi, which is almost exactly in between the two measurements below. I'm not sure why, but that metric appears to be slightly unstable. goos: linux goarch: amd64 pkg: mvdan.cc/garble cpu: AMD Ryzen 7 PRO 5850U with Radeon Graphics │ old │ new │ │ sec/op │ sec/op vs base │ Build-8 11.09 ± 1% 11.08 ± 1% ~ (p=0.796 n=10) │ old │ new │ │ bin-B │ bin-B vs base │ Build-8 5.390Mi ± 0% 5.382Mi ± 0% -0.14% (p=0.000 n=10) │ old │ new │ │ cached-sec/op │ cached-sec/op vs base │ Build-8 415.5m ± 4% 421.6m ± 1% ~ (p=0.190 n=10) │ old │ new │ │ mallocs/op │ mallocs/op vs base │ Build-8 35.43M ± 0% 34.05M ± 0% -3.89% (p=0.000 n=10) │ old │ new │ │ sys-sec/op │ sys-sec/op vs base │ Build-8 5.662 ± 1% 5.701 ± 2% ~ (p=0.280 n=10) |
1 year ago | |
---|---|---|
.github | 1 year ago | |
internal | 1 year ago | |
scripts | 1 year ago | |
testdata | 1 year ago | |
.gitattributes | 5 years ago | |
.gitignore | 2 years ago | |
AUTHORS | 2 years ago | |
CHANGELOG.md | 1 year ago | |
CONTRIBUTING.md | 2 years ago | |
LICENSE | 4 years ago | |
README.md | 1 year ago | |
bench_test.go | 1 year ago | |
cmdgo_quoted.go | 1 year ago | |
go.mod | 1 year ago | |
go.sum | 1 year ago | |
go_std_tables.go | 1 year ago | |
hash.go | 1 year ago | |
main.go | 1 year ago | |
main_test.go | 1 year ago | |
position.go | 2 years ago | |
reflect.go | 1 year ago | |
reverse.go | 1 year ago | |
runtime_patch.go | 1 year ago | |
shared.go | 1 year ago |
README.md
garble
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.
See garble -h
for up to date usage information.
Purpose
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
Mechanism
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.
Speed
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.
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.
Caveats
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.
Contributing
We welcome new contributors. If you would like to contribute, see CONTRIBUTING.md as a starting point.