16

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.

JasonMArcher
  • 14,195
  • 22
  • 56
  • 52
Shuriken
  • 1,382
  • 1
  • 12
  • 14
  • 2
    As you seem to be uncertain if you should use obfuscation at all, consider reading [this question](http://programmers.stackexchange.com/questions/129296/the-case-for-code-obfuscation). – nemo Jan 04 '14 at 22:49
  • 1
    As far as I know there are no ways to make your binary impossible to decompile. You can certainly make it quite difficult but I suggest you look at other ways to protect your application other than obfuscation – ymg Jan 04 '14 at 22:53
  • 2
    Actually, decompiling C binaries is a lot more difficult that decompiling Java binaries as the Java compiler does not change very much. A .class file has a lot of resemblance to the original .java file, but if you compile a C source code form and strip it of it's symbols almost all structural information is lost. – fuz Jan 04 '14 at 23:11
  • @FUZxxl It is what I said. Once I lost source code of Jar file decompiled jad had only one bug (goto) .class is source code. – Shuriken Jan 05 '14 at 11:46
  • @YasirG. I do not wish to make it impossible. I just wish to do some basic steps that are resonable to do like linker flag `-s` mentioned by junitas – Shuriken Jan 05 '14 at 11:48

3 Answers3

8

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.

joshlf
  • 21,822
  • 11
  • 69
  • 96
7

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.

justinas
  • 6,287
  • 3
  • 26
  • 36
  • 1
    Do you know how much that removes? I suspect that it can't remove everything, since reflection still needs to work properly. – joshlf Jan 05 '14 at 19:27
  • 2
    I don't know exactly how reflection is implemented, but it seems to be done in the Go runtime itself and not relying on debugging symbols. [This program](http://play.golang.org/p/GYc-NWb_FZ) runs fine even without debugging symbols. – justinas Jan 05 '14 at 19:42
  • 1
    It's things like [(*runtime.Func).Name()](http://golang.org/pkg/runtime/#Func.Name) that make me think there has to be some information still lying around. – joshlf Jan 05 '14 at 20:00
  • 2
    Oh shit. It looks like it does it aggresively, even if it breaks runtime reflection. Check out this [code snippet](https://gist.github.com/joshlf13/8273261) (which takes the address of main, and then uses reflection to find the name of the function). – joshlf Jan 05 '14 at 20:18
  • 2
    Seems to be fixed in later versions: compiled it under Go 1.2 and [it works](http://pastebin.com/raw.php?i=83e0brfp). – justinas Jan 05 '14 at 21:52
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.

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