How to protect (obsfucate) Go binary from cracking

Question

I wish to sell Go application. I will provide serial number to my clients. Is there ways to make it a bit more complex to crack app?

I say it is complex to crack C app and it is easy to crack Java app. Is there tools that will make Go app cracking job as hard as cracking C app? or some tutorial? At least something I could do to protect my project a bit. I do not ask about super heavy protection.

Answer 1

Once you have the binary itself, obfuscation is pretty difficult. People have tried stripping the symbols out of Go binaries before, but it usually leads to instability and unpredictable behavior, since symbols are required for certain reflection operations.

While you can't necessarily obfuscate the libraries you're statically linking against, you can certainly obfuscate your /own/ code by changing variable, type, and function names prior to compilation to names that are meaningless. If you want to go one step further, you can try obtaining the source code for the libraries you're using (the source code for the standard libraries is available and is included in most Go installations), and applying this obfuscation to the library source code as well.

As for post-compilation binary modification, as I mentioned before, it's probably best to stay away from it.

Answer 2

To add on joshlf13's answer: while stripping Go binaries is not recommended, there's a flag you can pass to the linker to omit the debugging symbols all along:

Pass the '-s' flag to the linker to omit the debug information (for example, go build -ldflags "-s" prog.go).

(Debugging Go Code with GDB)

This should at least be a better way, since I haven't seen any warnings for this like the ones about stripping symbols post-compilation.

Answer 3

Another option, with Go 1.16+ (Feb. 2021:

burrowers/garble

Produce a binary that works as well as a regular build, but that has as little information about the original source code as possible.

The tool is designed to be:

• Coupled with cmd/go, to support modules and build caching
• Deterministic and reproducible, given the same initial source code
• Reversible given the original source, to de-obfuscate panic stack traces

That might not be obfuscated enough for your need, but it is a good start.