CVE-2026-43499 en Amazon Fire TV Stick 3rd Gen (sheldonp)

Encadenando una escalada de privilegios del kernel de Linux con un downgrade del preloader y el desbloqueo del bootloader.

Descripción general

Este repositorio documenta mi reproducción autorizada de la cadena de explotación de CVE-2026-43499 en un Amazon Fire TV Stick 3rd Gen (sheldonp). La cadena utilizó root temporal a nivel de kernel para ejecutar un downgrade controlado del preloader, y luego usó el flujo de trabajo existente de Kamakiri BootROM para alcanzar el fastboot desbloqueado y completar el desbloqueo del bootloader.

Esta es una reproducción y un estudio de caso específico del dispositivo. No descubrí CVE-2026-43499, no creé el exploit original IonStack/GhostLock, ni desarrollé Kamakiri. Los investigadores y desarrolladores originales se acreditan a continuación.

[!IMPORTANT] Este artículo es un registro técnico, no una guía universal de rooteo. La compatibilidad de compilación importa, el root temporal no es root persistente, y los errores que involucran Preloader, LK, TEE o particiones protegidas por dm-verity pueden brickear el dispositivo de forma permanente.

Registro de reproducción

La cadena de extremo a extremo se completó el 12 de septiembre de 2026. Este repositorio registra el dispositivo y las versiones de software probadas, los archivos exactos utilizados, sus hashes SHA-256 y la evidencia original capturada durante el proceso.

Alcance

Fuera de alcance: descubrimiento de vulnerabilidades, una nueva implementación de exploit, explotación remota, root persistente o soporte para dispositivos distintos de la unidad sheldonp probada. No se instaló ninguna ROM personalizada durante esta reproducción.

Archivos de reproducción

Los siguientes son los archivos ZIP exactos utilizados durante esta reproducción. Los archivos no se redistribuyen en este repositorio; sus hashes SHA-256 se registran para que las copias obtenidas de forma independiente puedan compararse con los archivos utilizados en este estudio de caso.

Estos hashes identifican las copias utilizadas en este estudio de caso; los lectores deben comparar sus descargas con las fuentes originales y revisar las licencias de terceros aplicables.

Antecedentes técnicos

CVE-2026-43499, también conocido como GhostLock, es un use-after-free en la ruta futex/rtmutex de herencia de prioridad del kernel de Linux. Durante el rollback del proxy-lock, remove_waiter() operaba sobre current en lugar de la tarea almacenada en waiter->task. Como resultado, el waiter real podía regresar al espacio de usuario con pi_blocked_on aún referenciando un rt_mutex_waiter en un frame de pila del kernel ya liberado.

La investigación original de IonStack convierte esa referencia de pila colgante en una primitiva de escalada de privilegios local. R0rt1z2 adaptó la técnica al Fire TV Stick 3rd Gen y Fire TV Stick Lite (sheldonp/sheldon) ejecutando Fire OS 7 sobre un kernel 4.4.

La distinción clave en este estudio de caso es que CVE-2026-43499 no desbloquea el bootloader directamente. Proporciona acceso temporal a nivel de kernel. Ese acceso de corta duración hace posible realizar el downgrade controlado del preloader requerido antes de que pueda ejecutarse la cadena más antigua de Kamakiri BootROM.

Cadena de explotación

flowchart LR
    A[Fire OS 7 on sheldonp] --> B[CVE-2026-43499 / GhostLock]
    B --> C[Temporary root shell]
    C --> D[Controlled preloader downgrade]
    D --> E[Expected non-booting transition state]
    E --> F[Kamakiri BootROM stage]
    F --> G[Unlocked fastboot]
    G --> H[Bootloader unlocked]

La cadena cruza dos límites de seguridad separados:

1. Límite del kernel: un proceso local sin privilegios obtiene un contexto de root temporal a través de GhostLock.
2. Límite de la cadena de arranque: el root temporal prepara el dispositivo para una ruta de desbloqueo basada en BootROM conocida restaurando un preloader compatible.

Metodología

1. Establecer la línea base

Antes de modificar el dispositivo, identifiqué el nombre en clave del hardware y registré las versiones de Fire OS, build, bootloader y kernel a través de ADB.

adb devices -l
adb shell getprop ro.product.device
adb shell getprop ro.product.model
adb shell getprop ro.build.version.release
adb shell getprop ro.build.version.incremental
adb shell getprop ro.build.fingerprint
adb shell getprop ro.bootloader
adb shell uname -a
adb shell id

La línea base resultante fue sheldonp / AFTSSS, Fire OS PS7716.5666N, incremental 0036005356164, Android 9 y kernel 4.4.162+. El número de serie se omite deliberadamente.

2. Obtener root temporal con GhostLock

Conecté el Fire TV por USB con la depuración ADB habilitada y usé GhostLock 1.1.0, el paquete sheldon/sheldonp publicado con la guía de R0rt1z2 en XDA. El lanzador específico del dispositivo reinicia el Fire TV para comenzar desde un estado limpio, despliega el exploit y reintenta cuando es necesario.

La explotación exitosa crea un entorno de root temporal. Verifiqué el contexto de seguridad desde un shell ADB en lugar de tratar la finalización del script por sí sola como prueba:

adb shell
su
id

El contexto de root es efímero y se pierde al reiniciar. Ese comportamiento es importante: esta etapa es una primitiva habilitadora para el downgrade, no el mecanismo de persistencia final ni el desbloqueo del bootloader en sí.

La ejecución exitosa mostró uid=0, cambió SELinux a permisivo para el entorno temporal, montó el su temporal y deshabilitó los paquetes OTA de Fire OS gestionados por la herramienta.

El rastro completo de la explotación de GhostLock se conserva como evidencia de respaldo.

3. Hacer downgrade del preloader

Con root temporal disponible, usé el flujo de trabajo de downgrade dedicado del paquete en lugar de escribir manualmente las particiones del firmware. Esto restauró un preloader compatible con la ruta existente de Kamakiri.

Después del downgrade, el Fire TV dejó intencionalmente de arrancar en Fire OS. En este flujo de trabajo específico, ese estado de no arranque es el traspaso esperado entre la etapa del kernel en vivo y la etapa de USB BootROM. No debe confundirse con la prueba de que un flash fallido arbitrario sea recuperable.

[!CAUTION] Nunca borres el Preloader. No improvises escrituras en LK, TEE, Preloader, boot, recovery, system, vendor u otras particiones protegidas. Las guías originales advierten que el daño al firmware crítico puede causar un hard brick permanente porque puede que no quede disponible una ruta de recuperación funcional.

4. Ejecutar la cadena de Kamakiri BootROM

El flujo de trabajo de Kamakiri utilizado para este dispositivo estaba soportado y documentado para Linux. Por lo tanto, inicié una sesión de Ubuntu Live y realicé allí todo el flujo de trabajo de desbloqueo, incluida la etapa de bajo nivel de USB BootROM, sin instalar Ubuntu en el host. No probé esta etapa en Windows ni macOS.

Usando el paquete Kamakiri sheldon/sheldonp referenciado por la guía de desbloqueo, el proceso fue:

1. Preparar Python, PySerial, PyUSB, ADB, Fastboot y el entorno USB requerido por Kamakiri.
2. Iniciar bootrom-step.sh y conectar el Fire TV apagado por USB.
3. Permitir que la etapa BootROM se complete y transicione el dispositivo al entorno fastboot modificado.
4. Ejecutar fastboot-step.sh para finalizar el flujo de trabajo de desbloqueo.
5. Reiniciar y verificar que la ruta de arranque desbloqueada esperada estuviera disponible.

Kamakiri detectó la unidad como sheldonp, completó el downgrade de RPMB, flasheó los componentes TZ/LK requeridos por la cadena, inyectó el microloader y forzó el dispositivo a su modo fastboot hackeado.

Los hashes de los archivos y la versión de Ubuntu se registran arriba. Los lectores deben usar las guías originales enlazadas para instrucciones específicas de versión en lugar de asumir que estos pasos de alto nivel se aplican a otra compilación.

5. Validar el resultado

Traté los siguientes como hitos separados y capturé evidencia para cada uno:

6. Preservar Fire OS y ajustar el estado posterior al desbloqueo

Mi objetivo era conservar el Fire OS de fábrica en lugar de instalar una ROM personalizada de inmediato. En TWRP evité borrar datos o reemplazar el sistema operativo, y luego reinicié en la instalación existente de Fire OS. TWRP y la ruta de arranque desbloqueada permanecieron disponibles mientras se preservaba el entorno de usuario de fábrica.

Después de regresar a Fire OS, mantuve las actualizaciones OTA deshabilitadas para que Amazon no pudiera mover silenciosamente el dispositivo a una compilación que cambiara el exploit o modificara la cadena de arranque recuperada. También deshabilité el componente de protección de aplicaciones del sistema de Amazon comúnmente referido en las herramientas de la comunidad de Fire TV como ARCUS. Esto cambia el comportamiento de bloqueo de aplicaciones a nivel de SO de Amazon; no elude Widevine, las verificaciones de suscripción ni la aplicación de licencias implementada dentro de aplicaciones individuales.

Próximos pasos opcionales

Un bootloader desbloqueado y TWRP también hacen posible instalar software personalizado compatible. Una opción de la comunidad para esta familia de dispositivos es LineageOS 20 basado en Android 13. También pueden ser posibles otras ROMs compatibles, flujos de trabajo de recuperación o configuraciones de root persistente.

Esas alternativas no formaron parte de esta reproducción. Deben tratarse como procedimientos separados con sus propias consideraciones de firmware, TZ, borrado de datos, DRM, memoria y recuperación.

Observaciones

• Una conexión ADB por USB con cable es preferible porque los reintentos del exploit pueden reiniciar el objetivo e interrumpir el ADB inalámbrico.
• La fiabilidad del exploit depende del objetivo y de la compilación. Un reintento o reinicio no es evidencia de que un dispositivo no sea compatible, pero los offsets y la compatibilidad de compilación aún deben verificarse.
• La etapa de root temporal y la etapa de Kamakiri resuelven problemas diferentes y deben documentarse de forma independiente.
• El estado esperado de no arranque posterior al downgrade solo tiene sentido cuando la herramienta de downgrade reporta éxito y se sigue el flujo de trabajo exacto soportado.
• Una salida exitosa del script es evidencia más débil que el estado capturado del dispositivo, la identidad de root y la verificación de fastboot/recovery.
• Desbloquear el bootloader no requirió reemplazar Fire OS; mantener el Fire OS de fábrica fue una elección deliberada posterior al desbloqueo.
• Deshabilitar ARCUS afecta la capa de bloqueo de aplicaciones de Amazon, mientras que el DRM de las aplicaciones y las licencias de contenido siguen siendo cuestiones separadas.

Impacto de seguridad

En una compilación de Fire OS vulnerable y soportada, el código que ya se ejecuta localmente en el dispositivo puede explotar la falla del kernel para obtener un contexto de root temporal. En este laboratorio, ese acceso amplió la superficie de ataque más allá del sistema operativo en ejecución: habilitó un downgrade de firmware que reintrodujo una condición de la cadena de arranque utilizable por un exploit de BootROM más antiguo.

Esta cadena ilustra por qué la seguridad de un dispositivo depende de más que parchear una sola capa. Una escalada de privilegios del kernel puede convertirse en un puente hacia persistencia de bajo nivel o compromiso de la cadena de arranque cuando el software privilegiado puede modificar el estado del firmware crítico para la seguridad.

Estructura del repositorio

.
├── README.md              # Case study and methodology
├── LICENSE                # CC BY 4.0 for original documentation and media
├── images/
│   ├── README.md          # Evidence index and redaction guidance
│   └── evidence/          # Sanitized screenshots and photographs
└── references/
    └── README.md          # Source ledger and artifact guidance

Este repositorio no redistribuye los archivos ZIP de terceros. Obténlos de las guías originales de XDA, revisa sus términos aplicables y compara sus hashes con los valores registrados arriba.

Créditos

• NebuSec / CyberMeowfia — descubrimiento e investigación original de IonStack/GhostLock e implementación del exploit para CVE-2026-43499.
• R0rt1z2 — adaptación a Fire OS, la rama 4.4 de GhostLock y la guía de root temporal y downgrade para sheldon/sheldonp.
• IonStackQuest3 — primer port público de GhostLock para kernels Linux 5.10, acreditado por el proyecto downstream de Fire OS.
• Colaboradores de Amonet/Kamakiri, incluidos xyz, k4y0z, Rortiz2, t0x1cSH y los testers acreditados en el hilo original de desbloqueo — trabajo de BootROM, fastboot, recuperación y desbloqueo específico del dispositivo.

Mi contribución es la reproducción independiente, el registro de ejecución específico del dispositivo, el análisis de cómo se conectan las etapas y la evidencia original publicada en este repositorio.

Referencias

El registro de fuentes mantenido está en references/README.md. Las fuentes principales incluyen:

• Registro de CVE-2026-43499
• NebuSec: entrada de vulnerabilidad GhostLock
• NebuSec: IonStack Parte III — explotación en Android
• CyberMeowfia: código fuente de IonStack/CVE-2026-43499
• R0rt1z2/GhostLock, rama 4.4
• XDA: root temporal y downgrade del preloader para sheldon/sheldonp
• Código fuente de Amonet/Kamakiri
• XDA: guía de desbloqueo del bootloader, TWRP y unbrick para sheldon/sheldonp
• Corrección del kernel de Linux para remove_waiter()

Aviso de uso responsable

Este material se proporciona para uso educativo e investigación de seguridad autorizada en hardware que posees o que estás explícitamente autorizado a probar. Se ofrece sin garantía. Eres responsable del cumplimiento legal, la pérdida de datos, la interrupción del servicio y el daño al hardware resultante de tus acciones.

Licencia

El texto e imágenes originales creados para este repositorio están licenciados bajo la Creative Commons Attribution 4.0 International License.

Las herramientas de terceros, el código de exploit, el firmware, las citas, las capturas de pantalla, las marcas registradas y los materiales referenciados siguen sujetos a su respectiva autoría y licencias. La inclusión de un enlace o crédito no relicencia ese material bajo CC BY 4.0.