unisoc-su

Метод для CVE-2025-31710 и подключения к абстрактному сокету cmd_skt для получения root-шелла на незаплаченных моделях Unisoc

Прежде чем все закричат: сама Unisoc авторизовала меня на публикацию этого после бюллетеня по CVE-2025-31710, так что сидите тихо.

Начнём с шутки

Да, вам не снится, сегодня я хочу представить вам эксплойт для системного шелла в приложении com.sprd.engineermode, и, поскольку оно является одним из доверенных клиентов cmd_skt, я также смог проникнуть и туда. Этот абстрактный сокет является частью сервиса, работающего с правами root (cmd_services), так что да, я рад представить вам unisoc-su. Здесь вы можете увидеть список доверенных клиентов cmd_skt, извлечённый из бинарника cmd_services с помощью ghidra, который показывает, что com.sprd.engineermode присутствует:

Для этого эксплойта используется приложение com.sammy.systools от pascua28 и cli-pie от TomKing062. Существует две версии этого приложения: одна содержит различные бинарники для использования из системного шелла, другая — только cli-pie и некоторые cli для подключения к другим различным сокетам (для engpc теперь можно подключиться к этому из системного шелла, я предлагаю сначала подключить tools.sh), также для обеих версий есть вариант для Android 9 (для более старых устройств; в любом случае вы можете пересобрать приложение с помощью Apktool M, выбрав желаемую версию).

Как работает этот метод: сначала вы выполняете через adb или shizuku rish скрипт UnisocEngSyshell_Enabler_Script.sh, чтобы включить приложение com.sprd.engineermode (нужно только на новых моделях), затем, следуя инструкциям, набираете в звонилке *#*#83781#*#* для запуска главной активности, а оттуда входите в активность Adb shell. Затем в одну строку вводите полный PATH до cli-pie (включая апплет), в другую — "setprop persist.sys.cmdservice.enable enable", затем как можно быстрее жмёте start сначала на setprop, а затем на строке с cli-pie, и вуаля — появится connected. Затем жмёте end на активности setprop, удаляете её текст, вводите "nc -s 127.0.0.1 -p 1234 -L sh -l" или то, что вы используете для запуска reverse-шелла. Затем идёте в терминал и подключаетесь обратно соответствующим бинарником; если он не запускается, подключите соответствующий скрипт или просто подключитесь через "nc 127.0.0.1 1234", после этого "source /sdcard/Documents/unisoc-su.sh" (или туда, куда вы положили скрипт, но он должен быть доступен из системного шелла). Вот и всё, если всё правильно, вы только что получили root-шелл.

Теперь поговорим об этом эксплойте: контекст сильно защищён selinux, у нас есть root, но все защиты всё ещё активны. Этот root огромен, потому что мы ничего не отключали ради его получения, в отличие от других подобных эксплойтов. К сожалению, этого контекста недостаточно для отключения selinux, и, похоже, выполнение работает только из системного PATH. Что касается самого сервиса: похоже, на Android 9 (то есть до патча CVE-2022-47339) в его сервисном rc нет групп, поэтому они по умолчанию root, а позже группы были добавлены (а root из gid/groups убран), так что очевидно, что сервис стал более ограниченным, но при включённом selinux именно он всем и правит. О том, как ведёт себя сервис: на новых устройствах сервис, похоже, работает, пока кто-то не использует его или не подключится к нему; если нет подключённого клиента или отданной команды, сервис выключится, и понадобится свойство setprop, чтобы включить его снова, сервис делает это почти мгновенно, именно поэтому в этом методе мы запускаем setprop и быстро подключаемся; на Android 9 сервис, похоже, ждёт команду после выдачи setprop, и это, судя по всему, разница между старыми и новыми устройствами; после выполнения он выключается. Конечно, можно просто подключиться к нему через socat или через cli-pie (или запустить мост), в этом случае сервис останется поднятым, так как будет занят этим подключением; если команда не передана, сервис будет ожидать бесконечно.

cmd_services.rc из пользовательской прошивки Android 13 и инженерной прошивки Android 9, чтобы показать различия

CVE, вдохновившие этот метод: CVE-2022-47339 (cmd_services) от Lewei Qu(曲乐炜) и CVE-2025-31710 (системный шелл com.sprd.engineermode) от меня, хотя у Lewei Qu(曲乐炜) был похожий CVE на com.sprd.engineermode, как выяснилось, но я нашёл это уже после того, как получил свой.

Также три особых случая, которые появились позже, они не входят в список вдохновивших CVE. Первый — это повторно внедрённая уязвимость, я добавлю её сюда, чтобы всё было чище: CVE-2025-67264 (Doogee com.sprd.engineermode, плохой патч на новых моделях Unisoc, описан здесь) тоже от меня. Второй случай касается новых моделей ZTE, неясно, относится ли это ко всем или только к некоторым: активность Adb shell в com.sprd.engineermode была сохранена, на ZTE Blade V70 Vita происходит та же проблема, что и в CVE-2025-67264, но позже ZTE заплатчила это, заблокировав активность для userdebug/eng (CVE нет, так как они заметили это сами) вместо её удаления; в результате активность отображается в UI приложения, но выдаёт сообщение, что её нельзя открыть на пользовательских сборках. Устройство уязвимо (вероятно, до этого изменения): ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20241231.044538:user/release-keys, и было заплатчено на ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20250527.224618:user/release-keys. Похожая ситуация происходит на ZTE Blade A55; эти модели работают на Android 14, там cmd_services был переписан и переименован в tool_service (а набор сервисов, имеющих к нему доступ, сократился: com.sprd.engineermode, com.sprd.autoslt, com.sprd.runtime, com.spreadtrum.sgps, com.sprd.validationtools); эта новая версия всегда активна и не требует никакого setprop. Третий случай — похожая уязвимость на уязвимость из этого репозитория, затрагивающая старые модели Unisoc, описан здесь.