Decompiling Go. Compiling Go without debug info.

[Max]

I have opened compiled Go program (go build) with text editor and found all type names and function names I created.

Is it debug information or why is it located there?

Go executable could not be loaded as library. So there is no sense to leave function names or struct names.

It looks like that Go program could be decompiled in source code like Java.

I thought Go is more like C/C++ that could not be decompiled in original C/C++ source code.

[Jesse McNelis]

On Thu, Dec 19, 2013 at 10:43 AM, Max <max.se...@gmail.com> wrote:
> I have opened compiled Go program (go build) with text editor and found all
> type names and function names I created.
> Is it debug information or why is it located there?

It's information for the reflect package to use, but also debug
information and information for generating stacktraces for panics.

> Go executable could not be loaded as library. So there is no sense to leave
> function names or struct names.
> It looks like that Go program could be decompiled in source code like Java.
> I thought Go is more like C/C++ that could not be decompiled in original
> C/C++ source code.

--
=====================
http://jessta.id.au

[minux]

On Dec 18, 2013 6:43 PM, "Max" <max.se...@gmail.com> wrote:
> I have opened compiled Go program (go build) with text editor and found all type names and function names I created.
> Is it debug information or why is it located there?
>
> Go executable could not be loaded as library. So there is no sense to leave function names or struct names.

i think what you're seeing is the typeinfo, which is for reflect, and symbol table, which could be removed.

> It looks like that Go program could be decompiled in source code like Java.
> I thought Go is more like C/C++ that could not be decompiled in original C/C++ source code.

if you build with -ldflags -w to drop the dwarf debuginfo, there won't be local variable info, which greatly facilitates reverse engineering.

that said, i think code produced by gc is strange enough that unless there are decompiler specifically created for Go, normal decompilers won't work that well.

[minux]

On Dec 18, 2013 6:43 PM, "Max" <max.se...@gmail.com> wrote:
>

i'd like to add that there are pretty good decompilers for C (and C++), and people are still doing research in this field. also, for skilled reverse engineers, no debugging symbols don't honder them much (i even can think of cases where people post-process their binary to add misleading debugging info/symbol table.... which does confues common tools, but not all)

this kind of "protection" is not going to work. (when an adversary has your binary, and if it can be made to operate standalone, all bets are off no matter how much you do)

however, if you remove the symbol table, go panics won't display correctly and Go 1.2 even refuses to run. This only creates problems for your own developers and users, but not for the potential adversaries.

[Max]

Understand. I have not thought about reflection. 

json.Marshal will not work without such info.

function names are important for stacktrace.

Thank You

[zupah...@gmail.com]

One could minify the source (like JS) before compiling, which would destroy the debug info benefits for anyone trying to reverse engineer it.
As go comes with a parser, one is already half way through.