2a0ac434fb
As per the discussion in https://github.com/golang/go/issues/41145, it turns out that we don't need special support for build caching in -toolexec. We can simply modify the behavior of "[...]/compile -V=full" and "[...]/link -V=full" so that they include garble's own version and options in the printed build ID. The part of the build ID that matters is the last, since it's the "content ID" which is used to work out whether there is a need to redo the action (build) or not. Since cmd/go parses the last word in the output as "buildID=...", we simply add "+garble buildID=_/_/_/${hash}". The slashes let us imitate a full binary build ID, but we assume that the other components such as the action ID are not necessary, since the only reader here is cmd/go and it only consumes the content ID. The reported content ID includes the tool's original content ID, garble's own content ID from the built binary, and the garble options which modify how we obfuscate code. If any of the three changes, we should use a different build cache key. GOPRIVATE also affects caching, since a different GOPRIVATE value means that we might have to garble a different set of packages. Include tests, which mainly check that 'garble build -v' prints package lines when we expect to always need to rebuild packages, and that it prints nothing when we should be reusing the build cache even when the built binary is missing. After this change, 'go test' on Go 1.15.2 stabilizes at about 8s on my machine, whereas it used to be at around 25s before. |
5 years ago | |
|---|---|---|
| .github | 5 years ago | |
| internal | 5 years ago | |
| scripts | 5 years ago | |
| testdata | 5 years ago | |
| .gitattributes | 5 years ago | |
| .gitignore | 5 years ago | |
| AUTHORS | 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 | |
| import_obfuscation.go | 5 years ago | |
| line_obfuscator.go | 5 years ago | |
| main.go | 5 years ago | |
| main_test.go | 5 years ago | |
| runtime_strip.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.15 or later, since Go 1.14 uses an entirely different object format.
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 un-garble 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
-literalsflag is given - Removes extra information if the
-tinyflag is given
Options
By default, the tool garbles the packages under the current module. If not
running in module mode, then only the main package is garbled. To specify what
packages to garble, set GOPRIVATE, documented at go help module-private.
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 and fields are never garbled 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 garbled since we currently only transform the input Go source.
-
Go plugins are not currently supported; see #87.
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.