Closed mhils closed 2 years ago
Hi. Thank you for your interest in frida-apk
.
This is a very interesting observation. I am not sure why the ordering seems to matter here, I would think that attributes could be parsed regardless of order and still add the FLAG_DEBUGGABLE
to the process.
Curiously, the attrs_manifest.xml
file which is used to define the "schema" for attributes declares the debuggable
attribute after the name, theme, etc. as well: https://cs.android.com/android/platform/superproject/+/master:frameworks/base/core/res/res/values/attrs_manifest.xml;l=1716?q=attrs_manifest and it appears to follow the same order. Unsure if this is a coincidence.
Regardless, I am in the process of developing a frida-core API called Frida.AXML
: https://github.com/frida/frida-core/blob/main/src/droidy/axml.vala. The purpose of this module is to en/decode AXML files thus allowing you to create AXML files from scratch, or modify existing ones. The plan is also to expose this API to Python.
Once this module is complete, I will rewrite frida-apk to use the new frida-core API to modify AXML files, thus cleaning up the code considerably and allowing for more flexibility such as reordering attributes with ease. Further, other out-of-tree Python scripts that use frida-core could also develop their own transformations.
I am not sure why the ordering seems to matter here, I would think that attributes could be parsed regardless of order and still add the FLAG_DEBUGGABLE to the process.
Right. After experimenting a bit longer, I have found that attributes need to be sorted by their resource ids for my stock Pixel phone to pick them up properly (Android 12). I've spend a lot of time reading through ResourceTypes.cpp
to find the relevant, code but everything there seems to just iterate through the list... I'm a bit at a loss why/where it's happening, but it's definitely something I'm seeing on my device here. 🤷
After lots of trial and error I got things to work today - #97 has the necessary changes.
Regardless, I am in the process of developing a frida-core API called Frida.AXML
Very nice. You've probably seen the kaitai definition I've posted above, but that only handles decoding. And I guess you are aware of https://justanapplication.wordpress.com/category/android/android-binary-xml/ already as well. :-)
I tried to use the very cool
frida-apk
tool with a simple pinning demo app, but for some reason the APK did not end up as debuggable on my Pixel 3. This led me down a terrible rabbit hole into binary XML. To cut a long story short, I have discovered that I can "fix" the generated APK by moving the debuggable attribute to an earlier position in the same tag. I'm not sure why this makes things work, but maybe someone has any ideas.Here's a minimal repro script that creates two variants of a demo apk. Variant A exhibits the same behavior as if I'm just running
frida-apk
, variant B is "fixed" by reordering the attributes (see patch below).Some more notes:
apktool d
followed byapktool build
. For some reasons this also reorders the attributes, I haven't figured out yet why that is the case .debuggable
string is inserted after the padding in the StringPool Chunk, but that shouldn't cause any issues. I fixed it manually once, which didn't change the overall outcome. Also, the issue persists after doing a roundtrip through xml2axml.