Root en una tablet china de la basura (MT6580)

01. Aviso y Contexto Legal

Este documento detalla una sesión práctica de investigación técnica y laboratorio sobre un dispositivo abandonado sin dueño previo recuperado de la basura. No pretende ser una guía para saltarse bloqueos de cuentas personales ni un manual para brickear terminales ajenos. Si vas a experimentar con hardware, hazlo con tus propios aparatos.

Todas las herramientas utilizadas son públicas y de código abierto: adb, fastboot, MTKClient de bkerler y Magisk estable de topjohnwu. No se requirió ningún exploit zero-day: solo entender el ciclo de arranque de Android y la estructura de particiones de MediaTek.

02. El Hallazgo: La Caja

El dispositivo en cuestión es una tablet Android genérica de marca blanca con carcasa de plástico, panel de 800×1280 píxeles, 2 GiB de memoria RAM y 32 GB de almacenamiento eMMC soldado.

En la carcasa y en los ajustes del sistema figuraba la denominación comercial OUZRS P8 y presumía de correr Android 10. No existía ningún manual de servicio en la web del supuesto fabricante, ningún repositorio de firmware oficial ni compilaciones previas de TWRP con ese nombre.

03. Reconocimiento (Modo Solo Lectura)

Conectada por USB a una estación Linux con depuración ADB activa, la primera orden fue interrogar las propiedades del sistema mediante getprop. Las cadenas delataron de inmediato la maniobra de marketing:

ro.build.version.release = 10.0      # Puro marketing cosmético
ro.build.version.sdk     = 28        # Android 9 (Pie) real
ro.build.id              = PPR1.180610.011
ro.build.flavor          = full_k80_bsp-user
ro.fota.platform         = MTK6580_9.0
ro.board.platform        = mt6580
ro.treble.enabled        = true
ro.build.system_root_image = true
ro.boot.verifiedbootstate  = green
ro.boot.flash.locked       = 1
sys.oem_unlock_allowed     = 1
getenforce                 = Enforcing

El SDK es el 28 (Android 9 Pie) y la plataforma FOTA confiesa MTK6580_9.0. El "Android 10" mostrado en Ajustes era una simple cadena cambiada en el build.prop. Incluso la huella de certificación MLS/iQM960:7.0/NRD90M procedía clonada de una tablet de otro fabricante griego para engañar a Play Protect.

04. La Huella Forense: Tres Capas de Identidad

Buscar firmwares o información técnica bajo el nombre comercial "OUZRS P8" resultaba inútil. Analizando las variables de ro.product.* se descubrió la cadena de rebrand real:

El BSP base es k80_bsp (nombre en clave de MediaTek para el reference design de MT6580). Con estos strings, fue posible contrastar volcados y comprobar la tabla de particiones existente en foros especializados bajo "YesTel X7".

05. Primero el Dump, después el Ego

Intentar flashear sin antes respaldar nvram, proinfo y preloader es un suicidio. Esas áreas contienen la calibración de radiofrecuencia analógica de fábrica, los identificadores de hardware y las direcciones MAC. Si se corrompen, la tablet no podrá registrarse en ninguna red y el bootloader quedará inutilizable.

Orden estricto de extracción y respaldo de particiones:

1. Particiones Irremplazables: nvram, nvdata, proinfo (calibración RF y números de serie).
2. Zonas de Arranque de Hardware: preloader alojado en los bloques eMMC mmcblk0boot0 y mmcblk0boot1.
3. Núcleo de Arranque: boot, recovery, vbmeta, lk (Little Kernel) y su espejo lk2.
4. Hardware Propietario: lcm (controlador de panel LCD) y seccfg (estado de seguridad).
5. Imágenes del Sistema: vendor y system para extracción de blobs propietarios.

# Apagar tablet -> conectar manteniendo Vol- para forzar modo BROM
python mtk rl --skip userdata out_backup/
sha256sum out_backup/*.bin > checksums.sha256

06. Desbloqueo Oficial de Bootloader

Afortunadamente, el Little Kernel (lk) de MediaTek conservaba los comandos oficiales de fastboot. Tras habilitar el interruptor Desbloqueo OEM en los Ajustes de Desarrollador:

adb reboot bootloader
fastboot devices
fastboot flashing unlock
# Confirmar pulsando el botón Vol+ en el panel de la tablet
fastboot reboot-bootloader

El desbloqueo de bootloader reescribe la estructura de seguridad AND_SECCFG en la partición seccfg y realiza un borrado de fábrica automático (wipe de userdata). El estado de arranque verificado pasó de green a orange.

07. El Obstáculo del SAR y el Parche a skip_initramfs

En este hardware, intentar inyectar Magisk en la partición recovery no era viable: el sistema cuenta con el binario /system/bin/install-recovery.sh, que en cada cold boot restaura la imagen stock desde /system/recovery-from-boot.p.

Por otra parte, parchear directamente boot.img se topa con la configuración inyectada por el Little Kernel:

skip_initramfs ro rootwait init=/init

Al estar presente skip_initramfs, el kernel de Linux ignora completamente el ramdisk empaquetado en boot.img y monta la partición system directamente en la raíz /. Magisk reside en un ramdisk sintético (magiskinit); por tanto, con skip_initramfs activo, Magisk nunca se ejecuta en un arranque convencional.

Además, para evitar que Android Verified Boot (AVB) genere un bootloop al detectar un kernel parcheado, se modificó el byte del offset 0x7b en la cabecera de vbmeta pasando de 0x00 a 0x03 (HASHTREE_DISABLED | VERIFICATION_DISABLED).

fastboot flash vbmeta vbmeta_patched.img
fastboot flash boot   boot_magisk_legacysar.img
fastboot reboot

08. Verificación del Sistema y Telemetría

Tras el reinicio en frío presionando el botón físico de encendido, el dispositivo arrancó de forma normal. Desde la consola de depuración:

$ adb shell "su -c id"
uid=0(root) gid=0(root)  context=u:r:magisk:s0

$ adb shell "su -c getenforce"
Enforcing

$ adb shell "su -c getprop ro.boot.verifiedbootstate"
orange

$ adb shell "su -c magisk -v"
30.7:MAGISK:R

Resultados clave de la auditoría:

• Root Limpio: Magisk 30.7 plenamente operativo en espacio de usuario.
• SELinux Seguro: Política Enforcing conservada; no se degradó a Permissive.
• Particiones Intactas: recovery stock, system, vendor, preloader y nvram coinciden exactamente con sus sumas SHA-256 iniciales.
• Control de Daños: La tablet ahora puede conectarse a la VPN interna WireGuard de mi homelab para actuar como pantalla auxiliar de monitorización.

09. Lecciones y Principios de Laboratorio

• Nunca flashees preloader a ciegas: No aporta nada para obtener privilegios root y es la causa número uno de bricks irrecuperables por software.
• No asumas la veracidad del build.prop en hardware white-label: Los fabricantes chinos de gama baja modifican strings superficiales para fingir versiones de Android más modernas. El SDK API level manda.
• Preserva los hashes criptográficos de cada volcado: Un backup sin verificación SHA-256 es solo una esperanza, no una garantía.
• La vía SAR Legacy es la más elegante en SoCs antiguos: Un parche binario en la cmdline del kernel evita alterar el código en ensamblador del LK.