Yes! That works!
Here is what Erel recommends if you use his tool.
"- Make sure to use a process global variable for the password. The string will be obfuscated."
In some documents about Android Security it states to use android:debuggable="false" in the application manifest.
For instance, I know someone who likes to take this stuff apart.
He is not a Java developer so he does not know Java but if I make an app, he may try to take it apart.
Will Erel's solution make it hard enough for some apk hackers to give up?
Do that and I will have three solutions to retrieve the unencrypted assets easily:
- I run the APK on a rooted phone. I wait until the app decrypt the assets then I get the files in the internal folder. All text files are now readable. Erel warns about this weakness in the Secured Assets page.
- I add a few instructions in your code with a smali editor to know the contents of the password string. The obfuscation is removed at runtime when the string has to be used, so I have two possibilites: either I log the content once the obfuscation is removed, or I call the function embedded in your code that removes this obfuscation.
- I add a few instructions in your code with a smali editor to copy all assets in an external folder after their decryption (after the call to UnpackEncryptedAssets).
In brief, protection level: 1/5. Not zero, and a lot better than nothing, but very weak.
I did not mention the solution with a debugger (changing the setting in the Manifest from debuggable="false" to debuggable="true" is not difficult).
To strengthen this protection, you should keep the sensitive data in memory after their decryption and protect the app against changes. I focus on that in ProBundle.
