ungarbler protection

[chatonick]

There are such projects
https://github.com/mandiant/gostringungarbler
https://github.com/Invoke-RE/ungarble_bn
https://cloud.google.com/blog/topics/threat-intelligence/gostringungarbler-deobfuscating-strings-in-garbled-binaries
https://invokere.com/posts/2025/03/ungarble-deobfuscating-golang-with-binary-ninja/

To perform this process automatically, the primary challenge lies in identifying all decrypting subroutines introduced by garble's transformations. Our analysis revealed a consistent pattern—decrypted strings are always processed through Go's runtime_slicebytetostring function before being returned by the decrypting subroutine. This observation provides a reliable anchor point, allowing us to construct regular expression (regex) patterns to automatically detect these subroutines.

Do you have any idea how to protect the binary file from these attacks?

[mvdan]

This is not an actionable issue; I'll move to a discussion.

[mvdan]

These projects only undo string obfuscation, which is opt-in and a tiny part of what garble does. And, by design, the data is always there.

[mvdan]

Expanded here: #984

[chatonick]

These projects only undo string obfuscation

So, in fact, obfuscation is the only protection provided by garble itself, isn't it? Everything else is also available through the main golang compiler. And in this case, these projects allow to get readable string lists from compiled snippets of source code.

[luantak]

@chatonick garble removes a lot more information than just the string literals.

Normal go binaries even with debug symbols stripped contain almost the entire source structure for things like panic backtraces.

The runtime not being obfuscated helps people who try to reverse garble binaries immensely as it provides a kind of anchor to understand the flow of the program (hard to do, as the runtime depends on a lot of compiler magic). If we get to obfuscating the entire runtime extracting string literals and the like will get a lot harder, but it'll require patching the compiler which we avoided until now.

[chatonick]

garble removes a lot more information than just the string literals

I understand. Thank you to your team for the work done. But aren't all these additional flags for removing unnecessary information supported by the main compiler?

If we get to obfuscating the entire runtime extracting string literals and the like will get a lot harder, but it'll require patching the compiler which we avoided until now.

But it would be interesting to see. It may even be possible to do some semblance of symmetric or asymmetric cryptography, when we need to enter a password or secret key at the start of the program to continue it and decrypt runtime.