b8aec97e86
In the added test case, we'd see a failure, since we garbled the name of the "Embedded" type but not its use as an anonymous field. Garble both. This might possibly break some reflect code, but it doesn't seem like we have an option. When we garble a type, it's impossible to tell if it's going to be used as an anonymous field later. Updates #9. |
4 years ago | |
|---|---|---|
| .github | 4 years ago | |
| testdata/scripts | 4 years ago | |
| .gitattributes | 5 years ago | |
| .gitignore | 5 years ago | |
| LICENSE | 5 years ago | |
| README.md | 4 years ago | |
| go.mod | 4 years ago | |
| go.sum | 4 years ago | |
| main.go | 4 years ago | |
| main_test.go | 4 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.
-
Similarly to methods, exported struct fields are difficult to garble, as the names might be relevant for reflection work like
encoding/json