TIL you can't run executables from your app directory in Android SDK 30+, but you can just bump down to targeting ~28 and it works fine - due to selinux constraints on `untrusted_app`s
Conversation
Forgot to add this reference link;
developer.android.com/about/versions
"In addition, apps that target Android 10 cannot in-memory modify executable code from files which have been opened with dlopen(). This includes any shared object (.so) files with text relocations."
1
1
6
This will be interesting to see what protectors / packers due when backward compatible support for this goes away -- it will be significantly hardware for them to "unwind" their obfuscation/breakages
1
6
Replying to
It's still possible to do it for memory mapped from files (execmem) and it's still possible to map app data (app_data_file) as executable for now. Being able to map app data as executable should eventually go away but it's hard to see them being able to drop execmem due to ART.
1
If they hadn't taken the path of going back towards JIT compilation, they could permit execmem only in the isolatedProcess sandbox to allow browsers, etc. to work while not permitting it for processes in the normal app sandbox.
1
1
Replying to
Right, it looks like this is where it's headed, they're just trying to be "kind" potentially?
Language in the Play Store TOS basically says f' off to executing anything not in your apk, us I imagine some day (in the distant future) it will all break "without warning" 🙃
1
Replying to
It's because it's not disallowed by the policy to extract things from the apk and then execute from app data. It's just a bad practice. You're supposed to bundle native libraries and executables so that they get extracted by the package manager and the app can't write to them.
1
They end up as apk_data_file rather than app_data_file when the package manager handles it. There's also a more modern way of doing libraries where they're just stored and aligned in the apk so that they can be mapped directly from it instead of decompressed / extracted.
A lot of apps extract their native libraries to app data and load them from there. Not that many apps used native executables at all, so it was easier for them to force developers to bundle those properly first. Also, a lot more of those are first party and easier to cope with.
1
If they followed through on it completely, forbidding dynamic native code execution completely for the main app sandbox is totally doable. I just can't see how they get to that point due to wanting JIT for ART rather than just use cases covered by isolatedProcess.
1
1
Show replies