unisoc-su

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

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

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

9u4d2i

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

cmd_services apps

Для этого эксплойта используется приложение 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, чтобы показать различия cmd_services_android13 (user) rc cmd_services_android9 (eng) rc

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, описан здесь.

Здесь представлены различные скрипты для unisoc-su: один без обучающего руководства: unisoc-su.sh; один, который проводит по входу в root-шелл только через системный шелл (этот метод проще, работает офлайн и без shizuku/adb): unisoc-su-syshell-only-tut.sh; один, который проводит по входу в root-шелл через shizuku/adb, используется только для выполнения части с setprop: unisoc-su-adb-shizuku-tut.sh; также есть версия для подключения к различным сокетам. Подключайте тот, который вам нравится, из вашего терминала, только unisoc-su.sh и последний требуют подключения из системного шелла. Также доступен скрипт tools.sh в папке ghostroot для добавления различных каталогов в PATH, совместимый с adb/системой и root, а также multi скрипт для запуска системного шелла, если вы не знаете, какой nc есть в вашей системе; он будет пробовать nc из различных возможных бинарников, пока соединение не будет установлено.

Теперь добавлено также небольшое poc-приложение, это просто приложение с четырьмя кнопками: одна для подключения к root-шеллу cmd_services, другая для подключения к системному шеллу, кнопка помощи, кнопка очистки вывода и мини-терминал. Подготовка должна выполняться вручную, так что использовать его безопасно.

О GhostRoot (пост-эксплуатационный root-канал) Скрытный пост-эксплуатационный командный канал, который живёт в оперативной памяти и принимает ввод от любого непривилегированного приложения через файловый ввод-вывод.

Эксплойт работает вплоть до Android 13, так как в более поздних версиях Unisoc удалила тег sharedUserId из приложения EngineerMode, и теперь это обычное пользовательское приложение, из-за чего selinux запрещает выполнение cli-pie на Android 14 и выше.

SharedUid-NormalUid_Compare-Patch Изображение предоставлено TomKing062