Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Android caveat #2

Open
ChrisMcMStone opened this issue Dec 12, 2023 · 1 comment
Open

Android caveat #2

ChrisMcMStone opened this issue Dec 12, 2023 · 1 comment
Labels
question Further information is requested

Comments

@ChrisMcMStone
Copy link

Hello! Thank you for sharing this cool project.

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!

@vfsfitvnm vfsfitvnm added the question Further information is requested label Dec 13, 2023
@vfsfitvnm
Copy link
Owner

Hi 😄

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 😺

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

2 participants