Rootear una Fire HD 10 con IA: cómo 4 modelos lo hicieron posible

Un usuario sin experiencia en exploits usó tres IAs para rootear una Fire HD 10 de Amazon

Eric Pardee llevaba cinco años usando una Fire HD 10 comprada en 2021 por 114 dólares como panel domótico con Home Assistant, hasta que descubrió que varios servicios protegidos de Amazon podían reiniciar o apagar el dispositivo y él no tenía forma de deshabilitarlos sin acceso root. No existía un método público para rootear esa tableta, y en lugar de esperar a que alguien lo publicara, decidió preguntarle a la IA. La sesión completa, repartida entre cuatro modelos, terminó costándole 266,15 dólares y acabando con un exploit funcional: el modelo GLM-5.3 de Z.ai desactivó SELinux sobre el dispositivo y le devolvió el control. Al terminar, Pardee eliminó alrededor de un centenar de paquetes de Amazon, incluidos los que gestionaban las funciones que le molestaban (Xataka, 25 de agosto de 2026).

¿Qué hizo cada modelo en la cadena?

Pardee no programó el exploit. Lo que hizo fue dirigir la conversación, insistir cuando un modelo fallaba y pedirle a uno que revisara el trabajo del anterior. Él mismo se definió como un prompt kiddie: alguien que sabe orquestar IAs más rápido de lo que sabe escribir el código que esas IAs producen.

Kimi K3 (Moonshot AI) arrancó la investigación a mediados de agosto dentro de OpenCode, una herramienta abierta para trabajar con distintos modelos vía API. Localizó que la CVE-2022-38181 ya estaba parcheada en Fire OS 7.3.2.9, pero la unidad de Pardee nunca había actualizado, así que la vía seguía abierta. Tras unas 30 horas de trabajo generó un primer conjunto de herramientas. Después de más de 500 intentos fallidos por aplicar el método, el propio Kimi se quedó atascado. Coste de esta fase: 164,25 dólares (Xataka).
Fable 5 (Anthropic) rechazó la petición por sus salvaguardas de ciberseguridad, sin avanzar.
Claude 4.8 (Anthropic) sí aceptó, ayudó a inspeccionar el sistema y a mapear vectores de ataque sobre el kernel. Llegó un punto en el que también se negó a seguir.
GLM-5.3 (Z.ai) retomó la sesión partiendo de un documento Markdown que el propio Kimi había dejado escrito para el siguiente modelo. Empezó a trabajar a las 08:26 del 16 de agosto y, esa misma tarde, desactivó SELinux y logró el root. El modelo cerró la conversación con una frase que resume la historia: «Tú eres el propietario del dispositivo».

Lo más relevante no es el exploit en sí, sino la dinámica: un modeloinvestigó el kernel y abrió una vía, otro modelo revisó ese trabajo y encontró errores, y un tercero depuró el conjunto hasta hacerlo funcionar. Pardee actuó como integrador.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Por qué los modelos se encadenaron tan bien (y por qué importa)

Tres cosas hacen que esta cadena sea interesante más allá de lo anecdótico.

Primero, la división de roles cayó por sí sola. Kimi K3 se especializa en tareas largas de ingeniería de software y razonamiento profundo: Moonshot AI lanzó Kimi K3 como un modelo de 2,8 billones de parámetros enfocado precisamente a software engineering, knowledge work, deep research y comprensión multimodal, con ventana de contexto de un millón de tokens (Global Times, julio de 2026). Por eso es razonable que haya sido quien primero mapeó el terreno y dejó un documento estructurado. GLM-5.3, en cambio, fue entrenado con énfasis explícito en ciberseguridad: Z.ai reporta un 84,5 % en CyberGym, por encima del 83,8 % de Mythos 5 de Anthropic y del 83,6 % de GPT-5.6 Sol de OpenAI (Developer Tech, agosto de 2026). En ExploitGym, GLM-5.3 resolvió 105 tareas en dos horas y 130 en seis, frente a 29 y 39 de GLM-5.2 en las mismas ventanas. La mejora sobre su versión anterior fue del 233 % en ese benchmark.

Segundo, hay un cuello de botella operativo que cualquier founder debería tener en el radar. Tras el lanzamiento de Kimi K3, Moonshot tuvo que suspender nuevas suscripciones de pago porque la demanda estaba empujando sus GPUs al límite. La compañía, que en mayo había cerrado una ronda de más de 2.000 millones de dólares liderada por Meituan, China Mobile y CPE y que en junio se valoraba en torno a 30.000 millones, ya estaba preparando su salida a bolsa en Hong Kong con Goldman Sachs y CICC (IBTimes, julio de 2026). Si vas a depender de uno de estos modelos en producción, conviene recordar que el proveedor puede rarte el grifo en cualquier momento.

Tercero, las IAs cometen errores que otras IAs pueden cazar. En el caso de Pardee, Kimi K3 diseñó un método que no funcionaba; fue la siguiente IA la que tuvo que detectarlo. En seguridad ofensiva eso ya se explota a escala: según Z.ai, su Security Disclosure Ledger documenta 2.436 vulnerabilidades en 269 proyectos, con 1.097 hallazgos críticos o de severidad alta. La más antigua llevaba 26,6 años en el código sin ser descubierta (Developer Tech). Esto encaja con un patrón que ya se vio este año: el cuello de botella en ciberseguridad con IA pasó de descubrir a parchar.

¿Qué significa esto para tu startup?

La lección operativa no es «pídele a ChatGPT que te haga un exploit». La lección es que el trabajo técnico complejo se está descomponiendo en piezas que una IA diferente puede resolver mejor, y eso cambia cómo se presupuestan proyectos internos.

Acción concreta 1 — Diseña tus flujos críticos como cadenas de modelos, no como consultas únicas. Si necesitas una revisión de código, una auditoría de seguridad o un análisis de causa raíz, no asumas que un solo modelo te dará la mejor respuesta. Pardee tardó cuatro intentos; cada uno avanzó porque el anterior dejó algo documentado. En tu pipeline: un modelo investiga, otro audita, un tercero sintetiza. Para fundadores hispanohablantes que operan con presupuestos ajustados, Kimi K3 y GLM-5.3 ofrecen capacidades comparables a las del ecosistema cerrado a una fracción del coste — y son modelos open-source, así que no dependes de que un proveedor mantenga su suscripción abierta.

Acción concreta 2 — Documenta cada sesión como si fuera a leerla otra IA. El detalle que desbloqueó el proyecto fue que Pardee le pidió a Kimi K3 escribir un documento Markdown con todo el proceso antes de cambiar de modelo. Esa es la práctica que escale: si trabajas con agentes para tareas largas (debugging de un sistema embebido, configuración de una infra cloud, modelado financiero), termina cada sesión con un handoff en Markdown que el siguiente modelo pueda retomar sin reinventar el contexto. Es la diferencia entre un prompt aislado y un proyecto realmente orquestado.

Acción concreta 3 — Presupuesta contingencia de proveedor. Si tu producto depende de la API de un modelo, asume que el proveedor puede suspender altas, deprecar el endpoint o cambiar el formato de configuración sin avisar con mucha antelación. Z.ai ya advirtió que migrar a GLM-5.3 requiere cambiar thinking.type de "disabled" a "enabled" y seleccionar reasoning_effort: las llamadas que solo actualicen el model_id fallarán (Developer Tech). Diseña tus integraciones con un adapter layer que puedas actualizar en minutos, no en sprints.

El debate que la historia deja abierto

El cierre de la sesión — «Tú eres el propietario del dispositivo» — apunta a un debate que la industria intenta mantener enterrado. Durante años, rootear un dispositivo exigía conocimientos avanzados de kernel, ingeniería inversa y exploits de bajo nivel. Pardee tenía experiencia técnica, pero explícitamente reconoce que no llegaba a tanto: lo que cambió fue que la IA completó su capacidad para proporcionarle ese experto virtual que solo necesitaba las directrices correctas. La pregunta para founders, reguladores y para cualquiera que fabrique hardware ya no es si un usuario podrá tomar el control total de un dispositivo que compró, sino qué nivel de soporte y responsabilidad está dispuesta a ofrecer la industria cuando ocurra.