Modify cmd/link

[pagran]

Idea, is to modify and build cmd/link on the user's computer.

Patch making

According to @mvdan idea to make a fork with changes and updates based on garble supported version of golang. Then manually use git diff to generate patches which will later be used to change cmd/link.

Build process and caching modified linker

1. Retrieve $GOROOT and get full path $GOROOT/src/cmd/link
2. Copy original files modifiable by the patches to a temporary folder and apply patches
3. go build -overlay ${tmp}/fileWithListOfModifiedFilesAt2Step.json -o ${os.UserCacheDir}/.garble/link cmd/link
4. Save patchesHash + golangVersion nearby modified linker to keep it up to date

Launch logic:

1. If there is no .garble/link file - build linker
2. If there is a file - check version in step 4. If version don't match - rebuild linker
3. If file exists and hash matches - use it

Features for first version

Randomize magic value in moduledata, to increase difficulty of automatic analysis (PoC)

2. Completely removing function names (guaranteed to break reflexion) by writing an empty runtime.functab (code)
2.1. Or a more difficult way, we can hash all the names hash(name+randSalt) and modify the reflection. This will hide filenames and keep the reflection working.
4. Completely removing file names by writing an empty runtime.filetab (code)

[pagran]

Completely removing file names - tested and working (-3.7%)
Completely removing function names - tested and working (-3.9%)

Together: -7.7% (81kb)

[mvdan]

For step 3 of the linker build, put the binary in UserCacheDir/garble/link or something like that - then we can reuse that garble cache directory for other stuff in the future.

5. Add to the end of the compiled linker file obtained hash

What do you mean by "at the end"? It sounds to me like we could store that "inputs hash" as a file alongside the linker binary, which would be easier to reason about. If either the binary or the hash file are missing, we would rebuild.

As for the features - I think we should begin by just shuffling magic numbers. That's an easy change, so we can focus on reviewing the linker patching logic, and let our users test it before we develop more features.

I also don't think that feature should be behind a flag like --link-random-magic. Randomizing the magic number is presumably something that most users of garble will want, and I don't see a disadvantage to doing so, so we should just always do it.

I'm not going to comment on the two other proposed features for now. They sound interesting, but I think we can talk about them when the first one is in master and it works well :)

[pagran]

"at the end" - just write to end of the linker binary, this should not affect workability in any way

[mvdan]

Gotcha. I'd still use a separate file, as that's easier to understand and debug. It's also how Go's own build cache works - some files contain the built content, other files just contain hashes.

[pagran]

Okay, i will try to prepare a pullrequest on weekends