
Eine Methode für CVE-2025-31710 und zum Verbinden mit cmd_skt, um eine Root-Shell auf ungepatchten Unisoc-Modellen zu erhalten.
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

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:

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

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.