Encryption support shall be needed for know root packages & su binary paths to avoid cyber security threats

[neethuravindran]

For the below constants, It would be better to keep the encrypted file path strings in the string array **1. knownRootAppsPackages

2. knownDangerousAppsPackages
3. knownRootCloakingPackages
4. suPaths
5. pathsThatShouldNotBeWrtiable** So that we can avoid chances for changing the file path names and breaking the root detection checking by hackers Use decrypted strings where ever using this file path.

[stealthcopter]

I like this idea. Here's my current thoughts about how it should be implemented:

1. Keep the code readable
2. Encryption / encoding doesn't need to be secure as it's always going to be possible to reverse it.

So we could do something simple like base64 encoding, but also putting all the decoded values in a comment above to keep readability the same. As the comments will be dropped during compilation a simple string search will not longer work.

/*
The following array stores the following package names in base64:

            "com.noshufou.android.su",
            "com.noshufou.android.su.elite",
            "eu.chainfire.supersu",
            "com.koushikdutta.superuser",
            "com.thirdparty.superuser",
            "com.yellowes.su",
            "com.topjohnwu.magisk"
*/
    public static final String[] knownRootAppsPackages = {
            "Y29tLm5vc2h1Zm91LmFuZHJvaWQuc3U=",
            "Y29tLm5vc2h1Zm91LmFuZHJvaWQuc3UuZWxpdGU=",
            "ZXUuY2hhaW5maXJlLnN1cGVyc3U=",
            "Y29tLmtvdXNoaWtkdXR0YS5zdXBlcnVzZXI=",
            "Y29tLnRoaXJkcGFydHkuc3VwZXJ1c2Vy",
            "Y29tLnllbGxvd2VzLnN1",
            "Y29tLnRvcGpvaG53dS5tYWdpc2s="
    };

[WuglyakBolgoink]

Hallo @stealthcopter

yes, but base64 is too simple )

1. For example, on cordova-projects I can create hook, which do replacing directly in java class before we compile code... and user can define some salt-hash.
2. Maybe a better way too - move this constants in properties.. and do step 1 again.

for example encrypt original strings with AES256(str, salt), where salt is external hash. This make hard to find a pre-defined strings or base64(str)-strings...

what you think?

[stealthcopter]

@WuglyakBolgoink yeah, I like the idea of it not being static. I'm not aware of a good way of doing this in java/android/gradle. We also have the issue that if it's a compile time thing that all current build processes are supported as we don't want to break anything using our library. We welcome PR and contributions, so if you have time and want to have a look into it please do!

I could see it working with an encrypted properties file that we generate each release (and chuck the corresponding keys into a java class), however that's seems like it could be prone to breaking from updates.