0

When use command "nm go_binary", I find the names of variables, functions and packages and even the directory where my code is located are all displayed, is there any way to obfuscate the binary generated by the command "go build" and prevent go binary from being exploited by hackers?

thinkhy
  • 923
  • 13
  • 25
  • 5
    Obfuscating the names isn't going to stop any reverse engineering, it will hardly slow down the process. – JimB May 08 '16 at 15:54
  • 1
    https://www.reddit.com/r/golang/comments/3pmkwi/i_started_obfuscating_some_code_for_fun_and_got/? looks good ;) https://play.golang.org/p/WW-1fgSZW_ – VonC May 08 '16 at 16:09
  • 2
    @JimB Thanks for your quick reply. Obfuscating can't stop reverse engineering but in a way prevent info leakage. – thinkhy May 09 '16 at 15:56

2 Answers2

2

Obfuscating can't stop reverse engineering but in a way prevent info leakage

That is what burrowers/garble (Go 1.16+, Feb. 2021):

Literal obfuscation

Using the -literals flag causes literal expressions such as strings to be replaced with more complex variants, resolving to the same value at run-time.
This feature is opt-in, as it can cause slow-downs depending on the input code.

Literal expressions used as constants cannot be obfuscated, since they are resolved at compile time. This includes any expressions part of a const declaration.

Tiny mode

When the -tiny flag is passed, extra information is stripped from the resulting Go binary.
This includes line numbers, filenames, and code in the runtime that prints panics, fatal errors, and trace/debug info.
All in all this can make binaries 2-5% smaller in our testing, as well as prevent extracting some more information.

With this flag, no panics or fatal runtime errors will ever be printed, but they can still be handled internally with recover as normal.
In addition, the GODEBUG environmental variable will be ignored.

But:

Exported methods are never obfuscated at the moment, since they could be required by interfaces and reflection. This area is a work in progress.

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

I think the best answer to this question is here How do I protect Python code?, specifically this answer.

While that question is about Python, it applies to all code in general.

I was gonna mark this question as a duplicate, but maybe someone will provide more insight into it.

Community
  • 1
  • 1
OneOfOne
  • 95,033
  • 20
  • 184
  • 185