android: Support ART w/o copied_methods_offset_ #378
Conversation
|
Just gave this a try, when running Frida the system_server crashes. |
|
I tried a quick gadget compile and it didn't work either but I can't be certain I did it right as I rushed through it before work. Just giving a second data point until I can try again later. |
|
Pixel 6a crashes on start of frida-server (like shows the Google loading splash and restarts the entire launcher). First time compiling from sources, so take it with a grain a salt. I smoke tested what was on Not sure how the bridge is typically included in the build process (looks like just an npm package). This feels wrong, so if someone wants to correct my build process, I'm happy to test again. |
Fairly close to what I do. If you're not getting I linked |
Sanity checked by following your process of symlink and explicit build+copy of |
|
@hoo-dles I don't have the code at hand, but the build process copies the javascript sources and package.json, and then runs npm install elsewhere. There is a python script that builds this system server. Under the npm install you can add a new line for npm link, that way it will always build with your package. |
hmmm, I tried |
You need to modify the python script I mentioned so that it runs npm link for you during the build process. |
|
@AeonLucid @hoo-dles @ExternalAddress4401 You can test with Frida's latest SELinux update by following these guide: |
|
I have tested it on the Pixel 6 Pro with Android 16 ROM version 16.0.0 (BP4A.251205.006, Dec 2025), and it is functional but lacks stability. However, using |
|
Used verdaccio just to remove another variable even though I already suspected the results would be the same. rooted Pixel 6a, Android 16 (BP3A.250905.014, Play Nov 1, 2025) Edit: Adding my crash log for posterity |
|
The crash seems to be the long-standing ART bug where it assumes there is a Java stack frame present on the art::Thread's stack. This bug is in the exception-handling code. The way we ensure that a class is initialized is by performing a dummy field lookup, expected to fail. However, since ART's exception handling has this broken assumption, it ends up crashing the process. The existing workaround no longer works, and either we have to update it, or find a way to make our Java.perform() / Java.performNow() call some Java method that calls us back, so our code interacting with the VM satisfies this assumption. |
This commit adds support for Android 16+ which has several breaking changes in ART internals: 1. Skip JVMTI loading on API 36+ - Loading the JVMTI plugin causes system instability on these Android versions. 2. Skip ensureClassInitialized GetFieldID trick on API 36+ - This crashes due to an ART bug in exception handling when there's no Java stack frame. 3. Handle missing copied_methods_offset_ field - Android 16 removed the copied_methods_offset_ field from the ART Class structure. We now return 0 to signal this and use the array length from the methods array header instead. 4. Force Java reflection path on API 36+ - The ART class/method structures have changed in ways that cause incorrect method modifier detection. Using Java reflection via Method.getModifiers() gives correct results. Fixes frida#378 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
|
Not sure if this is a valid approach, but I'm trying to force class initialization by calling edit: I assume a deadlock, but I'm out here at the edge of my knowledge concerning the JNI and ART |
|
On atleast Android 9 and 10, this PR breaks frida-java-bridge. import Java from "frida-java-bridge";
console.log("Agent loaded");
if (Java.available) {
Java.perform(() => {
send({
type: "status",
message: "Application class-loader now available"
});
});
} else {
console.log("No Java VM in this process");
}Output It's a bit difficult to find the error line due to the frida-compile output. |
My guess is it barfs at I would try throwing in a quick null-check or something there. |
No description provided.