garble: consider ways to better obfuscate function bodies

Right now we strip some information away from the compiled code in function bodies, such as position information, variable names, and the names of funcs and types being used. However, the compiled code looks otherwise extremely similar to its non-obfuscated counterpart, especially in its structure.

For example, if I perform two obfuscated builds of the same program with different seeds, all the func/type/var names will be different, but one could deobfuscate a function body and quickly spot the pairs of corresponding obfuscated names in the two builds, as the structure of the function will be very similar. Meaning that if I manage to figure out what an obfuscated name in one build stands for, I can reuse that knowledge rather easily in the other build.

One can also imagine deobfuscating the Go code and trying to spot common patterns in “idiomatic” Go code, such as if err != nil { handle(err) }. Being able to quickly spot these patterns, even if the names are obfuscated, could lead to an easier understanding of what the code is doing.

We should investigate ways to improve this situation. In general terms, what we want is to deterministically “shuffle” the code around using the seed, akin to what we already do with literal obfuscation or when reordering declarations.

Doing this at the machine code level definitely seems like a bad idea; we’d need to explicitly support each GOARCH target. It would also require being able to modify object files in-place, further increasing the required complexity.

Doing it at the Go syntax level via go/ast is probably the most obvious option we have. We already do something like it when obfuscating literals, and it seems to work well. I think it could become more feasible if we implemented a “reduction” of the AST first, as per https://github.com/burrowers/garble/issues/459.

Doing this at the compiler’s SSA IR level could also be interesting. Advantages:

• As a heavily simplified form of the code, we could apply “rewrites” of the SSA program more easily. The go/ast is significantly more complex than go/ssa, as there are multiple ways to write the same piece of logic.
• We could perhaps perform heavier obfuscation this way, as SSA is further down the compiler pipeline when compared to the Go syntax.

Disadvantages:

• The complexity in design and execution; the SSA is not exposed via -toolexec, and is only kept in memory. This would likely mean having to build and use a modified version of cmd/compile.
• Unlike go/ast and the Go syntax, Go’s SSA representation is internal and may change in backwards-incompatible ways over the course of Go releases.
• Harder to contribute: while SSA isn’t a particularly hard concept in the field of compilers, the average Go developer will probably not be familiar with it.
• Unhelpful for source code obfuscation; https://github.com/burrowers/garble/issues/369 wouldn’t benefit from it at all.

Thus, my initial thoughts are that we should aim for obfuscating func bodies via go/ast rather than the compiler’s internal SSA. Happy to hear opinions, counter-points, or other potential ways to solve this.