|
|
|
|
|
by cookiengineer
794 days ago
|
|
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? |
|