How to allow for unobfuscated literal to remain in strings of binary?

[An00bRektn]

Hi! I've spent way more time than I'm willing to admit trying to do something that seems very counterintuitive. I was working through this "Responsible Red Teaming" course, and one of the lessons was on imprinting your tooling in case of breaches/leaks. I tried recreating the example from the course in Golang, which you can find here.

Obviously, Golang doesn't support macros, so the only way to obfuscate literals is to use tools like this one. Problem: The tool is too good at what it does, and even putting the const in front of the imprint string, while it prevents it from being obfuscated, doesn't prevent it from being excluded from the binary because of the Golang compiler.

So my question is this: What is the best way to add a useless string to my compiled binary while also using garble? Is it possible? I'm fairly new to Golang so there's a lot I just don't know. I could theoretically replace garble with a XOR function on each literal, but I wanted my example to be a little more realistic, but I'm really struggling to find a good solution.

Additional Notes

• I can create useless logic such that garble build gives me a binary with the imprint string in the strings. However, it's only when garble -literals happens that the string stops showing up
• From my debugging, I found that garble ends up taking a copy of the value in the const and uses that throughout the obfuscated code, without interacting with the variable declared as const, which is why the variable gets excluded from the compile
• I'm open to alternative ways to embed a string in the binary while using garble, while I was writing this, I found the "embed" package, and I'll try to test it, but I thought I'd drop this here anyway.

[mvdan]

There's currently no way to turn off literal obfuscation for just one literal, as far as I can see in the code. Perhaps @lu4p can confirm. I don't think anyone has asked for it yet :)

You could use go:embed, and we currently do not obfuscate embedded bytes/strings at all. But we might in the future, so that might not be the best solution.

We do have a way to turn off obfuscating types, as you can see in the README, because that can affect or break reflection in programs. Perhaps we should also have a way to turn off literal obfuscation, for example via comment directives. I can imagine that it might also matter for performance in some hot paths, which is hard for us to predict unless we rely on something like PGO.

[capnspacehook]

I think for now using hints to prevent garble from obfuscating certain types is sufficient. The way Sliver tackles this problem is creating a type specifically for unobfuscated strings, like so: https://github.com/BishopFox/sliver/blob/master/implant/sliver/constants/constants.go#L28-L34

[An00bRektn]

Thanks! Used go:embed and that worked out.

[mvdan]

@capnspacehook sneaky :) I guess you could do that without a struct as well, e.g.

type plainString string

var _ = reflect.TypeOf(plainString)

Or the same with []byte.