Mejores módulos de Magisk en 2026: fuentes verificadas y proyectos descontinuados

Varios módulos que todavía aparecen en listas actuales ya no existen. Play Integrity Fix fue eliminado de GitHub por su propio autor. Universal SafetyNet Fix publicó su última versión en enero de 2023. Y el paso de «instalar desde el repositorio online de la app de Magisk» que describen la mayoría de guías corresponde a una función retirada de Magisk hace años. Cada proyecto de esta lista se verificó contra su propio repositorio antes de incluirlo, y todos tienen enlace.

Última verificación técnica: 30 de octubre de 2026
Versión base de Magisk: v31.1 (lanzada el 25 de octubre de 2026)
También cubre: KernelSU, KernelSU Next, SukiSU Ultra y APatch
Cobertura de Android: de 12 a 17, y versiones más nuevas solo cuando un proyecto las soporta explícitamente
Actualizado el 30 de octubre de 2026: Magisk 31.0 y 31.1 (app nueva, sin más ventanas emergentes de root, eliminada la ocultación de la app), versiones actuales de cada gestor de root e implementación de Zygisk, alternativas open source a Tricky Store, y varios módulos ahora archivados u obsoletos
Regla de sourcing: solo enlaces oficiales del mantenedor. No alojamos ZIPs de módulos

Si solo quieres la respuesta rápida

La mayoría de usuarios busca una de cuatro cosas. No necesitas instalar toda la lista.

El resto de esta guía explica esas cuatro rutas con detalle y, sobre todo, qué conviene evitar.

Qué cambió y qué deberías dejar de instalar

Si estás siguiendo una guía antigua, puede que estés a punto de instalar algo que ya está muerto.

La última fila es la que más confusión genera. Mucha gente abre Magisk buscando la pestaña de módulos que describe una guía antigua, no la encuentra y piensa que la instalación está rota. No lo está.

Ahora la búsqueda y la instalación son pasos separados: localizas el módulo en GitHub, descargas el ZIP oficial y lo instalas desde el almacenamiento.

Varios «módulos populares» ni siquiera son módulos

Esto importa porque cambia dónde debes conseguirlos y cómo debes actuar si algo falla.

Todas pueden ser útiles. Ninguna es algo que debas «flashear» simplemente porque otra guía la colocó entre dos módulos Zygisk. Buscar un supuesto «AdAway ZIP» suele llevar precisamente a los mirrors no oficiales que queremos evitar.

Qué cambió en Magisk 31.0 y 31.1

Magisk 31.1 es la versión estable actual (25 de octubre de 2026) y cambia cómo se comporta Magisk en el día a día. La mayoría de guías antiguas, incluidas versiones anteriores de esta misma, describen el flujo antiguo. Según las notas de lanzamiento oficiales:

Las solicitudes de root ya no muestran una ventana emergente. El acceso de superusuario ahora se concede a las apps por adelantado, desde la pestaña Superuser de la app de Magisk. Si una app de terminal, una herramienta de backup o un módulo dice necesitar root y no aparece nada en pantalla, abre Superuser y concédelo ahí primero. Lo mismo se aplica a adb shell, que no tiene una app en primer plano donde mostrar el aviso. El equipo de Magisk explica que el antiguo aviso reactivo no puede funcionar en dispositivos HSUM.

La ocultación de la app de Magisk ha desaparecido. Se eliminó la función de repackaging (renombrar la app a un nombre de paquete aleatorio), y Magisk ya no reinstala su app si falta. El propio desarrollador lo dice sin rodeos: ocultar de verdad un paquete instalado es casi imposible en Android, así que, una vez configuradas tus políticas de Superuser y tus módulos, la forma más efectiva de ocultar la app de Magisk es desinstalarla. Las apps que buscan al gestor son una razón más para apoyarte en DenyList y en los pasos de ocultación de más abajo en lugar de en el nombre de la app.

Antes de actualizar un móvil que ya funciona bien, anota tu versión actual, haz una captura de la lista de Superuser y conserva la boot image stock de tu compilación. Los móviles en Android 6.0 deben quedarse en la 30.7.

¿Qué gestor de root estás usando?

Magisk ya no es la única opción. El gestor que uses determina qué módulos puedes instalar y qué tipo de integración tendrás disponible.

Hay dos errores especialmente comunes.

No puedes ejecutar dos sistemas de root a la vez. Desinstala por completo uno, restaura la imagen stock correspondiente y solo entonces instala el otro. Mantener dos activos genera conflictos.

Los forks de KernelSU no son intercambiables. KernelSU, KernelSU Next y SukiSU Ultra comparten ideas, pero sus gestores y cambios de kernel no son idénticos. Usa el build hecho para el fork que realmente tengas instalado.

Sobre Magisk Alpha: es una versión no oficial distribuida principalmente por Telegram. Tiene una comunidad activa, pero su historial público de código y releases es más débil que el de Magisk oficial, lo cual importa para software que se ejecuta como root. La versión oficial estable es más fácil de verificar. ReZygisk, por ejemplo, eliminó el soporte de Magisk Alpha en su v1.0.0.

Qué funciona con cada uno

La fila que más cambia la decisión es SUSFS. Trabaja dentro del kernel, no en espacio de usuario, de modo que puede ocultar señales que un módulo de userspace no puede ocultar de la misma forma. No funciona con Magisk, porque Magisk no modifica el kernel.

Esa es la principal razón técnica para considerar una alternativa a Magisk en 2026, pero exige un dispositivo con kernel compatible. No todos lo tienen. Nuestra comparación Magisk vs KernelSU vs APatch profundiza en esa elección.

Todo lo incluido en esta guía funciona con Magisk salvo que indiquemos expresamente una limitación.

Antes de instalar cualquier módulo

Haz una captura de tu lista actual de módulos. Abre tu gestor de root y guarda una captura de la pestaña Módulos. Si algo falla, sabrás exactamente qué cambió. Tarda cinco segundos y no necesita terminal.

Anota tu versión de Magisk y tu compilación de Android. Magisk muestra la versión en la pantalla principal. La versión de Android y el parche de seguridad aparecen en Ajustes → Información del teléfono.

Instala un módulo cada vez, reinicia y comprueba. Si instalas cinco módulos y reinicias una sola vez, no sabrás cuál rompió el sistema.

Aprende la ruta de recuperación antes de necesitarla. Está al final de esta guía. Léela antes de tocar nada.

Paso 1: elige una única implementación de Zygisk

Zygisk es la capa de inyección que necesitan muchos módulos de ocultación y el ecosistema Xposed. Magisk incluye su propia implementación. KernelSU y APatch no, por lo que necesitan una implementación independiente. Incluso en Magisk puedes optar por una alternativa, pero no debes ejecutar dos a la vez.

Tres reglas evitan la mayoría de problemas:

Ejecuta exactamente uno. Si instalas una implementación independiente en Magisk, desactiva antes Zygisk integrado. Ejecutar ambos es una fuente clásica de fallos.

Shamiko no funciona con ReZygisk. Shamiko está orientado a Zygisk integrado y Zygisk Next. Si eliges ReZygisk tendrás que usar otra herramienta de ocultación. Mezclarlos es una causa habitual de «ayer ocultaba root y hoy ya no». Lo mismo aplica a Zygisk Assistant según la combinación.

Desinstala el anterior antes de cambiar. Migrar sin retirar el módulo viejo ha causado bootloops, especialmente cuando cambia el ID del módulo.

El cambio de licencia de Zygisk Next merece una decisión consciente en lugar de una opción por defecto. Es un módulo con privilegios de root cuyas versiones recientes no pueden auditarse de forma independiente, y esa es la razón declarada por la que existe ReZygisk. Que te importe o no es una decisión personal, no un fallo técnico.

Paso 2: integridad y ocultación, como árbol de decisión

La corrección más importante respecto a muchas guías antiguas es esta:

Pasar Play Integrity y ocultar root a una app son dos problemas diferentes.

Es perfectamente posible pasar todos los verdicts de Play Integrity y que Google Wallet o una app bancaria siga rechazando el dispositivo. Cada app puede inspeccionar señales adicionales. Instalar toda la pila «porque una guía dice que es imprescindible» termina dejando seis módulos donde quizá bastaban dos.

Trabaja por capas y prueba después de cada una.

Empieza por DenyList. Viene integrado en Magisk, sin descargas. Añade las apps a las que quieres ocultar root. Muchas dejan de quejarse aquí y no necesitas nada más. Magisk 31.0 también añadió webview_zygote como destino de desmontaje de DenyList.

¿La app sigue detectando root? Añade una herramienta de ocultación. Shamiko, desde la distribución de releases de LSPosed, v1.2.5 a junio de 2025 con correcciones para Android 16 y páginas de 16K, y sin ninguna release más reciente a 30 de octubre de 2026. Hay un detalle contraintuitivo: Shamiko necesita que la aplicación de DenyList esté desactivada, pero que la lista siga configurada. Dejar la imposición activada deshabilita Shamiko. Es la configuración incorrecta más común de todo este artículo. En KernelSU con un kernel SUSFS, a menudo Shamiko ni siquiera es necesario porque el kernel ya hace ese trabajo.

¿El problema concreto es un verdict de integridad? Añade una herramienta de Play Integrity. osm0sis/PlayIntegrityFork, v18 a agosto de 2026, es la continuación directa del original descontinuado y el sucesor al que apuntó su propio autor. KOWX712/PlayIntegrityFix es otro fork mantenido de la misma línea, v4.9 a octubre de 2026. No instales dos forks de PIF al mismo tiempo.

Solo si tienes una necesidad concreta de key attestation, considera Tricky Store. 5ec1cff/TrickyStore, Android 10+. También circulan forks de beakthoven y qwq233, en los que ahora se basan varias herramientas.

Para gestionar en qué apps se aplica, KOWX712/Tricky-Addon-Update-Target-List ofrece una interfaz propia para la lista de objetivos, el keybox y el parche de seguridad de Tricky Store. Es un proyecto independiente y su autor pide que no se reporten issues de esto en el proyecto upstream.

Ya existen alternativas open source a Tricky Store. beakthoven/TrickyStoreOSS es una reescritura GPL-3.0 (v3.1.0, agosto de 2026). JingMatrix/TEESimulator es un KeyMint por software GPL-3.0 que corre dentro del daemon keystore (v4.0, agosto de 2026, Android 10+, solo dispositivos de 64 bits). qwq233/OhMyKeymint es una reimplementación completa del keystore que busca parecerse más al AOSP de serie (Android 12+, builds de preview). Ejecuta exactamente una. Ninguna trae un keybox funcional, y seguimos sin recomendar ninguno.

Tres cosas que muchas otras guías no explican

Tricky Store es cerrado desde v1.1.0. El mantenedor cerró el código por preocupaciones de abuso. Junto con el cambio de licencia de Zygisk Next, las dos herramientas más potentes de esta categoría son ahora binarios con privilegios de root que no se pueden auditar. Su última release fue la 1.4.1 en noviembre de 2025. Mejor saberlo antes de instalarlos, no después. Ya existen reescrituras open source, listadas justo debajo, aunque son más nuevas y menos probadas.

Tricky Store no incluye un keybox funcional. Incluye uno de AOSP que no sirve como credencial válida de attestation. Las guías que prometen «instala Tricky Store y tendrás Strong Integrity» se saltan esa parte. Los keyboxes además pueden ser revocados, tras lo cual la configuración deja de funcionar. Droid Rooter no distribuye keyboxes y recomendamos desconfiar de quien los venda como una solución permanente.

La integridad de dispositivo respaldada por software se volvió bastante más difícil en 2026. A comienzos de año se bloquearon muchas fingerprints utilizadas por la comunidad y uno de los repositorios principales que mantenía esa colección fue archivado por su propietario, quien explicó que ya no quedaban fingerprints funcionales para varias combinaciones comunes de arquitectura. Eso no significa que todos los enfoques basados en fingerprint hayan muerto, pero el suministro ya no es el mismo.

La lectura realista: los verdicts básicos suelen ser alcanzables; Device Integrity exige más trabajo; Strong Integrity con bootloader desbloqueado es genuinamente difícil; y algunas apps seguirán negándose aunque los tests sean verdes. No publicamos una «tasa de éxito» porque quedaría obsoleta en semanas.

¿Quieres que configuremos esto una sola vez y con tus apps reales en lugar de probar combinaciones durante días? Envíanos modelo, versión de Android, método de root y las apps que necesitas. Lo configuramos por acceso remoto y te decimos de antemano qué expectativas son realistas. El diagnóstico es gratuito desde nuestro servicio de root Android.

Si vas a pedir ayuda, envía estos datos

El comportamiento de integridad cambia constantemente. Preguntar «¿funciona esta pila con mi banco?» sin contexto no permite una respuesta seria. Envía esto:

Dispositivo y modelo exacto:
Versión y compilación de Android:
Nivel de parche de seguridad:
Gestor de root y versión:
Implementación de Zygisk:
Módulos instalados, con versiones:
Verdict de Play Integrity:
App y versión que falla:
Mensaje exacto que muestra:

Eso convierte una pregunta imposible de reproducir en un caso diagnosticable. Por la misma razón eliminamos anécdotas anónimas de compatibilidad de versiones anteriores: sin esos datos no eran verificables.

Paso 3: la capa Xposed

El proyecto LSPosed original no tiene ninguna release desde octubre de 2023 ni commits en master desde enero de 2024, y sus releases apuntaban a Android 8.1–14. En un dispositivo moderno ya no es el punto de partida correcto.

JingMatrix/LSPosed es el fork mantenido que usa la mayoría, y ahora vive en el repositorio JingMatrix/Vector (la URL antigua redirige ahí). Vector mantiene la compatibilidad de API con el Xposed original mientras reescribe los internals, con soporte hasta Android 16 y 17 y dispositivos con páginas de 16K. Sus releases se publican actualmente como builds canary de pre-release (canary-3114 el 26 de octubre de 2026), no como versiones estables etiquetadas, así que lee las notas de la release antes de actualizar.

JingMatrix/LSPatch es la vía sin root (también en builds canary, como Vector). Integra el framework dentro de una app parcheando su APK. Sin root y sin Zygisk. Es útil cuando solo necesitas el comportamiento de un módulo Xposed en una app concreta.

ReLSPosed, otro fork que circuló durante un tiempo, fue archivado por su propietario en febrero de 2026. Mira las fechas antes de confiar en cualquier fork.

Hide My Applist (Dr-TSNG/Hide-My-Applist) intercepta consultas a la lista de apps, una señal que algunas aplicaciones usan para descubrir gestores de root. El desarrollo estuvo suspendido una temporada, pero publicó la v3.8.3 en agosto de 2026. Trátalo como mantenido de forma ocasional y comprueba la fecha de la release antes de confiar en él.

Los módulos Xposed tienen el mismo problema: uno sin actividad durante dos años difícilmente es una apuesta segura en Android 15 o 16, aunque un hilo antiguo diga que «funciona perfecto».

Paso 4: lista verificada de módulos

Agrupados por lo que realmente quieres conseguir. Todos los enlaces apuntan al repositorio del mantenedor. Salvo que indiquemos lo contrario, funcionan con Magisk.

Bloqueo de anuncios y rastreadores

Ejecuta un solo bloqueador de hosts. Dos módulos, o uno junto con el modo root de AdAway, acaban peleando por el mismo recurso. Las listas demasiado agresivas también rompen funciones legítimas, así que empieza con un perfil estándar.

Un recordatorio importante: el bloqueo por hosts evita resoluciones de dominio. No puede eliminar anuncios servidos desde el mismo dominio que el contenido. El DNS privado de Android consigue gran parte del mismo efecto sin root.

Batería y energía

ACC es una alternativa concreta a las vagas recomendaciones de «battery management» que aparecen en muchas listas sin repositorio ni explicación. Usa sus herramientas de detección; no copies los valores de carga de otro modelo.

Gaming y scheduling

Configúralo por juego, no globalmente. Las mejoras dependen del dispositivo, kernel y juego, y los vídeos de demostración suelen exagerar. No lo apiles con otro módulo de scheduling.

Interfaz y personalización

Aplica cambios por grupos. SystemUI puede fallar o entrar en bootloop cuando mezclas overlays con una ROM o actualización no compatible. Antes de una actualización mayor, revierte los overlays.

Utilidades

Desarrollo y pruebas de seguridad

Estas herramientas amplían la superficie de confianza del dispositivo. Son útiles para debugging de tráfico y pruebas de seguridad; no son una buena configuración permanente en un móvil de uso diario. Elimina las CAs de pruebas cuando termines. Ninguna de las dos evita certificate pinning por sí sola.

Pilas alternativas para integridad

Integrity-Box agrupa gestión de integridad y entorno detrás de su propia interfaz. PlayIntegrityFix-NEXT fue un fork experimental con cobertura Android 10 a 16. Su propietario lo archivó en octubre de 2025 tras la release v3.0, así que no construyas una configuración nueva sobre él. Integrity-Box publica con mucha frecuencia (v46 el 29 de octubre de 2026), lo cual tiene dos caras: arreglos rápidos, y un objetivo en movimiento constante.

Ambos se solapan con PlayIntegrityFork. Trátalos como alternativas, no como capas que debas añadir encima. Las herramientas de integridad superpuestas producen conflictos muy difíciles de diagnosticar.

Ocultación a nivel kernel — solo familia KernelSU

SUSFS vive en gitlab.com/simonpunk/susfs4ksu y tiene un módulo complementario en sidex15/susfs4ksu-module. Necesita un kernel previamente parcheado para SUSFS, por lo que es una opción para KernelSU, KernelSU Next o SukiSU Ultra. No está disponible de la misma manera en Magisk ni APatch.

Niveles de riesgo

Dónde conseguir módulos ahora

Desde que desapareció el repositorio integrado:

• La página de releases del proyecto en GitHub. Es la fuente correcta para todo lo que enlazamos aquí. Descarga el asset .zip, no el ZIP automático del código fuente.
• Magisk-Modules-Alt-Repo, repositorio comunitario que sigue aceptando proyectos.
• MMRL, un gestor que permite explorar módulos de Magisk, KernelSU y APatch si prefieres una interfaz en lugar de descargar manualmente.

Para instalar: abre tu gestor de root → Módulos → Instalar desde almacenamiento → selecciona el ZIP → reinicia.

No alojamos binarios de módulos y conviene desconfiar de quien los redistribuya sin necesidad. Descarga desde el proyecto oficial, no desde un mirror, enlace acortado o archivo suelto de Telegram.

Cómo evaluar un módulo antes de instalarlo

Los módulos root se ejecutan con privilegios completos. Trátalos con el nivel de revisión que eso merece:

• ¿El código está visible? Si no hay repositorio, no lo instales.
• ¿Cuándo fue la última release? Dos años sin actividad en una plataforma que cambia rápido es una mala señal.
• ¿El mantenedor responde issues? Meses de silencio constante también es información.
• ¿La documentación declara compatibilidad? Versión de Android, gestor de root y conflictos conocidos.
• ¿Hay usuarios actuales ejecutándolo en tu versión de Android y con tu mismo gestor? No basta que funcionara en un móvil de 2023.
• ¿Te pide debilitar una protección? Cualquier cosa que exija desactivar SELinux merece un análisis mucho más serio.

Recuperarse de un bootloop provocado por un módulo

Ten esta ruta preparada antes de necesitarla. En este orden:

1. Modo seguro. Magisk desactiva todos los módulos cuando detecta un arranque en modo seguro. KernelSU tiene un mecanismo equivalente. Después puedes arrancar el sistema y eliminar el módulo problemático desde el gestor. La combinación de teclas depende del modelo, así que pruébala una vez mientras el móvil todavía funciona.

2. Comando de eliminación. Si un PC consigue ver el teléfono mientras intenta arrancar, Magisk documenta:

adb wait-for-device shell magisk --remove-modules

Elimina todos los módulos y reinicia.

3. Deshabilitar un solo módulo desde shell. Crear un archivo llamado disable dentro de la carpeta del módulo en /data/adb/modules/ desactiva únicamente ese módulo.

4. Restaurar la imagen stock de arranque. Es el plan de respaldo y la razón por la que deberías conservarla. Lee primero la advertencia siguiente.

La advertencia sobre boot images

La propia documentación de Magisk recuerda que la restauración de particiones depende del dispositivo. Samsung merece especial cuidado: no debes restaurar a ciegas boot, init_boot, recovery o vbmeta siguiendo un tutorial genérico. APatch, además, parchea boot, no init_boot.

Sigue el procedimiento para tu modelo exacto. Si un flash ya salió mal, diagnostica antes de volver a flashear: Magisk falló al flashear: cómo diagnosticar antes de borrar datos (en inglés). Si el teléfono ni siquiera arranca, primero identifica el estado: qué significa cada síntoma de la pantalla de arranque (en inglés).

Y, sobre todo, no empieces borrando datos. El orden importa. Una restauración de fábrica elimina también las claves de cifrado que protegen tus archivos.

Lecturas relacionadas: Magisk vs KernelSU vs APatch · SafetyNet y Play Integrity con root (en inglés) · Magisk en 2026: qué cambió (en inglés) · Error al flashear Magisk (en inglés) · OTA fallida en un Android rooteado (en inglés) · Guía de debloat en Android (en inglés).

Fuentes: los repositorios oficiales de GitHub o GitLab de cada proyecto, enlazados en el texto; documentación, FAQ y notas de versión oficiales de Magisk; documentación oficial de APatch y KernelSU. El estado de los módulos fue revisado contra la actividad de sus repositorios y las declaraciones de los mantenedores en la fecha indicada al inicio.

Última verificación: 30 de octubre de 2026. Este ecosistema cambia deprisa. Todos los proyectos mencionados estaban activos o tenían el estado descrito en esa fecha; cualquiera puede ser abandonado, bifurcado o sustituido sin aviso. Revisa el repositorio enlazado antes de instalar y toma la fecha de verificación como un dato técnico, no decorativo.