unisoc-su

Eine Methode für CVE-2025-31710 und um eine Verbindung zum abstrakten Socket cmd_skt herzustellen, um auf nicht gepatchten Unisoc-Modellen eine Root-Shell zu erhalten.

Bevor alle schreien: Unisoc selbst hat mir erlaubt, dies nach dem CVE-2025-31710-Bulletin zu veröffentlichen, also bleibt ruhig.

Beginnen wir mit einem Witz

9u4d2i

Ja, du träumst nicht. Heute möchte ich dir einen Exploit für eine System-Shell in der App com.sprd.engineermode vorstellen, und da sie einer der vertrauenswürdigen Clients von cmd_skt ist, konnte ich auch dort hineingelangen. Dieser abstrakte Socket gehört zu einem Dienst, der als root läuft (cmd_services), also ja, ich freue mich, dir unisoc-su zu präsentieren. Hier siehst du eine Liste der vertrauenswürdigen Clients von cmd_skt, die mit Ghidra aus der Binärdatei cmd_services extrahiert wurde und zeigt, dass com.sprd.engineermode vorhanden ist:

cmd_services apps

Für diesen Exploit werden die App com.sammy.systools von pascua28 und der cli-pie von TomKing062 verwendet. Es gibt zwei Versionen dieser App: Eine enthält verschiedene Binärdateien, die aus der System-Shell verwendet werden können, die andere nur den cli-pie und einige CLIs, um sich mit anderen verschiedenen Sockets zu verbinden (für engpc kannst du dieses jetzt aus der System-Shell sourcen – ich empfehle, zuerst tools.sh zu sourcen). Für beide gibt es außerdem eine Version für Android 9 (für ältere Geräte; du kannst die App aber auch mit Apktool M neu verpacken und die gewünschte Version auswählen).

So funktioniert diese Methode: Zuerst führst du als adb oder shizuku rish das UnisocEngSyshell_Enabler_Script.sh aus, um die App com.sprd.engineermode zu aktivieren (nur bei neuen Modellen nötig). Führe dann gemäß den Anweisungen auf dem Wähler *#*#83781#*#* aus, um die Hauptaktivität zu starten, und wechsle von dort in die Adb-Shell-Aktivität. Gib dann in eine Zeile den vollständigen Pfad des cli-pie ein (einschließlich des Applets) und in die andere "setprop persist.sys.cmdservice.enable enable". Drücke dann so schnell wie möglich zuerst bei setprop auf Start und dann bei der cli-pie-Zeile, und zack, es wird "connected" angezeigt. Drücke dann bei der Setprop-Aktivität auf Ende und lösche den Text, gib "nc -s 127.0.0.1 -p 1234 -L sh -l" ein oder was du verwendest, um die Reverse-Shell zu starten. Gehe dann zum Terminal und verbinde dich mit dem entsprechenden Binary zurück; falls es nicht läuft, source das entsprechende Script oder verbinde dich einfach mit "nc 127.0.0.1 1234". Danach "source /sdcard/Documents/unisoc-su.sh" (oder wo auch immer du das Script platziert hast, aber es muss aus der System-Shell erreichbar sein). Das war's – wenn alles korrekt ist, hast du gerade eine Root-Shell erhalten.

Jetzt sprechen wir über diesen Exploit: Der Kontext ist stark durch selinux geschützt; wir haben root, aber sämtliche Schutzmechanismen sind weiterhin aktiv. Dieser Root ist extrem wertvoll, weil wir nichts deaktiviert haben, um ihn zu erlangen, anders als bei ähnlichen Exploits. Leider hat dieser Kontext nicht genug Rechte, um selinux zu deaktivieren; außerdem scheint die Ausführung nur über den System-PATH zu funktionieren. Was den Dienst selbst betrifft: Unter Android 9 (also vor dem CVE-2022-47339-Patch) scheint er keine Gruppen in seiner Service-RC zu haben, sodass standardmäßig root verwendet wird. Später wurden dagegen Gruppen hinzugefügt (und root als gid/Gruppen entfernt), daher ist es offensichtlich, dass der Dienst stärker eingeschränkt wurde – aber solange selinux aktiv ist, ist es ohnehin selinux, das den Ton angibt. Zum Verhalten des Dienstes: Auf neueren Geräten scheint der Dienst zu laufen, bis ihn etwas verwendet oder sich mit ihm verbindet; wenn kein Client verbunden ist oder kein Befehl an ihn gesendet wird, schaltet sich der Dienst ab, und die Setprop-Eigenschaft wird benötigt, um ihn wieder zu aktivieren. Der Dienst schaltet sich fast sofort ab – deshalb führen wir bei dieser Methode den Setprop aus und verbinden uns schnell. Unter Android 9 scheint der Dienst nach dem Setprop auf einen Befehl zu warten; das scheint der Unterschied zwischen älteren und neueren Geräten zu sein. Nach der Ausführung schaltet er sich ab. Natürlich ist es möglich, sich einfach mit socat oder dem cli-pie mit ihm zu verbinden (oder die Bridge zu starten); in diesem Fall bleibt der Dienst aktiv, da er durch diese Verbindung belegt ist. Wenn kein Befehl angegeben wird, wartet der Dienst unbegrenzt.

cmd_services.rc aus Android-13-User-ROM und Android-9-ENG-ROM, um die Unterschiede zu zeigen cmd_services_android13 (user) rc cmd_services_android9 (eng) rc

CVEs, die diese Methode inspiriert haben: CVE-2022-47339 (cmd_services) von Lewei Qu(曲乐炜) und CVE-2025-31710 (System-Shell von com.sprd.engineermode) von mir – obwohl Lewei Qu(曲乐炜) offenbar ein ähnliches CVE zu com.sprd.engineermode hatte; das habe ich jedoch erst entdeckt, nachdem ich meins bekommen hatte.

Außerdem gibt es drei Sonderfälle, die später auftraten; sie gehören nicht zu den inspirierenden CVEs. Beim ersten handelt es sich um eine erneut eingeführte Schwachstelle, die ich hier hinzufüge, um die Dinge übersichtlicher zu machen: CVE-2025-67264 (Doogee com.sprd.engineermode – schlechter Patch auf neuen Unisoc-Modellen, hier behandelt) ebenfalls von mir. Der zweite Fall betrifft neue ZTE-Modelle; es ist unklar, ob er für alle oder nur für einige gilt: Die Adb-Shell-Aktivität von com.sprd.engineermode wurde beibehalten. Beim ZTE Blade V70 Vita tritt dasselbe Problem wie bei CVE-2025-67264 auf, aber später hat ZTE es gepatcht, indem es die Aktivität auf userdebug/eng beschränkte (kein CVE, da sie es selbst bemerkten), anstatt sie zu entfernen. Infolgedessen wird die Aktivität in der App-Oberfläche angezeigt, meldet jedoch, dass sie auf User-Builds nicht geöffnet werden kann. Das Gerät ist verwundbar auf (vermutlich vor dieser Änderung): ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20241231.044538:user/release-keys und wurde gepatcht auf ZTE/EEA_P606F17/P606F17:14/UP1A.231005.007/20250527.224618:user/release-keys. Ähnliches passiert beim ZTE Blade A55. Diese Modelle laufen mit Android 14; dort wurde cmd_services neu geschrieben und der Name in tool_service geändert (und die Dienste, die darauf zugreifen können, wurden reduziert: com.sprd.engineermode, com.sprd.autoslt, com.sprd.runtime, com.spreadtrum.sgps, com.sprd.validationtools). Diese neue Version ist immer aktiv und benötigt kein Setprop. Der dritte Fall, eine Schwachstelle ähnlich der in diesem Repo, die alte Unisoc-Modelle betrifft, wurde hier behandelt.

Hier werden verschiedene Skripte für unisoc-su bereitgestellt: eines ohne Anleitung: unisoc-su.sh; eines, das dich nur über die System-Shell zur Root-Shell führt (diese Methode ist einfacher, funktioniert offline und ohne Shizuku/adb): unisoc-su-syshell-only-tut.sh; eines, das mit Shizuku/adb zur Root-Shell führt und nur zum Ausführen des Setprop-Teils dient: unisoc-su-adb-shizuku-tut.sh; sowie eine Version zum Verbinden mit verschiedenen Sockets. Du kannst das gewünschte Skript von deinem Terminal aus sourcen – nur unisoc-su.sh und die letztgenannte Version müssen aus der System-Shell gesourct werden. Außerdem gibt es ein tools.sh-Skript im ghostroot-Ordner, um verschiedene Verzeichnisse zu PATH hinzuzufügen; es ist mit adb/System und Root kompatibel. Ebenfalls vorhanden ist ein multi-Skript zum Starten der System-Shell, falls du nicht weißt, welches nc auf deinem System vorhanden ist – es versucht, über verschiedene mögliche Binärdateien eine nc-Verbindung herzustellen, bis die Verbindung erfolgreich ist.

Jetzt habe ich außerdem eine kleine PoC-App hinzugefügt. Es ist nur eine App mit vier Schaltflächen: eine zum Verbinden mit der cmd_services-Root-Shell, eine weitere zum Verbinden mit der System-Shell, eine Hilfe-Schaltfläche, eine Schaltfläche zum Löschen der Ausgabe und ein Mini-Terminal. Die Vorbereitung muss manuell erfolgen, daher ist die App sicher zu verwenden.

Über GhostRoot (Post-Exploit-Root-Kanal) Ein heimlicher Post-Exploit-Befehlskanal, der im RAM überlebt und Eingaben von jeder nicht privilegierten App über dateibasierte E/A akzeptiert.

Der Exploit funktioniert bis Android 13; in späteren Versionen hat Unisoc das sharedUserId-Tag aus der EngineerMode-App entfernt, sodass sie jetzt eine normale Benutzer-App ist. Dadurch verweigert selinux die Ausführung des cli-pie unter Android 14 und höher.

SharedUid-NormalUid_Compare-Patch Bild bereitgestellt von TomKing062