8000 Support for changes to AndroidManifest.xml · Issue #30 · ksg97031/frida-gadget · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Support for changes to AndroidManifest.xml #30

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

Open
gradyl16 opened this issue Mar 25, 2025 · 2 comments
Open

Support for changes to AndroidManifest.xml #30

gradyl16 opened this is 8000 sue Mar 25, 2025 · 2 comments

Comments

@gradyl16
Copy link

Motivation

Some applications don't ship with any native libraries. In this case, the android manifest will have a line something like:

<application android:extractNativeLibs="false" ...>

You may be able to patch the application properly in all other respects, but if this is retained, you will receive something like the following error on installation:

adb: failed to finalize session
Failure [INSTALL_FAILED_INVALID_APK: INSTALL_FAILED_INVALID_APK: Failed to extract native libraries, res=-2]

A simple fix would be to change the aforementioned flag to true. However, if you're having issues rebuilding resources, then you generally have to skip the resource decoding during compilation (i.e. with the --no-res flag). This requires one to manually decode the AndroidManifest.xml, make the change, reencode it, then recompile.

Request

I'm hoping you can include a feature (perhaps another cmd line flag) that allows a user of frida-gadget to specify either just a yes/no for whether they would like to modify this part of the manifest, or just one that automatically checks the value of this attribute and modifies it accordingly (since you need it set to true to install the patched application regardless).

@ksg97031
Copy link
Owner
ksg97031 commented Mar 25, 2025

Hi @gradyl16,

If I don’t use the --no-res option, the manifest seems to be modified automatically.
Is it not working properly even though that option wasn’t set?

Also, I was unable to find a way to decode and re-encode the AndroidManifest.xml when using the --no-res option — is there a method for this that I might be missing?

@gradyl16
Copy link
Author
gradyl16 commented Mar 25, 2025

I assume it works properly when not using the --no-res flag. The trouble occurs when apktool has trouble rebuilding resources during the recompilation phase (e.g. exceptions being thrown). In this case, the only feasible solution I've found is to use the --no-res flag. However, since apktool is ignoring resources, the manifest is also ignored and thus not changed.

I haven't found any tools that can reliably retain the original encoding of the manifest file after manipulation. There are tools to decode/reencode the manifest like xml2axml. However, I've noticed that after reencoding the manifest and recompiling the apk that the installation fails due to some sort of alignment error:

adb install-multiple base-aligned-debugSigned.apk config.arm64_v8a-aligned-debugSigned.apk bundledtree-aligned-debugSigned.apk
adb: failed to finalize session
Failure [INSTALL_PARSE_FAILED_UNEXPECTED_EXCEPTION: Failed parse during installPackageLI: Failed to read manifest from /data/app/vmdl7082
3031.tmp/base.apk: length=190; index=-1]

Perhaps this is an artifact of the particular tool I'm using, though. If we could find exactly which tool aapt uses to decode/reencode the XML files, then that would probably avoid this issue.


iBotPeaches/Apktool#2514
iBotPeaches/Apktool#3806

Looks like handling split APKs is a known issue for apktool. Hoping we can find a way to work with the raw manifest to avoid these issues.

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

No branches or pull requests

2 participants
0