For now, it mainly consists of not garbling Test* funcs, and not garbling the _testmain.go file that will run them. Updates #6. |
6 years ago | |
|---|---|---|
| .github | 6 years ago | |
| testdata/scripts | 6 years ago | |
| .gitattributes | 6 years ago | |
| .gitignore | 6 years ago | |
| LICENSE | 6 years ago | |
| README.md | 6 years ago | |
| go.mod | 6 years ago | |
| go.sum | 6 years ago | |
| main.go | 6 years ago | |
| main_test.go | 6 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.