add entryoff encryption

[pagran]

Added a simple encryption with a random key for funcInfo.entryoff, this completely breaks function info parsing since it breaks link _func->offset in binary

There is a problem that encrypted addresses look sequential:

Create function @ 0x4815c0 // invalid address
Create function @ 0x481880
Create function @ 0x481b40
Create function @ 0x481bc0
Create function @ 0x481f20
Create function @ 0x4824c0

If you know, please write how to encrypt (with a simple algorithm), to make a resulting number look more random

[mvdan]

If you know, please write how to encrypt (with a simple algorithm), to make a resulting number look more random

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 Func.Entry(), which would do the same per our changes. It's a bit like literal obfuscation, in that we're not removing information, we're just making it slightly harder to retrieve.

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.

[pagran]

Commit was more complex (because of nameOff field name changed between go versions), but addresses more random:

0x483e7978
0xc1c33fab
0x9728b172
0xb05a3a05
0x6c8e4d79
0xe3d9ce56
0x5b2532b3
0x17dae95
0x79e5cd9d
0x7d3bd49e
0x9789ca9c
0xdfc84574
0xf7dd343c
0x6e0c112e
0xcc261fb8
0x9f525e49
0xe790d141
0xd1b523ef
0xd50b0d50
0xee3c8623

[mvdan]

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]

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]

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 :)