d8de5a4306
We were using temporary filenames for modified Go and assembly files. For example, an obfuscated "encoding/json/encode.go" would end up as: /tmp/garble-shared123/encode.go.456.go where "123" and "456" are random numbers, usually longer. This was usually fine for two reasons: 1) We would add "/tmp/garble-shared123/" to -trimpath, so the temporary directory and its random number would be invisible. 2) We would add "//line" directives to the source files, replacing the filename with obfuscated versions excluding any random number. Unfortunately, this broke in multiple ways. Most notably, assembly files do not have any line directives, and it's not clear that there's any support for them. So the random number in their basename could end up in the binary, breaking reproducibility. Another issue is that the -trimpath addition described above was only done for cmd/compile, not cmd/asm, so assembly filenames included the randomized temporary directory. To fix the issues above, the same "encoding/json/encode.go" would now end up as: /tmp/garble-shared123/encoding/json/encode.go Such a path is still unique even though the "456" random number is gone, as import paths are unique within a single build. This fixes issues with the base name of each file, so we no longer rely on line directives as the only way to remove the second original random number. We still rely on -trimpath to get rid of the temporary directory in filenames. To fix its problem with assembly files, also amend the -trimpath flag when running the assembler tool. Finally, add a test that reproducible builds still work when a full rebuild is done. We choose goprivate.txt for such a test as its stdimporter package imports a number of std packages, including uses of assembly and cgo. For the time being, we don't use such a "full rebuild" reproducibility test in other test scripts, as this step is expensive, rebuilding many packages from scratch. This issue went unnoticed for over a year because such random numbers "123" and "456" were created when a package was obfuscated, and that only happened once per package version as long as the build cache was kept intact. When clearing the build cache, or forcing a rebuild with -a, one gets new random numbers, and thus a different binary resulting from the same build input. That's not something that most users would do regularly, and our tests did not cover that edge case either, until now. Fixes #328. |
5 years ago | |
|---|---|---|
| .github | 5 years ago | |
| internal | 5 years ago | |
| scripts | 5 years ago | |
| testdata | 5 years ago | |
| .gitattributes | 6 years ago | |
| .gitignore | 5 years ago | |
| AUTHORS | 5 years ago | |
| CHANGELOG.md | 5 years ago | |
| CONTRIBUTING.md | 5 years ago | |
| LICENSE | 5 years ago | |
| README.md | 5 years ago | |
| bench_test.go | 5 years ago | |
| go.mod | 5 years ago | |
| go.sum | 5 years ago | |
| hash.go | 5 years ago | |
| main.go | 5 years ago | |
| main_test.go | 5 years ago | |
| position.go | 5 years ago | |
| reverse.go | 5 years ago | |
| runtime_strip.go | 5 years ago | |
| shared.go | 5 years ago | |
README.md
garble
GO111MODULE=on go get mvdan.cc/garble
Obfuscate Go code by wrapping the Go toolchain. Requires Go 1.16 or later.
garble build [build flags] [packages]
The tool also supports garble test to run tests with obfuscated code,
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
- Remove all build and module information
- Strip filenames and shuffle position information
- Strip debugging information and symbol tables via
-ldflags="-w -s" - Obfuscate literals, if the
-literalsflag is given - Remove extra information, if the
-tinyflag is given
By default, the tool obfuscates the packages under the current module. If not
running in module mode, then only the main package is obfuscated. To specify
what packages to obfuscate, set GOPRIVATE, documented at 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.16.1:
$ go get golang.org/dl/go1.16.1
$ go1.16.1 download
$ PATH=$(go1.16.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 variants, resolving to the same value at run-time.
This feature is opt-in, as it can cause slow-downs depending on the input code.
Literal expressions used as constants cannot be obfuscated, since they are
resolved at compile time. This includes any expressions part of a const
declaration.
Tiny mode
When the -tiny flag is passed, extra information is stripped from the resulting
Go binary. This includes line numbers, filenames, and code in the runtime that
prints panics, fatal errors, and trace/debug info. All in all this can make binaries
2-5% smaller in our testing, as well as prevent extracting some more information.
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 all source code
positions are set to line 1. 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 finally the obfuscated build.
Go's build cache is fully supported; if a first garble build run is slow, a
second run should be significantly faster. This should offset the cost of the
double builds, as incremental builds in Go are fast.
Determinism and seeds
Just like Go, garble builds are deterministic and reproducible if the inputs
remain the same: the version of Go, the version of Garble, and the input code.
This has significant benefits, such as caching builds or being able to use
garble reverse to de-obfuscate stack traces.
However, it also means that an input package will be obfuscated in exactly the
same way if none of those inputs change. If you want two builds of your program
to be entirely different, you can use -seed to provide a new seed for the
entire build, which will cause a full rebuild.
If any open source packages are being obfuscated, providing a custom seed can also provide extra protection. It could be possible to guess the versions of Go and garble given how a public package was obfuscated without a seed.
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 and reflection. This area is a work in progress.
-
It can be hard for garble to know what types will be used with reflection, including JSON encoding or decoding. If your program breaks because a type's names are obfuscated when they should not be, you can add an explicit hint:
type Message struct { Command string Args string } // Never obfuscate the Message type. var _ = reflect.TypeOf(Message{}) -
Go plugins are not currently supported; see #87.
Contributing
We welcome new contributors. If you would like to contribute, see CONTRIBUTING.md as a starting point.