Now that we've dropped support for Go 1.15.x, we can finally rely on this environment variable for toolexec calls, present in Go 1.16. Before, we had hacky ways of trying to figure out the current package's import path, mostly from the -p flag. The biggest rough edge there was that, for main packages, that was simply the package name, and not its full import path. To work around that, we had a restriction on a single main package, so we could work around that issue. That restriction is now gone. The new code is simpler, especially because we can set curPkg in a single place for all toolexec transform funcs. Since we can always rely on curPkg not being nil now, we can also start reusing listedPackage.Private and avoid the majority of repeated calls to isPrivate. The function is cheap, but still not free. isPrivate itself can also get simpler. We no longer have to worry about the "main" edge case. Plus, the sanity check for invalid package paths is now unnecessary; we only got malformed paths from goobj2, and we now require exact matches with the ImportPath field from "go list -json". Another effect of clearing up the "main" edge case is that -debugdir now uses the right directory for main packages. We also start using consistent debugdir paths in the tests, for the sake of being easier to read and maintain. Finally, note that commandReverse did not need the extra call to "go list -toolexec", as the "shared" call stored in the cache is enough. We still call toolexecCmd to get said cache, which should probably be simplified in a future PR. While at it, replace the use of the "-std" compiler flag with the Standard field from "go list -json". |
4 years ago | |
---|---|---|
.github | 4 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 | |
CHANGELOG.md | 4 years ago | |
CONTRIBUTING.md | 5 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 | 4 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.16 or later.
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 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
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.16.1 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 that
prints panics, fatal errors, and trace/debug info. All in all this can make binaries
2-5% 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.