unisoc-su

Um método para CVE-2025-31710 e para conectar ao socket abstrato cmd_skt para obter um shell root em modelos unisoc sem patch

Antes que todos gritem, a própria Unisoc me autorizou a publicar isso após o boletim CVE-2025-31710, então fiquem quietos.

Vamos começar com uma piada

9u4d2i

Sim, você não está sonhando, hoje quero apresentar a você um exploit para um shell de sistema no aplicativo com.sprd.engineermode e, como é um dos clientes confiáveis do cmd_skt, também consegui acessá-lo. Este socket abstrato faz parte de um serviço executado como root (cmd_services), então sim, estou feliz em apresentar a você o unisoc-su. Aqui você pode ver uma lista dos clientes confiáveis do cmd_skt extraída do binário cmd_services com ghidra, que mostra que com.sprd.engineermode está presente:

cmd_services apps

Para este exploit, é usado o aplicativo com.sammy.systools por pascua28 e cli-pie por TomKing062. Existem duas versões deste aplicativo, uma possui vários binários para serem usados a partir do shell do sistema, a outra apenas com o cli-pie e alguns clis para conectar a outros vários sockets (para engpc você pode agora obter este do shell do sistema, sugiro obter primeiro o tools.sh), então para ambos há uma versão para Android 9 (para dispositivos mais antigos, de qualquer forma você pode reempacotar o aplicativo com Apktool M selecionando a versão desejada).

Como este método funciona: primeiro você executa como adb ou shizuku rish o UnisocEngSyshell_Enabler_Script.sh para habilitar o aplicativo com.sprd.engineermode (necessário apenas em modelos novos), então seguindo as instruções, execute no discador *#*#83781#*#* para executar a atividade principal, depois entre na atividade Adb shell. Em seguida, digite em uma linha o PATH completo do cli-pie (incluindo o applet), na outra "setprop persist.sys.cmdservice.enable enable", então pressione start o mais rápido possível primeiro no setprop e depois na linha do cli-pie, e pronto, aparecerá "connected". Depois pressione end na atividade setprop e apague o texto, insira "nc -s 127.0.0.1 -p 1234 -L sh -l" ou o que você usar para executar o reverse shell. Então vá para o terminal e conecte-se de volta com o binário correspondente; se não funcionar, obtenha o script correspondente ou simplesmente conecte-se com "nc 127.0.0.1 1234", depois disso "source /sdcard/Documents/unisoc-su.sh" (ou onde você colocou o script, mas ele deve estar acessível a partir do shell do sistema). É isso, você acabou de obter um shell root se tudo estiver correto.

Agora, vamos falar sobre este exploit. O contexto é fortemente protegido pelo selinux, temos root, mas todas as proteções ainda estão ativas. Este root é enorme porque não desabilitamos nada para obtê-lo, ao contrário de outros exploits semelhantes. Infelizmente, este contexto não tem poder suficiente para desabilitar o selinux e a execução parece funcionar apenas no PATH do sistema. Sobre o serviço em si, parece que no Android 9 (ou seja, antes do patch CVE-2022-47339) ele não tem grupos em seu rc de serviço, então eles assumem root como padrão; posteriormente, grupos foram adicionados (e root como gid/grupos removido), então é óbvio que o serviço ficou mais restrito, mas com o selinux ativo, é ele quem manda de qualquer forma. Sobre como o serviço age: em dispositivos mais novos, o serviço parece rodar até que algo o use ou se conecte a ele; se não houver cliente conectado ou comando emitido, o serviço será desligado e será necessária a propriedade setprop para reativá-lo. O serviço faz isso quase imediatamente, por isso neste método executamos o setprop e rapidamente nos conectamos. No Android 9, o serviço parece aguardar um comando após o setprop ser emitido; essa parece ser a diferença entre dispositivos antigos e novos. Após a execução, ele desliga. Claro, é possível apenas conectar-se a ele com socat ou com o cli-pie (ou executar a bridge); nesse caso, o serviço permanecerá ativo, pois estará ocupado por essa conexão; se nenhum comando for fornecido, o serviço ficará aguardando indefinidamente.

cmd_services.rc da rom de usuário do Android 13 e da rom de engenharia do Android 9 para mostrar as diferenças cmd_services_android13 (user) rc cmd_services_android9 (eng) rc

CVEs que inspiraram este método: CVE-2022-47339 (cmd_services) por Lewei Qu(曲乐炜) e CVE-2025-31710 (shell de sistema do com.sprd.engineermode) por mim, embora Lewei Qu(曲乐炜) tenha tido um CVE semelhante no com.sprd.engineermode, mas descobri isso depois de obter o meu.

Também três casos especiais que surgiram depois, eles não fazem parte da lista de CVEs inspiradores. O primeiro é uma vulnerabilidade reintroduzida, vou adicioná-lo aqui para deixar as coisas mais claras: CVE-2025-67264 (patch ruim da Doogee no com.sprd.engineermode em novos modelos unisoc, coberto aqui) por mim também. O segundo caso diz respeito a novos modelos da ZTE, não está claro se se aplica a todos ou apenas a alguns; a atividade Adb shell do com.sprd.engineermode foi mantida. No ZTE Blade V70 Vita, ocorre o mesmo problema que no CVE-2025-67264, mas posteriormente a ZTE o corrigiu bloqueando a atividade para userdebug/eng (sem CVE, pois eles mesmos notaram) em vez de removê-la; como resultado, a atividade aparece na UI do aplicativo, mas informa que não pode ser aberta em builds de usuário. O dispositivo é vulnerável em (provavelmente antes desta alteração): ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20241231.044538:user/release-keys e foi corrigido em ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20250527.224618:user/release-keys. Algo semelhante acontece no ZTE Blade A55. Esses modelos rodam Android 14; lá, o cmd_services foi reescrito e seu nome mudou para tool_service (e os serviços que podem acessá-lo foram reduzidos: com.sprd.engineermode, com.sprd.autoslt, com.sprd.runtime, com.spreadtrum.sgps, com.sprd.validationtools). Esta nova versão está sempre ativa e não requer nenhum setprop. O terceiro caso, que é uma vulnerabilidade semelhante à deste repositório afetando modelos antigos da unisoc, foi coberto aqui.

Aqui estão fornecidos vários scripts para o unisoc-su: um sem tutorial: unisoc-su.sh; um que guia para entrar no shell root apenas com o shell do sistema (este método é mais fácil, funciona offline e sem shizuku/adb): unisoc-su-syshell-only-tut.sh; um que guia para entrar no shell root usando shizuku/adb, usado apenas para executar a parte do setprop: unisoc-su-adb-shizuku-tut.sh; também uma versão para conectar a vários sockets. Obtenha o que preferir do seu terminal; apenas o unisoc-su.sh e este último exigem ser obtidos a partir do shell do sistema. Também está disponível um script tools.sh na pasta ghostroot para adicionar vários diretórios ao PATH, compatível com adb/system e root, além de um script multi para executar o shell do sistema se você não souber qual nc possui em seu sistema; ele tentará nc a partir de vários binários possíveis até que a conexão seja bem-sucedida.

Adicionado agora também um pequeno poc app, é apenas um aplicativo com quatro botões: um para conectar ao shell root do cmd_services, outro para conectar ao shell do sistema, um botão de ajuda, um botão para limpar a saída e um mini terminal. A preparação deve ser feita manualmente, por isso é seguro de usar.

Sobre o GhostRoot (Canal Root Pós-Exploit) Um canal de comandos pós-exploit furtivo que sobrevive na RAM e aceita entrada de qualquer aplicativo não privilegiado via I/O baseado em arquivos.

O exploit funciona até o Android 13, pois em versões posteriores a unisoc removeu a tag sharedUserId do aplicativo EngineerMode, e agora ele é um aplicativo de usuário normal; isso faz com que o selinux negue a execução do cli-pie no Android 14 e superiores.

SharedUid-NormalUid_Compare-Patch Imagem fornecida por TomKing062