Few enhancements to gadget injection into APK (patchapk)

[Phyks]

Hi,

Here are a few proposals for enhancements of the patchapk function, in line with #582:

-[x] Try to make the default value of flags and arguments clearer to the reader, through the --help interface. Everything enabled by default should now be explicitly stated as such.

• Inject libfrida-gadget.so by adding it in existing shared libraries if possible, and resort to Activity patching if this is not possible.
• Let user specify an alternative name of the Frida gadget library to help dodge (basic) anti-frida measures.
• Use a fuzzy matching of libraries folders inside an APK. If a user uses the base nomenclature from Frida (frida-gadget-xxx-arm64.so.xz => arm64) as provided architecture, it would now match a folder such as arm64-v8a inside the unpacked APK tree.
• Default to aapt2 for repacking. As far as I understand and experimented, aapt2 should work out of the box for most cases, while regular aapt would often fail on some resources. Is there a specific reason for keeping aapt as default?

Best,

[leonjza]

Sorry for the delay. Think there are a few things to think about. One major thing to add would be to add the ability to skip patching native libraries using a flag.

[leonjza]

Don't think this is used for anything.

[Phyks]

I'm using it below in inject_load_library for injecting the library with the correct architecture.

[leonjza]

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?

[Phyks]

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.

[Phyks]

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.

[IPMegladon]

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.

Sorry for the delay. Think there are a few things to think about. One major thing to add would be to add the ability to skip patching native libraries using a flag.

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

[Phyks]

Thanks for the review. However, I'm no longer using objection on a daily basis as I used to. I'm happy to make quick fixups to this MR if you think this is worth it, but let you decide what you want to do (close, pass it to someone else, etc.) if there is some significant dev time required (which I totally understand, I agree with all your points).