Go binary mangling

[xtuc (Sven Sauleau)]

We have a close-source application and we want to distribute binaries. The binaries emitted by Golang are particularly easy to disassemble. You can find more detail at http://xtuc.fr/notes/disassemble-go.html.

I understand that if you are building an application in the cloud you usually don’t care about someone reverse engineering your binary.

The only solution I have found is to create a tool. I’m currently writing a Golang source mangler. It’s built on top of go/types (and go/ast).

I recently compiled my app using gccgo and was expecting gcc to mangle all the identifiers. I think that only function calls are mangled (but still readable) via https://github.com/golang/gofrontend/blob/e0c1f0b645b12a544b484c0f477f8fb6f5980550/libgo/go/cmd/cgo/gcc.go#L659-L668. I can still see my function declarations with their type signature.

It seems that our use case is not common, or how do you handle it? Is the Go team willing to do something about it?

Thanks,
Sven.

[Giulio_Iotti]

I am not sure what the “threat model” is for this operation. I think it’s mostly a net loss: advanced reversers are not slowed down at all by having the functions renamed, normal users will report unreadable stack traces when your program will eventually panic and crash.

What are you trying to defend against, exactly? You should model what attack you want to avoid and establish procedures to mitigate that precise case.