860 votos a favor, 404 comentarios: la comunidad explota
En julio de 2026, se filtró una captura de pantalla de un comentario interno en el IssueTracker de Google. Un mantenedor principal del equipo de Google ADB escribió: “La conexión a localhost también ha demostrado ser una vía para que las aplicaciones escalen privilegios utilizando sockets ADB. ¿Por qué no limitamos el enlace únicamente a la interfaz inalámbrica wlan0?”
Esta discusión técnica, aparentemente inocua, obtuvo 860 votos a favor y 404 comentarios en Hacker News, desencadenando una de las controversias más intensas en la comunidad de desarrolladores de Android en casi una década. En el centro del debate se encuentra una pregunta inevitable: ¿se trata de una auténtica mejora de seguridad o de un pretexto para eliminar herramientas incómodas?
Una “puerta trasera” oculta en las opciones de desarrollador
ADB (Android Debug Bridge) apenas existe para el usuario común de Android: se encuentra escondido dentro de las “Opciones de desarrollador” en Ajustes, una sección que en sí misma es un huevo de pascua que requiere tocar siete veces seguidas el “Número de compilación” para aparecer.
Sin embargo, el poder de ADB es inmenso. Funciona como un canal de nivel de administración para el sistema operativo móvil: puede instalar y desinstalar aplicaciones, leer registros, inspeccionar archivos y simular pulsaciones de teclas o toques en pantalla. Los desarrolladores lo utilizan para depurar apps, mientras que los usuarios avanzados lo emplean para acceder a funciones que el sistema no ofrece de forma nativa.
Históricamente, ADB requería un cable USB conectado a un ordenador. Android 11 introdujo la depuración inalámbrica (Wireless Debugging), que permite la conexión por Wi-Fi tras vincular mediante un código QR. Ambos métodos requerían dos dispositivos: un teléfono y un ordenador.
Sin embargo, desarrolladores ingeniosos descubrieron una alternativa: ¿y si ejecuto un cliente ADB directamente en el teléfono y me conecto a mí mismo a través de 127.0.0.1 (localhost)?
Esta técnica pasó a conocerse como “ADB en el dispositivo” (On-Device ADB). Aunque nunca fue un uso diseñado originalmente por Google, dio lugar a todo un ecosistema de herramientas de código abierto.
Shizuku: un ecosistema imprevisto
El producto más emblemático nacido de ADB en el dispositivo es Shizuku (nombre que proviene de la palabra japonesa 雫, que significa gota).
La función de Shizuku se puede resumir en una sola frase: utiliza ADB en el dispositivo para obtener privilegios a nivel de sistema y permite que otras aplicaciones invoquen esos permisos sin necesidad de acceso root.
¿Suena aún abstracto? He aquí algunos ejemplos concretos:
- Canta: permite desinstalar el bloatware preinstalado por los fabricantes (como tiendas o monederos propios) sin necesidad de root.
- App Manager: permite consultar con detalle qué permisos utiliza realmente cada aplicación y a qué archivos accede.
- aShell: abre una ventana de terminal en el propio teléfono para ejecutar comandos ADB de forma nativa.
- ShizuCallRecorder: habilita la grabación de llamadas en teléfonos de regiones donde dicha función viene desactivada de fábrica. El propio autor, Kitsumed, la desarrolló para compensar su discapacidad auditiva en la vida cotidiana.
Cuando Rikka, creador de proyectos de código abierto para Android, lanzó Shizuku en 2019, probablemente no imaginó que se convertiría en una “infraestructura fundamental”. Hoy en día, Shizuku cuenta con más de un millón de instalaciones solo a través de Google Play, una cifra que se queda corta considerando el gran volumen de usuarios que la instalan directamente desde F-Droid o GitHub.
La cadena de ataque: exige acumular requisitos
La preocupación del mantenedor de Google ADB es que aplicaciones maliciosas puedan utilizar la conexión 127.0.0.1 de ADB en el dispositivo para escalar sus propios privilegios, saltándose así el aislamiento del sandbox de Android.
Ahora bien, ¿cuántos pasos necesita completar una aplicación maliciosa para llevar a cabo este ataque con éxito?
Analizando la publicación original de Kitsumed y las discusiones en los comentarios de HN, la secuencia real de ataque es la siguiente:
- El usuario debe ir manualmente a “Ajustes → Acerca del teléfono” y pulsar 7 veces en “Número de compilación” para activar las opciones de desarrollador.
- El usuario debe entrar manualmente en las opciones de desarrollador y activar la “Depuración por USB” para iniciar el demonio ADB.
- El usuario debe activar además la “Depuración inalámbrica” (Android 11+) o conectarse por USB a un ordenador para habilitar el modo TCP/IP.
- Cuando una aplicación maliciosa inicia la conexión, aparece un cuadro de diálogo en pantalla y el usuario debe pulsar explícitamente “Permitir”.
- Si se utiliza el modo de vinculación de depuración inalámbrica, el usuario también debe introducir manualmente un código de vinculación de 6 dígitos.
El comentario del usuario microtonal en HN fue el más apoyado: “Este vector de ataque requiere tener activadas tanto las opciones de desarrollador como la depuración remota ADB. Para el 99.9% de los usuarios, este no es un vector de ataque realista. El 0.1% restante sabe perfectamente lo que está haciendo.”
Otro usuario, crote, lo expresó de forma aún más directa: “Es prácticamente imposible que esto afecte a usuarios comunes; solo desarrolladores descuidados podrían caer. Y eso asumiendo que el escaneo de malware de Google Play falle por completo… Un momento, ¿acaso la razón para restringir la instalación externa no era que el escaneo de Play es excelente?”
Desde una perspectiva de ingeniería, CVE-2026-0073 fue efectivamente una vulnerabilidad real que eludía la autenticación en la depuración inalámbrica. Sin embargo, dicha vulnerabilidad ya ha sido corregida. La propuesta que se discute actualmente pretende bloquear la función de ADB en el dispositivo en sí, mucho después de haber resuelto el fallo.
¿Quién es el antagonista?
Es difícil no detectar la repetición de un patrón.
Repasando las decisiones de producto de Google en los últimos años: Chrome introdujo Manifest V3, mermando los bloqueadores de anuncios bajo el argumento de la seguridad; Android restringió los permisos de instalación externa (sideloading), limitando las instalaciones fuera de Play Store con el mismo pretexto. En cada ocasión, la “seguridad” ha sido la carta jugada, y el resultado siempre ha sido el mismo: reducir el margen de control del usuario sobre su propio dispositivo.
El usuario transcriptase en HN dio en el clavo: “Sigo sin poder creer que una empresa de publicidad haya logrado castrar de manera efectiva la capacidad de bloqueo de anuncios y contenidos para el 80% de los usuarios del mundo con el pretexto de problemas de seguridad inexistentes.”
La historia con esta restricción de ADB sigue exactamente el mismo guion. Existía una solicitud de función legítima en IssueTracker: permitir a los desarrolladores elegir en qué interfaces de red escucha el demonio ADB (actualmente escucha en todas). Era una mejora razonable. Sin embargo, en los comentarios, el mantenedor de ADB cambió el rumbo del debate, pasando de “restringir la selección de interfaces” a “prohibir por completo las conexiones en bucle local (localhost)”, destruyendo la base misma sobre la que se sustenta el depurado ADB local.
En todo este ecosistema no existe un villano malvado de película. Lo que realmente se está librando es una batalla sobre los límites de poder entre el propietario de la plataforma (Google) y los propietarios reales de los dispositivos (consumidores y desarrolladores). Google busca mantener la naturaleza cerrada y controlable del ecosistema Android, mientras que los usuarios y desarrolladores exigen el control efectivo de su propio hardware.
El ecosistema sacrificado
Si la propuesta sale adelante, ¿qué se perderá exactamente?
- Todas las funciones de Shizuku: desde la eliminación de bloatware preinstalado hasta el bloqueo del inicio automático de aplicaciones quedarán paralizadas.
- Decenas de herramientas que dependen de Shizuku, como Canta, App Manager y aShell.
- Librerías base de bajo nivel como
libadb-android. - Todos los flujos de trabajo de desarrollo que utilicen ADB dentro de Termux.
En su artículo original, Kitsumed hizo un llamamiento a los desarrolladores para que aporten comentarios constructivos en IssueTracker en lugar de publicar mensajes de protesta sin valor. Esta postura comedida refleja cierta resignación: “Sabemos que esto probablemente no se pueda detener, pero al menos no parezcamos tontos.”
A juzgar por los movimientos recientes en IssueTracker, la tarea ya ha sido asignada a los ingenieros principales del equipo de ADB, lo que indica que el proceso sigue su marcha.
La seguridad nunca es solo una cuestión técnica
La prohibición de ADB en el dispositivo puede verse, desde un punto de vista, como un endurecimiento lógico de la seguridad: cualquier medida que reduzca la superficie de ataque tiene su valor. Pero desde otra perspectiva, representa una señal de “desconfianza por defecto hacia el propietario del dispositivo”: aunque hayas comprado el teléfono, no necesariamente tienes derecho a decidir qué código puede ejecutarse en él.
Durante el debate, el usuario JoshTriplett de HN propuso una solución intermedia: desactivar las conexiones por bucle local de forma predeterminada, pero ofrecer un conmutador persistente en los ajustes (que sobreviva a los reinicios) y cuyo estado no pueda ser leído por apps de terceros. De este modo se garantizaría la seguridad de los usuarios comunes mientras se mantiene una vía abierta para los usuarios avanzados. En términos de ingeniería, no se trata de un diseño difícil de implementar.
Sin embargo, la propuesta ha levantado ampollas precisamente porque ha evitado cualquier compromiso.
En 2026, Android se encuentra inmerso en un difícil equilibrio: por un lado, la Ley de Mercados Digitales (DMA) de la Unión Europea lo obliga a abrirse a la instalación externa y a tiendas de aplicaciones de terceros; por otro, Google refuerza internamente el control sobre los niveles más profundos del sistema. La restricción de ADB en el dispositivo puede ser solo otra ficha de dominó que cae en esta contienda sin que la mayoría de los usuarios llegue a darse cuenta.
Fig.: Interfaz de configuración de depuración inalámbrica en Shizuku. Fuente: shizuku.rikka.app
Fig.: Interfaz tras iniciar Shizuku con éxito. Fuente: shizuku.rikka.app
Fig.: Cuadro de diálogo para introducir el código de vinculación de 6 dígitos. Fuente: shizuku.rikka.app
Fuentes de referencia
- Android May Soon Restrict On-Device ADB, Affecting Shizuku, libadb and Developers — Kitsumed Blog
- Hacker News Discussion (item?id=49045159)
- Shizuku User Manual — Rikka Apps
- Google IssueTracker — ADB Feature Request
- Android Developers — Documentación oficial de ADB
