Conversation
In Slack I was suggesting to xor with a sequence of math/rand numbers using garble's deterministic random number as seed. That would work for the linker, but not for the runtime, as I understand that the runtime needs to apply the xor again for any one function independently. What you're doing here is cheap for the runtime (one xor per call), but it's also fairly easy to deobfuscate - a tool just has to pull the xor number from the runtime and apply it to each func pointer. Or call We could consider more complex logic, but I also want to be careful about slowing down these runtime methods considerably. This stuff is what powers APIs like https://pkg.go.dev/runtime#Callers, and we don't want to make those operations significantly slower. |
b7cce1b to
54b7024
Compare
|
Commit was more complex (because of nameOff field name changed between go versions), but addresses more random: |
|
Please hold off on merging this until I've done a release, for the sake of not releasing too many new features at once. |
mvdan
left a comment
There was a problem hiding this comment.
SGTM - I assume this wouldn't really have a performance impact, given that you're just adding XOR and MUL integer operations per call.
mvdan
left a comment
There was a problem hiding this comment.
LGTM with that last bit of docs. Happy for you to merge as a single commit as long as you write a commit message summarizing the feature :)
Added a simple encryption with a random key for
funcInfo.entryoff, this completely breaks function info parsing since it breaks link_func->offset in binaryThere is a problem that encrypted addresses look sequential:
If you know, please write how to encrypt (with a simple algorithm), to make a resulting number look more random