Few enhancements to gadget injection into APK (patchapk) #586
Conversation
| @@ -211,6 +213,8 @@ def __init__(self, skip_cleanup: bool = False, skip_resources: bool = False, man | |||
| self.skip_resources = skip_resources | |||
| self.manifest = manifest | |||
|
|
|||
| self.architecture = None | |||
There was a problem hiding this comment.
Don't think this is used for anything.
There was a problem hiding this comment.
I'm using it below in inject_load_library for injecting the library with the correct architecture.
| for lib in existing_libs_in_apk: | ||
| libnative = lief.parse(os.path.join(libs_path, lib)) | ||
| libnative.add_library(self.libfridagadget_name) # Injection! | ||
| libnative.write(os.path.join(libs_path, lib)) |
There was a problem hiding this comment.
If I have this right, I think we are going to be injecting into every native library here? I'm not sure that is what we want :) Not sure what the right approach would be here to choose a target. Maybe random?
There was a problem hiding this comment.
Indeed, I don't have any idea for a better strategy so far, happy to take feedbacks and ideas.
I'm basically replicating method 1 from https://fadeevab.com/frida-gadget-injection-on-android-no-root-2-methods/. Problem is that bundled native library in the APK may not be loaded upon APK initialization (they could be dynamically loaded later on at runtime). Therefore, if we inject in a random library, we might inject in an unused library?
This is quite old but I remember having apps exhibiting this behavior.
From https://developer.android.com/studio/command-line/aapt2 > Prior to AAPT2, AAPT was the default version of Android Asset Packaging Tool and it has now been deprecated. Although AAPT2 should immediately work with older projects, this section describes some behavior changes that you should be aware of.
|
I should have reworked the various bits discussed. I'm waiting for your latest feedbacks on the remaining points to make a final pass on this MR to ensure everything is clean and mergeable. |
|
Given that many applications only load the so libraries later on or don't use them at all as you mention, I think it would be better to have this as a secondary mode of operation where you have to specify the library to inject to. Main reason being that it would negatively impact early-instrumentation as the library may only be loaded later on. This adds to what Leonza mentioned about having a flag to disable it, rather I think it should be set to actively specify to use it. That way you also don't inject into multiple .so libraries.
It might even be worth either adding a command to list the shared object files it can inject into, and/or to use a prompt where the user can select which one to inject into (using prompt_toolkit). Just a suggestion |
|
Thanks for the review. However, I'm no longer using |
Hi,
Here are a few proposals for enhancements of the
patchapkfunction, in line with #582:-[x] Try to make the default value of flags and arguments clearer to the reader, through the
--helpinterface. Everything enabled by default should now be explicitly stated as such.libfrida-gadget.soby adding it in existing shared libraries if possible, and resort to Activity patching if this is not possible.frida-gadget-xxx-arm64.so.xz=>arm64) as provided architecture, it would now match a folder such asarm64-v8ainside the unpacked APK tree.aapt2for repacking. As far as I understand and experimented,aapt2should work out of the box for most cases, while regularaaptwould often fail on some resources. Is there a specific reason for keepingaaptas default?Best,