|
|
|
# garble
|
|
|
|
|
|
|
|
go install mvdan.cc/garble@latest
|
|
|
|
|
|
|
|
Obfuscate Go code by wrapping the Go toolchain. Requires Go 1.17 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:
|
|
|
|
|
initial support for build caching (#142)
As per the discussion in https://github.com/golang/go/issues/41145, it
turns out that we don't need special support for build caching in
-toolexec. We can simply modify the behavior of "[...]/compile -V=full"
and "[...]/link -V=full" so that they include garble's own version and
options in the printed build ID.
The part of the build ID that matters is the last, since it's the
"content ID" which is used to work out whether there is a need to redo
the action (build) or not. Since cmd/go parses the last word in the
output as "buildID=...", we simply add "+garble buildID=_/_/_/${hash}".
The slashes let us imitate a full binary build ID, but we assume that
the other components such as the action ID are not necessary, since the
only reader here is cmd/go and it only consumes the content ID.
The reported content ID includes the tool's original content ID,
garble's own content ID from the built binary, and the garble options
which modify how we obfuscate code. If any of the three changes, we
should use a different build cache key. GOPRIVATE also affects caching,
since a different GOPRIVATE value means that we might have to garble a
different set of packages.
Include tests, which mainly check that 'garble build -v' prints package
lines when we expect to always need to rebuild packages, and that it
prints nothing when we should be reusing the build cache even when the
built binary is missing.
After this change, 'go test' on Go 1.15.2 stabilizes at about 8s on my
machine, whereas it used to be at around 25s before.
5 years ago
|
|
|
* 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](https://go.dev/pkg/runtime/#Version) and [module](https://go.dev/pkg/runtime/debug/#ReadBuildInfo) information
|
|
|
|
* Strip filenames and shuffle position information
|
|
|
|
* Strip debugging information and symbol tables via `-ldflags="-w -s"`
|
|
|
|
* [Obfuscate literals](#literal-obfuscation), if the `-literals` flag is given
|
|
|
|
* Remove [extra information](#tiny-mode), if the `-tiny` flag is given
|
|
|
|
|
deprecate using GOPRIVATE in favor of GOGARBLE (#427)
Piggybacking off of GOPRIVATE is great for a number of reasons:
* People tend to obfuscate private code, whose package paths will
generally be in GOPRIVATE already
* Its meaning and syntax are well understood
* It allows all the flexibility we need without adding our own env var
or config option
However, using GOPRIVATE directly has one main drawback.
It's fairly common to also want to obfuscate public dependencies,
to make the code in private packages even harder to follow.
However, using "GOPRIVATE=*" will result in two main downsides:
* GONOPROXY defaults to GOPRIVATE, so the proxy would be entirely disabled.
Downloading modules, such as when adding or updating dependencies,
or when the local cache is cold, can be less reliable.
* GONOSUMDB defaults to GOPRIVATE, so the sumdb would be entirely disabled.
Adding entries to go.sum, such as when adding or updating dependencies,
can be less secure.
We will continue to consume GOPRIVATE as a fallback,
but we now expect users to set GOGARBLE instead.
The new logic is documented in the README.
While here, rewrite some uses of "private" with "to obfuscate",
to make the code easier to follow and harder to misunderstand.
Fixes #276.
3 years ago
|
|
|
The tool obfuscates the packages matching `GOGARBLE`, a comma-separated list of
|
|
|
|
glob patterns of module path prefixes, as documented in `go help private`.
|
|
|
|
When `GOGARBLE` is empty, it assumes the value of `GOPRIVATE`.
|
|
|
|
When `GOPRIVATE` is also empty, then `GOGARBLE` assumes the value of the current
|
|
|
|
module path, to obfuscate all packages under the current module.
|
|
|
|
|
|
|
|
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](https://go.dev/doc/manage-install#installing-multiple)
|
|
|
|
and set up `$PATH` with them. For example, for Go 1.17.1:
|
|
|
|
|
|
|
|
```sh
|
|
|
|
$ go install golang.org/dl/go1.17.1@latest
|
|
|
|
$ go1.17.1 download
|
|
|
|
$ PATH=$(go1.17.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, as well as prevent extracting some more information.
|
|
|
|
|
|
|
|
With this flag, no panics or fatal runtime 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.
|
|
|
|
|
|
|
|
Note that this flag can make debugging crashes harder, as a panic will simply
|
|
|
|
exit the entire program without printing a stack trace, and all source code
|
|
|
|
positions are set to line 1. Similarly, `garble reverse` is generally not useful
|
|
|
|
in this mode.
|
|
|
|
|
|
|
|
### 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 then the obfuscated build.
|
|
|
|
|
|
|
|
Garble obfuscates one package at a time, mirroring how Go compiles one package
|
|
|
|
at a time. This allows Garble to fully support Go's build cache; incremental
|
|
|
|
`garble build` calls should only re-build and re-obfuscate modified code.
|
|
|
|
|
|
|
|
Note that the first call to `garble build` may be comparatively slow,
|
|
|
|
as it has to obfuscate each package for the first time. This is akin to clearing
|
|
|
|
`GOCACHE` with `go clean -cache` and running a `go build` from scratch.
|
|
|
|
|
|
|
|
### Determinism and seeds
|
|
|
|
|
|
|
|
Just like Go, garble builds are deterministic and reproducible in nature.
|
|
|
|
This has significant benefits, such as caching builds and being able to use
|
|
|
|
`garble reverse` to de-obfuscate stack traces.
|
|
|
|
|
|
|
|
By default, garble will obfuscate each package in a unique way,
|
|
|
|
which will change if its build input changes: the version of garble, the version
|
|
|
|
of Go, the package's source code, or any build parameter such as GOOS or -tags.
|
|
|
|
This is a reasonable default since guessing those inputs is very hard.
|
|
|
|
|
|
|
|
However, providing your own obfuscation seed via `-seed` brings some advantages.
|
|
|
|
For example, builds sharing the same seed will produce the same obfuscation,
|
|
|
|
even if any of the build parameters or versions vary.
|
|
|
|
It can also make reverse-engineering harder, as an end user could guess what
|
|
|
|
version of Go or garble you're using.
|
|
|
|
|
|
|
|
Note that extra care should be taken when using custom seeds.
|
|
|
|
If a seed used to build a binary gets lost, `garble reverse` will not work.
|
|
|
|
Rotating the seeds can also help against reverse-engineering in the long run,
|
|
|
|
as otherwise some bits of code may be obfuscated the same way over time.
|
|
|
|
|
|
|
|
An alternative approach is `-seed=random`, where each build is entirely different.
|
|
|
|
|
|
|
|
### 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. This area is a work in progress; see
|
detect more std API calls which use reflection
Before, we would just notice direct calls to reflect's TypeOf and
ValueOf. Any other uses of reflection, such as encoding/json or
google.golang.org/protobuf, would require hints as documented by the
README.
Issue #162 outlines some ways we could fix this issue in a general way,
automatically detecting what functions use reflection on their parameters,
even for third party API funcs.
However, that goal is pretty significant in terms of code and effort.
As a temporary improvement, we can expand the list of "known" reflection
APIs via a static table.
Since this table is keyed by "func full name" strings, we could
potentially include third party APIs, such as:
google.golang.org/protobuf/proto.Marshal
However, for now simply include all the std APIs we know about.
If we fail to do the proper fix for automatic detection in the future,
we can then fall back to expanding this global table for third parties.
Update the README's docs, to clarify that the hint is not always
necessary anymore.
Also update the reflect.txt test to stop using the hint for encoding/json,
and to also start testing text/template with a method call.
While at it, I noticed that we weren't testing the println outputs,
as they'd go to stderr - fix that too.
Updates #162.
4 years ago
|
|
|
[#3](https://github.com/burrowers/garble/issues/3).
|
|
|
|
|
|
|
|
* Garble aims to automatically detect which Go types are used with reflection,
|
|
|
|
as obfuscating those types might break your program.
|
|
|
|
Note that Garble obfuscates [one package at a time](#speed),
|
|
|
|
so if your reflection code inspects a type from an imported package,
|
|
|
|
and your program broke, you may need to add a "hint" in the imported package:
|
|
|
|
```go
|
|
|
|
type Message struct {
|
|
|
|
Command string
|
|
|
|
Args string
|
|
|
|
}
|
|
|
|
|
|
|
|
// Never obfuscate the Message type.
|
|
|
|
var _ = reflect.TypeOf(Message{})
|
|
|
|
```
|
|
|
|
|
|
|
|
* Go declarations exported for cgo via `//export` are not obfuscated.
|
|
|
|
|
|
|
|
* Go plugins are not currently supported; see [#87](https://github.com/burrowers/garble/issues/87).
|
|
|
|
|
|
|
|
### Contributing
|
obfuscate unexported names like exported ones (#227)
In 90fa325da7, the obfuscation logic was changed to use hashes for
exported names, but incremental names starting at just one letter for
unexported names. Presumably, this was done for the sake of binary size.
I argue that this is not a good idea for the default mode for a number
of reasons:
1) It makes reversing of stack traces nearly impossible for unexported
names, since replacing an obfuscated name "c" with "originalName"
would trigger too many false positives by matching single characters.
2) Exported and unexported names aren't different. We need to know how
names were obfuscated at a later time in both cases, thanks to use
cases like -ldflags=-X. Using short names for one but not the other
doesn't make a lot of sense, and makes the logic inconsistent.
3) Shaving off three bytes for unexported names doesn't seem like a huge
deal for the default mode, when we already have -tiny to optimize for
size.
This saves us a bit of work, but most importantly, simplifies the
obfuscation state as we no longer need to carry privateNameMap between
the compile and link stages.
name old time/op new time/op delta
Build-8 153ms ± 2% 150ms ± 2% ~ (p=0.065 n=6+6)
name old bin-B new bin-B delta
Build-8 7.09M ± 0% 7.08M ± 0% -0.24% (p=0.002 n=6+6)
name old sys-time/op new sys-time/op delta
Build-8 296ms ± 5% 277ms ± 6% -6.50% (p=0.026 n=6+6)
name old user-time/op new user-time/op delta
Build-8 562ms ± 1% 558ms ± 3% ~ (p=0.329 n=5+6)
Note that I do not oppose using short names for both exported and
unexported names in the future for -tiny, since reversing of stack
traces will by design not work there. The code can be resurrected from
the git history if we want to improve -tiny that way in the future, as
we'd need to store state in header files again.
Another major cleanup we can do here is to no longer use the
garbledImports map. From a look at obfuscateImports, we hash a package's
import path with its action ID, much like exported names, so we can
simply re-do that hashing for the linker's -X flag.
garbledImports does have some logic to handle duplicate package names,
but it's worth noting that should not affect package paths, as they are
always unique. That area of code could probably do with some
simplification in the future, too.
While at it, make hashWith panic if either parameter is empty.
obfuscateImports was hashing the main package path without a salt due to
a bug, so we want to catch those in the future.
Finally, make some tiny spacing and typo tweaks to the README.
4 years ago
|
|
|
|
|
|
|
We welcome new contributors. If you would like to contribute, see
|
|
|
|
[CONTRIBUTING.md](CONTRIBUTING.md) as a starting point.
|