You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm interested in understanding the following caveat you mention about Android:
When targeting an Android application, both library and second payload binary blob will be copied to its native library directory - changing the security context to u:object_r:apk_data_file:s0 is not enough for the library file.
Specifically, do you think copying the lib to the native library directory could cause problems in terms for breaking app integrity? Or if not, why exactly is this caveat a caveat? Thanks very much!
The text was updated successfully, but these errors were encountered:
The following are January 2022 findings of mine mixed to what I read online - I don't know the details and they might be outdated!
Loading the second payload into memory (a mmap syscall) so that it can be executed:
you just can't mmap a file from an arbitrary path as executable - you must change its security context to u:object_r:apk_data_file:s0 first.
Loading the target library (using dlopen):
certain regions of memory are allowed to dlopen certain paths only (due to linker namespaces); the second payload has no explicit namespace attached to it, hence it can only load libraries that lives in the app native library folder (and probably from somewhere else).
The quickest solution I could think of is simply copying the target library into the app library folder (e.g. /data/app/com.example.application/lib/arm64/), so that an anonymous region of memory can dlopen it.
The fun fact is that any file in the very same directory can also be mmapped as executable, so I also copy the second payload in there to avoid changing its security context.
I don't think it breaks the app integrity as it's a reversible operation - but yes - copying the target library overwrites any existing file with the same name - so make sure there is no clash between file names.
This is probably a workaround rather than a caveat, but I can already imagine it won't be feasible anymore in future Android versions. Moreover, an application could simply check for intruders in its native library directory 😺
Hello! Thank you for sharing this cool project.
I'm interested in understanding the following caveat you mention about Android:
Specifically, do you think copying the lib to the native library directory could cause problems in terms for breaking app integrity? Or if not, why exactly is this caveat a caveat? Thanks very much!
The text was updated successfully, but these errors were encountered: