Obfuscation and Go templates

[tdewolff]

This project is pretty impressive, I've been unable to extract significant amounts of meaningful data after running garble (think of strings, https://github.com/goretk/redress and https://github.com/mandiant/GoReSym), great job, very useful!

I'm wondering how templates work and how variable names and functions names as invoked in templates continue to work after obfuscation. I've noticed how the struct fields are obfuscated, but the template continues to work addressing those fields, how is that possible?

[luantak]

Here's the commit in which I implemented the current approach for dealing with reflection, the commit message is quite thorough.

926f3de

If you want any more clarification feel free to ask.

[tdewolff]

Thank you for your help Paul! Very neat how the names are obfuscated and reversed when actually used. Naturally this is not real security, but neither is obfuscation, still it makes it harder for disassembly to return anything meaningful. I've noticed the need to add var _ = reflect.TypeOf(Type{}) for some types, which is why I was investigating this feature. This happened in the following case:

// package github.com/tdewolff/private/cmd/foobar
type S struct {
    Field string
    Nested private.Nested
}
// var _ = reflect.TypeOf(Nested{}) // not needed

// package github.com/tdewolff/private
type Nested struct {
    Foo string
    Bar string
}
var _ = reflect.TypeOf(Nested{}) // prevent garble

The last line was required in order to access those fields from a template in private/cmd/foobar. It looks like the fields are still obfuscated though, but the reflect.TypeOf line makes them accessible by their original field names. Is this intended or a bug?

[luantak]

Naturally this is not real security, but neither is obfuscation, still it makes it harder for disassembly to return anything meaningful.

Just to clarify this was never done to provide additional obfuscation, previously the reflected names weren't obfuscated at all. This lead to many programs breaking, because in go separate types with the same fields can be used interchangeably, so if type A is obfuscated but type B is not, their signatures no longer match leading to compilation errors. So we now just obfuscate everything, and inject the names we need for reflection.

We currently only detect reflection of types which are reflected in the same package they're defined in.

This made sense when we excluded the names from obfuscation entirely (single pass in package compile order), because we couldn't know at that point that dependents reflected that type.

As we now just record the name we can definitely change this behavior to record upstream types as reflected when reflected in downstream packages.

You shouldn't need to add reflect.TypeOf hints at all anymore, if you have to it's a bug.