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

frida-apk: Add support for ResourceMap, ordered inserts #97

Merged
merged 2 commits into from
Mar 26, 2022

Conversation

mhils
Copy link
Contributor

@mhils mhils commented Mar 6, 2022

This PR makes frida-apk work with my Android 12 Pixel 3 device (stock ROM, no root).

See the 9285b27 commit message for a detailed explanation of the changes. I've taken the liberty to build this on top of #95, which hopefully should be uncontroversial.

FWIW I've built a small tool around this for certificate pinning (https://github.com/mitmproxy/android-unpinner). If you folks feel that the JDWP stuff is useful, please feel free to shamelessly copy it.

This commit is the result of an investigation into why `frida-apk`
failed on a stock Pixel 3 with Android 12. Much of the explanation
assumes knowledge of the Android Binary XML format, which to a large
extent is documented at
https://justanapplication.wordpress.com/category/android/android-binary-xml/.

First, in order to recognize an app to be debuggable, its resource ID
needs to be specified in the resource map chunk. While `ResourceTypes.h`
claims that the resource map chunk would be optional, that's not the
case for manifests in practice. This means we first look out for the
matching chunk, and pad it to insert the debuggable resource ID (string
pool and resource map share the same indices).

Second, for some reasons the implementation on my test device expects
tag attributes to be sorted by their resource ID. It's not really clear
why this is the case and I have not managed to turn up any sources that
indicate such processing, but moving `debuggable` to the front of the
attribute list fixes the behavior. However, that then breaks all
attributes with lower resource IDs listed afterwards, so we actually
need to traverse the attribute list to figure out where we need to
insert.

Fixes frida#96.
@oleavr oleavr merged commit aa10bb8 into frida:main Mar 26, 2022
@oleavr
Copy link
Member

oleavr commented Mar 26, 2022

Thanks, this is awesome! 😍

FWIW I've built a small tool around this for certificate pinning (https://github.com/mitmproxy/android-unpinner). If you folks feel that the JDWP stuff is useful, please feel free to shamelessly copy it.

Very cool! Re JDWP, Frida already has native support for gadget injection through JDWP. We haven't done a great job advertising it though, so it's a rather obscure feature even though it's already been around for a year. Basically if you use an Android Device to try to spawn() or attach() and Frida is unable to connect to a remote frida-server, it will attempt its non-rooted/jailed code-path. The gist of it happens in injector.vala, which uses jdwp.vala and droidy-client.vala for the heavy lifting. That said it currently assumes arm64, and given how few folks know about it it likely needs some love 😊

@mhils mhils deleted the frida-apk-re branch March 28, 2022 06:24
@mhils
Copy link
Contributor Author

mhils commented Mar 28, 2022

Very cool! Re JDWP, Frida already has native support for gadget injection through JDWP. We haven't done a great job advertising it though, so it's a rather obscure feature even though it's already been around for a year.

The more you know... 😅 This is awesome and needs more visiblity. I completely missed Frida's JDWP implementation when looking at this kind of stuff. Is there anything that stops frida from doing JDWP injection if I invoke frida -FU? I guess it requires a bit of plumbing (checking if the target PID is in the JDWP PID list), but having non-root debugging to just work would be really fantastic.

@oleavr
Copy link
Member

oleavr commented Mar 29, 2022

@mhils 😊 No we just have to wire it up here. Happy to guide you in case you're interested in taking a stab at it! (If so feel free to hit me up on Discord, Telegram, Twitter DM, or whichever is most convenient.)

@mhils
Copy link
Contributor Author

mhils commented Mar 30, 2022

Thanks @oleavr! I'm trying to solve the very same "very cool feature but not properly exposed/documented" problem for some mitmproxy parts at the moment, as much as I'd like to play around with Vala I'm afraid I won't find any cycles for this anytime soon. Thank you for the offer! 😊

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

Successfully merging this pull request may close these issues.

2 participants