e08dd99c1e
The problem with the "grep" built-in command is that it prints the entire data if there is an error. We don't want megabytes of binary output for a test. |
5 years ago | |
|---|---|---|
| testdata/scripts | 5 years ago | |
| .gitignore | 5 years ago | |
| LICENSE | 5 years ago | |
| README.md | 5 years ago | |
| go.mod | 5 years ago | |
| go.sum | 5 years ago | |
| main.go | 5 years ago | |
| main_test.go | 5 years ago | |
README.md
garble
GO111MODULE=on go get mvdan.cc/garble
Obfuscate a Go build.
garble build [build flags] [packages]
which is equivalent to the longer:
go build -a -trimpath -toolexec=garble [build flags] [packages]
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 bothGOPATHand modules with ease - Deterministic, though the output is not yet reproducible
- Reversible given the original source, to un-garble panic stack traces
Mechanism
The tool wraps calls to the Go compiler to transform the Go source code, in order to:
- Replace as many useful identifiers as possible with short base64 hashes
- Remove module build information
- Remove comments and empty lines, to make position info less useful
It also wraps calls to the linker in order to:
- Enforce the
-sflag, to not include the symbol table - Enforce the
-wflag, to not include DWARF debugging data
Finally, the tool requires the use of the -trimpath build flag, to ensure the
binary doesn't include paths from the current filesystem.
Caveats
The -a flag for go build is required, since -toolexec doesn't work well
with the build cache; see #27628.
Since no caching at all can take place right now (see the link above), builds
will be slower than go build - especially for large projects.
The standard library is never garbled when compiled, since the source is always publicly available.