I'm reverse-engineering an Android app.
Problem is, I don't have much experience with Android internals, all my rev-eng skills being related to x86 practice.
The APK of the app comes with two native libraries inside (lib...so), the more interesting one of the two is encrypted (no ELF header, no GCC signatures etc).
Hoping it will be decrypted when the app is in use, I installed it on a rooted tablet only to find that /data/app-lib/com.[appname]/lib[something].so is also encrypted (.so file is identical to that inside the APK) there, even when the app is being actively used!
I surmise there has to be some sort of transparent decryption when this native library is being loaded by the app.
Is it some kind of built-in feature of JNI? If not, how that could have been achieved? And how to catch the app in the middle of loading this library, since I uderstand the ld-linux must see a normal ELF-style library anyway else it fails.
The lib[something].so trick is old and easy. This is a way to unpack any BLOB from your APK into a read-only file at install time. It may be some non-executable data (encrypted or not).
On the other hand, I would not exclude the possibility that the file is really an encrypted library. Some custom decryption mechanism will then read it and write the output elsewhere. The decrypted library can be System.loaded (from Java), or dlopened from any location on the filesystem, including the 'external storage'. Even the file name may have no traces of lib or .so.