Well, I mean, this is pretty similar to muslc's approach of randomizing memory offsets on bootup of the binary. Only that there's a lot of obfuscation added on top.
Another mechanism could be using go routines to modify memory and pointers/references to a slice that is held by the main process, because that would add another layer of noise. You could also make it so that only a magic value in that memory leads to successful API calls, and the other values will just throw errors down the line which are ignored/stubbed. That would make effectively debugging it impossible.
And, of course, to use garble to obfuscate symbols. Maybe the goal of a project like this could be an "unexploitable" binary?
Has anyone compiled and used go/compile with muslc?
Another mechanism could be using go routines to modify memory and pointers/references to a slice that is held by the main process, because that would add another layer of noise. You could also make it so that only a magic value in that memory leads to successful API calls, and the other values will just throw errors down the line which are ignored/stubbed. That would make effectively debugging it impossible.
And, of course, to use garble to obfuscate symbols. Maybe the goal of a project like this could be an "unexploitable" binary?
Has anyone compiled and used go/compile with muslc?