unisoc-su

Un método para CVE-2025-31710 y para conectarse al socket abstracto cmd_skt para obtener un shell root en modelos unisoc sin parchear

Antes de que todos griten, el propio Unisoc me autorizó a publicar esto después del boletín de CVE-2025-31710, así que manténganse tranquilos.

Empecemos con un chiste

Sí, no estás soñando, hoy quiero presentarte un exploit para un shell del sistema en la aplicación com.sprd.engineermode y, dado que es uno de los clientes de confianza de cmd_skt, también pude acceder a él. Este socket abstracto es parte de un servicio que se ejecuta como root (cmd_services), así que sí, me alegra presentarte unisoc-su. Aquí puedes ver una lista de los clientes de confianza de cmd_skt extraída del binario cmd_services con ghidra que muestra que com.sprd.engineermode está presente:

Para este exploit se utiliza la aplicación com.sammy.systools de pascua28 y cli-pie de TomKing062. Hay dos versiones de esta aplicación, una tiene varios binarios para ser usados desde el shell del sistema, la otra solo tiene el cli-pie y algunos clis para conectarse a otros varios sockets (para engpc ahora puedes obtener esto desde el shell del sistema, sugiero obtener primero el tools.sh), luego hay para ambas una versión para Android 9 (para dispositivos más antiguos, de todas formas puedes reempaquetar la aplicación con Apktool M seleccionando la versión deseada).

Cómo funciona este método: primero ejecutas como adb o shizuku rish el UnisocEngSyshell_Enabler_Script.sh para habilitar la aplicación com.sprd.engineermode (solo necesario en modelos nuevos), luego siguiendo las instrucciones ejecuta en el marcador *#*#83781#*#* para ejecutar la actividad principal, luego desde aquí ingresa a la actividad Adb shell. Luego escribe en una línea la ruta completa del cli-pie (incluyendo el applet), en la otra "setprop persist.sys.cmdservice.enable enable", luego presiona start lo más rápido posible primero en setprop y luego en la línea del cli-pie, y boom aparecerá conectado. Luego presiona end en la actividad de setprop y borra su texto, ingresa "nc -s 127.0.0.1 -p 1234 -L sh -l" o lo que uses para ejecutar el reverse shell. Luego ve a la terminal y conéctate de vuelta con el binario correspondiente, si no funciona ejecuta el script correspondiente o simplemente conéctate con "nc 127.0.0.1 1234", después de eso "source /sdcard/Documents/unisoc-su.sh" (o donde hayas colocado el script, pero debe ser accesible desde el shell del sistema). Eso es todo, acabas de obtener un shell root si todo es correcto.

Ahora, hablemos sobre este exploit, el contexto está fuertemente protegido por selinux, tenemos root pero todas las protecciones siguen activas. Este root es enorme porque no desactivamos nada para obtenerlo como otros exploits similares. Desafortunadamente este contexto no tiene suficiente poder para desactivar selinux y la ejecución parece funcionar solo en el PATH del sistema. Sobre el servicio en sí, parece que en Android 9 (antes del parche de CVE-2022-47339) no tiene grupos en su rc de servicio y por lo tanto estos por defecto son root, luego en cambio se agregaron grupos (y se eliminó root como gid/grupos) por lo que es obvio que el servicio se volvió más restringido, pero con selinux activo es este el que manda de todas formas. Sobre cómo actúa el servicio: en dispositivos más nuevos el servicio parece ejecutarse hasta que algo lo usa o se conecta a él, si no hay ningún cliente conectado o comando emitido, el servicio se apagará y se necesitará la propiedad setprop para encenderlo nuevamente, el servicio hace esto casi de inmediato, por eso en este método ejecutamos el setprop y nos conectamos rápidamente, en Android 9 el servicio parece esperar un comando después de emitir el setprop, esta parece ser la diferencia entre dispositivos antiguos y nuevos, después de la ejecución se apaga, por supuesto es posible simplemente conectarse a él con socat o con el cli-pie (o ejecutar el puente), en este caso el servicio permanecerá activo ya que estará ocupado por esta conexión, si no se proporciona ningún comando el servicio permanecerá esperando indefinidamente.

cmd_services.rc de la rom user de android 13 y la rom eng de android 9 para mostrar las diferencias

CVEs que inspiraron este método: CVE-2022-47339 (cmd_services) por Lewei Qu(曲乐炜) y CVE-2025-31710 (shell del sistema de com.sprd.engineermode) por mí, aunque Lewei Qu(曲乐炜) tenía un CVE similar en com.sprd.engineermode parece, pero lo encontré después de obtener el mío.

También tres casos especiales que llegaron después, no forman parte de la lista de CVEs inspiradores, el primero es una vulnerabilidad reintroducida, lo agregaré aquí para que quede más claro: CVE-2025-67264 (Doogee com.sprd.engineermode parche incorrecto en modelos unisoc nuevos, cubierto aquí) también por mí, el segundo caso se refiere a modelos nuevos de ZTE, no está claro si aplica a todos o solo a algunos, la actividad Adb shell de com.sprd.engineermode se mantuvo, en ZTE Blade V70 Vita ocurre el mismo problema que en CVE-2025-67264 pero luego ZTE lo parcheó bloqueando la actividad para userdebug/eng (sin CVE ya que ellos mismos lo notaron) en lugar de eliminarla, como resultado la actividad aparece en la UI de la aplicación pero indica que no se puede abrir en compilaciones de usuario, el dispositivo es vulnerable en (probablemente antes de este cambio):ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20241231.044538:user/release-keys y fue parcheado en ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20250527.224618:user/release-keys, algo similar ocurre en ZTE Blade A55, estos modelos ejecutan Android 14, allí cmd_services fue reescrito y su nombre cambió a tool_service (y los servicios que pueden acceder a él se redujeron: com.sprd.engineermode, com.sprd.autoslt, com.sprd.runtime, com.spreadtrum.sgps, com.sprd.validationtools), esta nueva versión siempre está activa y no requiere ningún setprop, el tercero, que es una vulnerabilidad similar a la de este repositorio que afecta a modelos unisoc antiguos, fue cubierto aquí.