Import path obfuscation

[lu4p]

Add package name obfuscation similar to what gobfuscate does for GOPATH.

[mvdan]

Unfortunately I don't think there is a way to do this with our design. We obfuscate one package at a time, while other tools like gobfuscate work on an entire GOPATH at once. When we're obfuscating a package foo/bar, it's already being built under that import path, because we are not in control of resolving dependencies and locating packages. We only control the compiler and linker's inputs.

I really don't want to take the "obfuscate the entire world" approach that gobfuscate takes, too. That requires a ton of upfront work and it's slow, so it doesn't scale to large builds at all. It's also much trickier to implement properly if one wants to support both GOPATH and modules.

[lu4p]

Do you think it is possible to replace all paths in the resulting binary?

[mvdan]

We control when the linker is called, so we could modify the resulting binary. But, how? I assume simple search and replace wouldn't work well at all. It's an interesting idea, but it requires some research.

[mvdan]

I've expanded the README with current shortcomings of the tool, clarifying that many of them can probably be improved in the future.

[capnspacehook]

I think modifying produced object files would be the best bet. As was mentioned in #44, modifying binaries would be more work as we'd have to support code to modify PE, ELF, MACH-O and more binary formats. Not to mention, most binary files would break if you replaced a string in the binary with a string of a different size, meaning we'd only be able to randomize the import paths such that they didn't change size, which is useful information to humans.

Also, are there any rules related to Go import paths that would prevent us from fully randomizing import paths? For example, would renaming github.com/foo/bar to a and github.com/foo/bar/baz to b break things, because github.com/foo/bar/baz is a subpackage of github.com/foo/bar? If not, I think fully randomizing import paths would be extremely beneficial.

[mvdan]

Also, are there any rules related to Go import paths that would prevent us from fully randomizing import paths?

Before the build happens, there are definitely rules in place. For example, the internal package rules work on path element prefixes. However, as far as I can tell those rules are enforced at compile time only, and the linker shouldn't care if we replace the import paths.

That being said, the replacement should still be deterministic, just like the rest of the tool. If anyone wants to have a crack at this, patches are welcome, though it's a pretty difficult task to get started with. You should probably attempt a smaller PR first.

[capnspacehook]

I'm interested in tackling this, what smaller patch do you suggest starting with? Also, my first step is going to be parsing the object files, does anyone know of any libraries to parse and get offsets of symbols in Go object files? goobj looks promising, but what's the difference between goobj and goob2? Does goobj2 deal with the new object format?

[lu4p]

@capnspacehook Can you provide links to goobj and goobj2?

[lu4p]

@capnspacehook Maybe have a go at #39 first, which should be relativly easy and helps you to understand the codebase.

[mvdan]

@capnspacehook as a first patch, how about this TODO here? https://github.com/mvdan/garble/blob/3e4f3821ea8516068e6b3d87e89473d99825c060/main.go#L567

It's an optimization to save a bit of work when -literals isn't used. I reckon it should be under a dozen lines of code, and it shouldn't require any test changes as the tool already has tests with and without the flag.

does anyone know of any libraries to parse and get offsets of symbols in Go object files? goobj looks promising, but what's the difference between goobj and goob2? Does goobj2 deal with the new object format?

I don't have a good answer for you there, sorry. Perhaps check the Go repo's git log to see where they come from. It is true that Go has a new object format, though, and we only support the latest stable Go version, so you should completely ignore the old object (export) format.

@lu4p #39 is probably easier than this one, but I still wouldn't call it an easy first issue :)

[capnspacehook]

@lu4p links to goobj and goobj2:

• https://golang.org/pkg/cmd/internal/goobj
• https://golang.org/pkg/cmd/internal/goobj2

[lu4p]

@capnspacehook goobj2 is the one you want

[capnspacehook]

@mvdan sounds good, I'll work on that small optimization first.

[capnspacehook]

Hmm, looks like goobj will actually work just fine... it apparently works with both the old and new formats automatically

https://github.com/golang/go/blob/master/src/cmd/internal/goobj/read.go#L511

[lu4p]

Ok

[mvdan]

FYI both, I've started the #obfuscation channel over at the Gophers slack, so it could be a place to exchange short messages or questions about garble. I intend to keep using GitHub to track issues, but I understand that comments on here are generally asynchronous.