b10cce34f8
This is important, because "-std -foo" and "-buildid -foo" are entirely different cases. The first is equivalent to "-std=true -foo" since the flag is boolean, but the second is equivalent to "-buildid=-foo" since the flag isn't boolean. We can keep track of which of the flags we're interested in are boolean, which isn't much extra work. Also add unit tests; the build ID is a hash, so it's very hard to write an end-to-end test that reliably has an ID starting with a dash. |
5 years ago | |
|---|---|---|
| .github | 5 years ago | |
| testdata/scripts | 5 years ago | |
| .gitattributes | 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. Requires Go 1.13 or later.
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 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 to transform the Go source code, in order to:
- Replace as many useful identifiers as possible with short base64 hashes
- Remove module build information
- Strip filenames and unnecessary 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
-aflag forgo buildis required, since-toolexecdoesn'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.
-
Deciding what method names to garble is always going to be difficult, due to interfaces that could be implemented up or down the package import tree.
-
Some uses of the
reflectpackage may break, such as accessing a struct's field, whose name has been garbled.