feat: add support to custom random seed

[davidmartos96]

Hello!
I'm using the obfuscate feature from clean builds in CI/CD, but every build is generating different output, so checks that I have for unchanged autogenerated files are failing.

My proposed solution is to provide optionally a seed for the random number generator.

[techouse]

LGTM!

@petercinibulk @ThexXTURBOXx can you throw an eye on this pls?:)

[ThexXTURBOXx]

Just some documentation changes

[techouse]

Just some documentation changes

Good idea. I updated the PR.

[davidmartos96]

@ThexXTURBOXx What are the implications from not using .secure()?
In the end, isn't the "randomly generated list of numbers" contiguously in memory after obfuscation?
Does it really matter how the numbers were generated?

[ThexXTURBOXx]

Good idea. I updated the PR.

Thanks! :)

What are the implications from not using .secure()?
In the end, isn't the "randomly generated list of numbers" contiguously in memory after obfuscation?
Does it really matter how the numbers were generated?

Coming from a hardware security standpoint, yes, it does matter how they were generated.
A simple brute-force scenario could try to reproduce parts of the resulting binary using the same (P)RNG configuration that was used when generating the XOR key.
If that succeeds, one knows (1) the location of the key and hence (2) the key and the encrypted data next to it and thus (3) the decrypted data.
Yes, basic utilities like strings will still not be able to extract the data in a meaningful way, but the predictability makes searching for the data very easy with PRNGs (especially when the initial configuration is known).

One could always extract the decrypted data directly from memory, but that was not the point the obfuscation in the first place.
That is also what I initially pointed out when creating the PR - there are still rather "easy" ways to extract the data.
But by going this route of argumentation you will always end up with the conclusion that you should not include secret data in your app, but have it in some kind of cloud service, where it is securely stored and never able to leave it.
The obfuscation possibility is just to keep "script kiddies" away from trying to steal your secrets that you are too lazy to store securely elsewhere :)

[davidmartos96]

@ThexXTURBOXx Thank you for the detailed answer! Didn't think about brute forcing patterns in the binary.