Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[Android 17] Early observations: JIT thread pool crash on attach and JNI transition frame aborts

Abierto
  • ¿Algo no está bien?
#411 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
12/100
Tipo de issue
Error
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
android, java, javascript
Área
mobile, reverse-engineering

Línea de trabajo

The payload names no file in this repository; the crashes are in ART internals (art::jit::Jit::CreateThreadPool) and in the JNI transition check. Start by reproducing the Java.use hooks on android.webkit.WebView $init and android.os.Binder attachInterface on an API 37 device or emulator, then gather the tombstone. Done would mean a hook pattern that survives on API 37 with a stated cause, which needs Android runtime knowledge and a maintainer decision on scope.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Ran into a couple of quirks while testing Frida 17.21.0 on Android 17 (API 37, build CE2A.260420.019). Opening this up to share logs and reproduction details in case they're useful as A17 support gets fleshed out.

1. SIGSEGV in art::jit::Jit::CreateThreadPool during attach
  • Behavior: When attaching frida-server early during process launch, ART intermittently segfaults inside art::jit::Jit::CreateThreadPool.
  • Observations: Appears to be a race between ptrace attachment and JIT thread pool initialization. Disabling JIT before launching or attaching avoids the crash on our end: 
    adb shell setprop dalvik.vm.usejit false
    Not sure if there's a cleaner synchronization hook or if this is primarily visible on emulator timing, but wanted to mention it.
2. Runtime abort: JNI transition frame error
  • Behavior: Hooking native constructor stubs or Binder entrypoints causes ART to abort the process: 
    art E ... JNI transition frame error
  • Reproduction cases we saw:
    • Replacing $init on native classes:
      Java.use('android.webkit.WebView').$init.implementation = ...
    • Hooking Binder interface registration:
      Java.use('android.os.Binder').attachInterface.implementation = ...
  • Observations: Looks like A17 might have tightened up stack validation or frame accounting around native-to-managed transitions. Replacing these native stubs with JS trampolines seems to trigger that transition check.
  • Current workaround for us: Steered our scripts away from hooking $init and Binder.attachInterface directly on API 37, targeting higher-level callers or concrete factory methods instead.

Happy to pull more tombstones or test proposed patches if anyone is digging into A17 support.

Lenguaje dominante
JavaScript
Estrellas
413
Forks
174
Sin PR fusionados en 30 d

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de frida/frida-java-bridge

Todos los issues de frida/frida-java-bridge

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.