Forked from: github.com/burrowers/garble
You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
 
 
 
Go to file
Daniel Martí 2fad0e1583 wrap types.Importer to canonicalize import paths
The docs for go/importer.ForCompiler say:

	The lookup function is called each time the resulting importer
	needs to resolve an import path. In this mode the importer can
	only be invoked with canonical import paths (not relative or
	absolute ones); it is assumed that the translation to canonical
	import paths is being done by the client of the importer.

We use a lookup func for two reasons: first, to support modules, and
second, to be able to use our information from "go list -json -export".

However, go/types does not canonicalize import paths before calling
ImportFrom. This is somewhat understandable; it doesn't know whether an
importer was created with a lookup func, and ImportFrom only requires
the input path to be canonicalized in that scenario. When the lookup
func is nil, the importer canonicalizes by itself via go/build.Import.

Before this change, the added crossbuild test would fail:

	> garble build net/http
	[stderr]
	# vendor/golang.org/x/crypto/chacha20
	typecheck error: /usr/lib/go/src/vendor/golang.org/x/crypto/chacha20/chacha_generic.go:10:2: could not import crypto/cipher (can't find import: "crypto/cipher")
	# vendor/golang.org/x/text/secure/bidirule
	typecheck error: /usr/lib/go/src/vendor/golang.org/x/text/secure/bidirule/bidirule.go:12:2: could not import errors (can't find import: "errors")
	# vendor/golang.org/x/crypto/cryptobyte
	typecheck error: /usr/lib/go/src/vendor/golang.org/x/crypto/cryptobyte/asn1.go:8:16: could not import encoding/asn1 (can't find import: "encoding/asn1")
	# vendor/golang.org/x/text/unicode/norm
	typecheck error: /usr/lib/go/src/vendor/golang.org/x/text/unicode/norm/composition.go:7:8: could not import unicode/utf8 (can't find import: "unicode/utf8")

This is because we'd fall back to importer.Default, which only knows how
to find packages in $GOROOT/pkg. Those are missing for cross-builds,
unsurprisingly, as those built archives end up in the build cache.

After this change, we properly support importing std-vendored packages,
so we can get rid of the importer.Default workaround. And, by extension,
cross-builds now work as well.

Note that, in the added test script, the full build of the binary fails,
as there seems to be some sort of linker problem:

	> garble build
	[stderr]
	# test/main
	d9rqJyxo.uoqIiDs5: relocation target runtime.os9A16A3 not defined

We leave that as a TODO for now, as this change is subtle enough as it
is.
5 years ago
.github CI: pin a commit when testing against Go tip 5 years ago
internal make -literals succeed on all of std 5 years ago
scripts update the list of runtime-related packages for 1.16 (#246) 5 years ago
testdata wrap types.Importer to canonicalize import paths 5 years ago
.gitattributes start testing on GitHub Actions 6 years ago
.gitignore skip literals used in constant expressions 5 years ago
AUTHORS set up an AUTHORS file to attribute copyright 5 years ago
CHANGELOG.md CHANGELOG: finish v0.2.0 draft 5 years ago
CONTRIBUTING.md README: document commands 5 years ago
LICENSE set up an AUTHORS file to attribute copyright 5 years ago
README.md README: document commands 5 years ago
bench_test.go rework the build benchmarks 5 years ago
go.mod all: drop support for Go 1.15.x (#265) 5 years ago
go.sum all: drop support for Go 1.15.x (#265) 5 years ago
hash.go use "go env -json" to collect env info all at once 5 years ago
main.go wrap types.Importer to canonicalize import paths 5 years ago
main_test.go handle unknown flags in reverse (#290) 5 years ago
position.go make garble work on Go tip again 5 years ago
reverse.go make reverse error if no changes were made 5 years ago
runtime_strip.go all: drop support for Go 1.15.x (#265) 5 years ago
shared.go use "go env -json" to collect env info all at once 5 years ago

README.md

garble

GO111MODULE=on go get mvdan.cc/garble

Obfuscate Go code by wrapping the Go toolchain. Requires Go 1.16 or later.

garble build [build flags] [packages]

The tool also supports garble test to run tests with obfuscated code, and garble reverse to de-obfuscate text such as stack traces. 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 de-obfuscate 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 via -ldflags="-w -s"
  • Obfuscate literals, if the -literals flag is given
  • Remove extra information, if the -tiny flag is given

By default, the tool obfuscates the packages under the current module. If not running in module mode, then only the main package is obfuscated. To specify what packages to obfuscate, set GOPRIVATE, documented at go help private.

Note that commands like garble build will use the go version found in your $PATH. To use different versions of Go, you can install them and set up $PATH with them. For example, for Go 1.16.1:

$ go get golang.org/dl/go1.16.1
$ go1.16.1 download
$ PATH=$(go1.16.1 env GOROOT)/bin:${PATH} garble build

Literal obfuscation

Using the -literals flag causes literal expressions such as strings to be replaced with more complex variants, resolving to the same value at run-time. This feature is opt-in, as it can cause slow-downs depending on the input code.

Literal expressions used as constants cannot be obfuscated, since they are resolved at compile time. This includes any expressions part of a const declaration.

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 that prints panics, fatal errors, and trace/debug info. All in all this can make binaries 2-5% smaller in our testing.

Note: if -tiny is passed, no panics or 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.

Speed

garble build should take about twice as long as go build, as it needs to complete two builds. The original build, to be able to load and type-check the input code, and finally the obfuscated build.

Go's build cache is fully supported; if a first garble build run is slow, a second run should be significantly faster. This should offset the cost of the double builds, as incremental builds in Go are fast.

Determinism and seeds

Just like Go, garble builds are deterministic and reproducible if the inputs remain the same: the version of Go, the version of Garble, and the input code. This has significant benefits, such as caching builds or being able to use garble reverse to de-obfuscate stack traces.

However, it also means that an input package will be obfuscated in exactly the same way if none of those inputs change. If you want two builds of your program to be entirely different, you can use -seed to provide a new seed for the entire build, which will cause a full rebuild.

If any open source packages are being obfuscated, providing a custom seed can also provide extra protection. It could be possible to guess the versions of Go and garble given how a public package was obfuscated without a seed.

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 obfuscated at the moment, since they could be required by interfaces and reflection. This area is a work in progress.

  • It can be hard for garble to know what types will be used with reflection, including JSON encoding or decoding. If your program breaks because a type's names are obfuscated when they should not be, you can add an explicit hint:

    type Message struct {
    	Command string
    	Args    string
    }
    
    // Never obfuscate the Message type.
    var _ = reflect.TypeOf(Message{})
    
  • Go plugins are not currently supported; see #87.

Contributing

We welcome new contributors. If you would like to contribute, see CONTRIBUTING.md as a starting point.