We used to rely on a parallel implementation of an object file parser and writer to be able to obfuscate import paths. After compiling each package, we would parse the object file, replace the import paths, and write the updated object file in-place. That worked well, in most cases. Unfortunately, it had some flaws: * Complexity. Even when most of the code is maintained in a separate module, the import_obfuscation.go file was still close to a thousand lines of code. * Go compatibility. The object file format changes between Go releases, so we were supporting Go 1.15, but not 1.16. Fixing the object file package to work with 1.16 would probably break 1.15 support. * Bugs. For example, we recently had to add a workaround for #224, since import paths containing dots after the domain would end up escaped. Another example is #190, which seems to be caused by the object file parser or writer corrupting the compiled code and causing segfaults in some rare edge cases. Instead, let's drop that method entirely, and force the compiler and linker to do the work for us. The steps necessary when compiling a package to obfuscate are: 1) Replace its "package foo" lines with the obfuscated package path. No need to separate the package path and name, since the obfuscated path does not contain slashes. 2) Replace the "-p pkg/foo" flag with the obfuscated path. 3) Replace the "import" spec lines with the obfuscated package paths, for those dependencies which were obfuscated. 4) Replace the "-importcfg [...]" file with a version that uses the obfuscated paths instead. The linker also needs that last step, since it also uses an importcfg file to find object files. There are three noteworthy drawbacks to this new method: 1) Since we no longer write object files, we can't use them to store data to be cached. As such, the -debugdir flag goes back to using the "-a" build flag to always rebuild all packages. On the plus side, that caching didn't work very well; see #176. 2) The package name "main" remains in all declarations under it, not just "func main", since we can only rename entire packages. This seems fine, as it gives little information to the end user. 3) The -tiny mode no longer sets all lines to 0, since it did that by modifying object files. As a temporary measure, we instead set all top-level declarations to be on line 1. A TODO is added to hopefully improve this again in the near future. The upside is that we get rid of all the issues mentioned before. Plus, garble now nearly works with Go 1.16, with the exception of two very minor bugs that look fixable. A follow-up PR will take care of that and start testing on 1.16. Fixes #176. Fixes #190. |
4 years ago | |
---|---|---|
.github | 5 years ago | |
internal | 4 years ago | |
scripts | 4 years ago | |
testdata | 4 years ago | |
.gitattributes | 5 years ago | |
.gitignore | 5 years ago | |
AUTHORS | 5 years ago | |
CONTRIBUTING.md | 4 years ago | |
LICENSE | 5 years ago | |
README.md | 4 years ago | |
bench_test.go | 4 years ago | |
go.mod | 4 years ago | |
go.sum | 4 years ago | |
hash.go | 4 years ago | |
line_obfuscator.go | 4 years ago | |
main.go | 4 years ago | |
main_test.go | 4 years ago | |
reverse.go | 4 years ago | |
runtime_strip.go | 5 years ago | |
shared.go | 4 years ago |
README.md
garble
GO111MODULE=on go get mvdan.cc/garble
Obfuscate Go code by wrapping the Go toolchain. Requires Go 1.15.x; note that support for Go 1.16 is a work in progress.
garble build [build flags] [packages]
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 deobfuscate 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
- Obfuscate literals, if the
-literals
flag is given - Remove extra information if the
-tiny
flag is given
Options
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 module-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.15.8:
$ go get golang.org/dl/go1.15.8
$ go1.15.8 download
$ PATH=$(go1.15.8 env GOROOT)/bin:${PATH} garble build
You can also declare a function to make multiple uses simpler:
$ withgo() {
local gocmd=go${1}
shift
PATH=$(${gocmd} env GOROOT)/bin:${PATH} "$@"
}
$ withgo 1.15.8 garble build
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.
-
Functions implemented outside Go, such as assembly, aren't obfuscated since we currently only transform the input Go source.
-
Go plugins are not currently supported; see #87.
-
There are cases where garble is a little too agressive with obfuscation, this may lead to identifiers getting obfuscated which are needed for reflection, e.g. to parse JSON into a struct; see #162. To work around this you can pass a hint to garble, that an type is used for reflection via passing it to
reflect.TypeOf
orreflect.ValueOf
in the same file:// this is used for parsing json type Message struct { Command string Args string } // never obfuscate the Message type var _ = reflect.TypeOf(Message{})
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 the
prints panics, fatal errors, and trace/debug info. All in all this can make binaries
6-10% smaller in our testing.
Note: if -tiny
is passed, no panics, fatal 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.
Contributing
We actively seek new contributors, if you would like to contribute to garble use the CONTRIBUTING.md as a starting point.