ba19a1d49c
It's common for asset bundling code generators to produce huge literals, for example in strings. Our literal obfuscators are meant for relatively small string-like literals that a human would write, such as URLs, file paths, and English text. I ran some quick experiments, and it seems like "garble build -literals" appears to hang trying to obfuscate literals starting at 5-20KiB. It's not really hung; it's just doing a lot of busy work obfuscating those literals. The code it produces is also far from ideal, so it also takes some time to finally compile. The generated code also led to crashes. For example, using "garble build -literals -tiny" on a package containing literals of over a megabyte, our use of asthelper to remove comments and shuffle line numbers could run out of stack memory. This all points in one direction: we never designed "-literals" to deal with large sizes. Set a source-code-size limit of 2KiB. We alter the literals.txt test as well, to include a few 128KiB string literals. Before this fix, "go test" would seemingly hang on that test for over a minute (I did not wait any longer). With the fix, those large literals are not obfuscated, so the test ends in its usual 1-3s. As said in the const comment, I don't believe any of this is a big problem. Come Go 1.16, most developers should stop using asset-bundling code generators and use go:embed instead. If we wanted to somehow obfuscate those, it would be an entirely separate feature. And, if someone wants to work on obfuscating truly large literals for any reason, we need good tests and benchmarks to ensure garble does not consume CPU for minutes or run out of memory. I also simplified the generate-literals test command. The only argument that matters to the script is the filename, since it's used later on. Fixes #178. |
4 years ago | |
|---|---|---|
| .github | 4 years ago | |
| internal | 4 years ago | |
| scripts | 4 years ago | |
| testdata | 4 years ago | |
| .gitattributes | 5 years ago | |
| .gitignore | 4 years ago | |
| AUTHORS | 4 years ago | |
| CONTRIBUTING.md | 4 years ago | |
| LICENSE | 4 years ago | |
| README.md | 4 years ago | |
| bench_test.go | 4 years ago | |
| go.mod | 4 years ago | |
| go.sum | 4 years ago | |
| hash.go | 4 years ago | |
| import_obfuscation.go | 4 years ago | |
| line_obfuscator.go | 4 years ago | |
| main.go | 4 years ago | |
| main_test.go | 4 years ago | |
| runtime_strip.go | 4 years ago | |
| shared.go | 4 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 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.
Contributing
We actively seek new contributors, if you would like to contribute to garble use the CONTRIBUTING.md as a starting point.